Is it possible to configure vrfs in A10 thunders? If so, could you please provide example
For configuring something like Virtual routing and forwarding (VRF), generally we will create Application Delivery Partitions (ADP, formerly called Layer 3 Virtual (L3V) Partitions).
Each ADP maintains its own MAC tables, IP addresses, routing tables, and peering with external routers. So one configures each partition as needed based on the surrounding networks.
I can provide more detail if you provide and example of what you’re trying to achieve.
Thanks for the info. Trying to create one external vrf towards the Internet, to an ibgp peering router. The other is internal vrf using ospf, towards a cgnat router. Using a single trunk group, with 40g LAG, Then, creating subinterfaces of that trunk interface, going to inside and outside ve’s
Here’s a sample proposed config:
int loopback 0
ip address 10.10.3.10 255.255.255.255
!
vlan 10
tagged trunk 5
router-interface ve 10
named “inside”
!
vlan 11
tagged trunk 5
router-interface ve 11
named “outside”
!
interface ve 10
  name “TO CGNAT”
  ip address 10.11.25.2 255.255.255.252
  load-interval 30
  ip nat inside
!
interface ve 11
  name “TO INET”
  ip address 24.18.10.22 255.255.255.252
  load-interval 30
  ip nat outside
!
interface ethernet 1
  name “TO CGNAT”
  enable
  trunk-group 5 lacp
  mode active
  lacp timeout long
!
interface ethernet 2
  name “TO CGNAT”
  enable
  trunk-group 5 lacp
  mode active
  lacp timeout long
!
interface ethernet 3
  name “TO INET”
  enable
  trunk-group 5 lacp
  mode active
  lacp timeout long
!
interface ethernet 4
  name “TO INET”
  enable
  trunk-group 5 lacp
  mode active
  lacp timeout long
!
router bgp 65001
bgp router id 10.10.3.10
vrf INTERNET
no synchronization
bgp log-neighbor-changes
default-information originate
address-family ipv4 unicast
 network 24.18.10.20/30
 network 4.18.10.0/25
 neighbor  24.18.10.21 remote-as 65001
 neighbor route-reflector-client
 neighbor  24.18.10.21 default-originate
 neighbor  24.18.10.21 soft-reconfiguration inbound
 neighbor  24.18.10.21 route-map MPLS-IN in
 neighbor  24.18.10.21 route-map MPLS-OUT out
!
router ospf 65001
ospf router-id 10.10.3.10
vrf CGNAT
redistribute ip-nat
default-information originate route-map default\_route
network 10.11.25.0 0.0.0.3 area 0
network 10.10.3.10 0.0.0.0 area 0
!
ip prefix-list MPLS-IN permit 0.0.0.0/0
ip prefix-list MPLS-OUT permit 4.18.10.10/25
!
route-map default\_route permit 1
 set ip next-hop 10.11.25.1
!
route-map MPLS-IN permit 10
 match ip address prefix-list MPLS-IN
!
route-map MPLS-OUT permit 10
 match ip address prefix-list MPLS-OUT
!
router ospf 65001
vrf CGNAT
redistribute bgp 65001 subnets
  area 0
   interface bundle-ethernet5.10
router bgp 65001
bgp router id 10.10.3.10
default-information originate
 neighbor 24.18.10.21 remote-as 65001
 neighbor 24.18.10.21 update-source 24.18.10.22
 neighbor 4.18.10.0 /25 remote-as 65001
 redistribute ip-nat route-map nat\_redis
exit
!
router ospf 65001
 ospf router-id 10.10.3.10
 default-information originate route-map default\_route
 network 10.11.25.0 0.0.0.3 area 0
 network 4.18.10.0 0.0.0.127 area 0
 network 10.10.3.10 0.0.0.0 area 0
exit
route-map default\_route permit 1
 set ip next-hop 10.11.25.1
!
route-map nat\_redist permit 1
set ip next-hop 24.18.10.21
This is a publicly accessible forum, so you may wish to transform public addresses into RFC1918 addresses. With the redistribute ip-nat, ip nat inside, and ip nat outside I’m wondering if this is the CGNAT device. Not that is matters for the answer. WRT to VRF (Virtual routing and forwarding), something you could do is create 2 ADP, putting the OSPF config in one ADP and the BGP config in the other config. For example, in our training pods, we have a single ACOS vThunder that acts like our inside and our outside router. The shared partition is left mostly empty of config, except for the obvious
partition CLIENTS id 1 partition INTERNET id 2
and enabling the needed interface ethernet <#> Inside each partition, I claim the appropriate 802.1Q tagged vlans based on the Layer2 config surrounding the vm. The CLIENTS partition has the OSPF config, and the INTERNET partition has the BGP config. To the student, it looks like we have 2 router vms, but it’s really just 1 vm with some extra virtual nics defined, and the hypervisor virtual switching configured to allow vms to use 802.1Q tags. As an administrator, to look at the OSPF interactions, use the standard active-partition CLIENTS command to get into the partition to check the status of OSPF. Inside CLIENTS, I can’t see what BGP side is doing. To troubleshoot BGP, I active-partition INTERNET and I’m off to the races.
Thank you. The addresses are random/fictional, but I guess I still could’ve used RFC1918’s. As it currently is configured, it should still route properly, correct? Or, are the partitions a must?