In this blog I am going to show you how to provide L4-L7 service insertion within BGP EVPN fabric especially using eBGP between appliance and leaf pair switches. The challenge with L4-L7 service insertion is that such appliance can be deployed as virtual machine and could be easily migrated (vMotion) at any point across different ESX hosts connected to different leaf switches. That’s often seen in multi tenant environments where end customers are not big enough and they don’t need powerful physical appliance to provide L4-L7 service. If this is a case and there is a business requirement to engaged dynamic routing protocol between fabric and appliance, you must be sure that after migration of the appliance it can re-establish adjacency fast enough to minimize business impact.
Below is a network diagram which I am going to use to show configuration steps and some design consideration to achieve end-to-end connectivity for such design requirements.
Before we dive into configuration and design consideration below some info regard the topology.
- Internal VLAN 100 10.1.100.0/24 is stretch across the fabric and is mapped to the VNI 100100. In addition, that VLAN is configured with the distributed gateway.
- Default route 0.0.0.0/0 is received from the external network and is injected into own VRF called INTERNET.
- The firewall has static default route 0.0.0.0/0 which point to 10.1.200.3 and is redistributed into internal BGP to provide Internet access.
- There is a transit VLAN 201 10.1.201.0/24 which is uses to provide transport for eBGP between the firewall and leaf switches. This VALN is not map to any VNI and is only local significant for each leaf pair.
- Each leaf pair switches are configured in its own BGP AS as depicted on the diagram and they use MLAG.
- Virtual appliance is configured with BGP AS 65200. In addition, DMZ VLAN 202 10.1.202.0/24 is stretch across the fabric and is mapped to the VNI 100202 and the default gateway is terminated on the firewall.
In this blog I am not going to discuss how to configure underlay and overlay network to provide end-to-end connectivity between the leafs switches. I assume that you have some basic knowledge and you know how to do so.
Lets first focus on the transit link between the virtual firewall and leaf switches LEAF02-A and LEAF02-B.
Figure-1 and Figure-2 shows related configuration for both leafs. The difference between both leafs is the IP address for the transit VLAN 201. The LEAF02-A and LEAF02-B use 10.1.201.1/24 and 10.1.201.2/24 respectively. In addition, each switch has different virtual-router mac address. The remaining configuration is exactly the same for both nodes. On thing to note is that these config is shared among all leafs in the fabric. That’s required to make sure when virtual appliance is migrated to different ESX host it will be able to establish eBGP session with new leaf pair. Interface VLAN 201 uses mac address virtual-router command to assign virtual mac address the the SVI on each switch from virtual-router mac-address. The interface keeps the same MAC address across the fabric and that’s required to make sure that after migration of the virtual appliance, it will be able migrate to different leafs switches without relaying on new ARP resolution for its BGP peers. Another important thing to emphasize is that transit network 10.1.201.0/24 (VLAN 201) is not extended through the fabric and VLAN 201 is not mapped to any specific VNI. This is not required however the drawback of that approach is that virtual appliance IP address 10.1.201.254 won’t be reachable from host connected to different leafs. That network only provides the transit however if you need reachability to transit IP of the appliance you can extend that VLAN across the fabric.
Furthermore under tenant vrf I am using local-as feature to make sure that virtual appliance always peer with the same BGP AS when is moved across the fabric. Technically you don’t have to do it however from scalability and manageability perspective it make sense because you can minimize BGP peering statement on the virtual appliance and simplify configuration. You can put all leafs in the same BGP AS number and use allowas-in feature to make sure appliance always peer with the same BGP AS.
LEAF02-A
ip virtual-router mac-address aa:aa:00:00:00:aa
interface Vlan200
vrf forwarding INTERNET
ip address 10.1.200.1/24
ip virtual-router address 10.1.200.3
interface Vlan201
vrf forwarding A
ip address 10.1.201.1/24
mac address virtual-router
router bgp 65004
vlan 201
rd auto
route-target both 1:200
redistribute learned
vrf A
rd 1:200
route-target import evpn 1:200
route-target export evpn 1:200
neighbor 10.1.201.254 remote-as 65100
neighbor 10.1.201.254 local-as 65200 no-prepend replace-as
neighbor 10.1.201.254 maximum-routes 12000
redistribute connected
!
address-family ipv4
neighbor 10.1.201.254 activate
interface Vxlan1
vxlan source-interface Loopback1
vxlan udp-port 4789
vxlan vlan 100 vni 100100
vxlan vlan 202 vni 100202
vxlan vrf A vni 100001
vxlan vrf INTERNET vni 100002
vxlan flood vtep 10.1.1.200Figure-1
LEAF02-B
ip virtual-router mac-address aa:aa:00:00:00:ab
interface Vlan200
vrf forwarding INTERNET
ip address 10.1.200.2/24
ip virtual-router address 10.1.200.3
interface Vlan201
vrf forwarding A
ip address 10.1.201.1/24
mac address virtual-router
router bgp 65004
vlan 201
rd auto
route-target both 1:200
redistribute learned
vrf A
rd 1:200
route-target import evpn 1:200
route-target export evpn 1:200
neighbor 10.1.201.254 remote-as 65100
neighbor 10.1.201.254 local-as 65200 no-prepend replace-as
neighbor 10.1.201.254 maximum-routes 12000
redistribute connected
!
address-family ipv4
neighbor 10.1.201.254 activate
interface Vxlan1
vxlan source-interface Loopback1
vxlan udp-port 4789
vxlan vlan 100 vni 100100
vxlan vlan 202 vni 100202
vxlan vrf A vni 100001
vxlan vrf INTERNET vni 100002
vxlan flood vtep 10.1.1.200Figure-2
When eBGP configuration is in place for the transit network between leaf switches and the virtual appliance we can verify how that looks from the control-plane perspective.
Figure-3 shows what prefixes are received from the virtual firewall. Prefix 10.1.202.0/24 is DMZ where firewall provides a default gateway for that LAN segment. Apart DMZ prefix default route is advertised for the Internet access.
LEAF02-B#sh ip bgp neighbors 10.1.201.254 routes vrf A
BGP routing table information for VRF A
Router identifier 10.1.201.2, local AS number 65004
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 0.0.0.0/0 10.1.201.254 - 100 0 65100 ?
* > 10.1.202.0/24 10.1.201.254 - 100 0 65100 ?
LEAF02-A#sh ip bgp neighbors 10.1.201.254 routes vrf A
BGP routing table information for VRF A
Router identifier 10.1.201.1, local AS number 65004
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 0.0.0.0/0 10.1.201.254 - 100 0 65100 ?
* > 10.1.202.0/24 10.1.201.254 - 100 0 65100 ?Figure-3
Looking at the Figure-4 you can see the ARP entry exist on both LEAF02 switches for the next-hop 10.1.201.254, which is eBGP peer firewall appliance connected over MLAG.
LEAF02-A#sh ip arp vrf A
Address Age (sec) Hardware Addr Interface
10.1.201.2 N/A aaaa.0000.00ab Vlan201, not learned
10.1.201.254 N/A 5000.0003.0002 Vlan201, Port-Channel10
LEAF02-B#sh ip arp vrf A
Address Age (sec) Hardware Addr Interface
10.1.201.1 N/A aaaa.0000.00aa Vlan201, not learned
10.1.201.254 N/A 5000.0003.0002 Vlan201, Port-Channel10Figure-4
Checking tenant A VRF routing table on the LEAF02-A, the Figure-5 shows no information about internal host 10.1.100.100 which is not power up yet.
LEAF02-A#sh ip route vrf A
VRF: A
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian,
DP - Dynamic Policy Route
Gateway of last resort:
B E 0.0.0.0/0 [200/0] via 10.1.201.254, Vlan201
C 10.1.100.0/24 is directly connected, Vlan100
C 10.1.201.0/24 is directly connected, Vlan201
B E 10.1.202.0/24 [200/0] via 10.1.201.254, Vlan201Figure-5
Figure-6 shows output from the LEAF01-A switch where host 10.1.100.100 will be connected. At this point no ARP entry is present yet, however the DMZ subnet 10.1.202.0/24 is received via BGP.
LEAF01-A#sh ip arp vrf A
Address Age (min) Hardware Addr Interface
LEAF01-A#sh ip route vrf A
VRF: A
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian,
DP - Dynamic Policy Route
Gateway of last resort:
B E 0.0.0.0/0 [200/0] via VTEP 10.1.1.201 VNI 100001 router-mac 50:00:00:1b:5e:8d
C 10.1.100.0/24 is directly connected, Vlan100
C 10.1.201.0/24 is directly connected, Vlan201
B E 10.1.202.0/24 [200/0] via VTEP 10.1.1.201 VNI 100001 router-mac 50:00:00:1b:5e:8dFigure-6
The DMZ prefix 10.1.202.0/24 is learned from the VTEP 10.1.1.201 and VNI 100001. THe VNI 100001 is mapped to VRF A and provides symmetric IRB. In addition, VTEP router-mac 50:00:00:1b:5e:8d is sent as extended community.
Lets look at the BGP EVPN entry on this router for more details. The Figure-7 reveals a lot of information most of them at the same as for standard IPv4 BGP advertisement. There are two pieces of information which are unique for BGP EVPN, that’s the VNI and encapsulation method. In this example VNI 10001 is used and encapsulation method is VXLAN.
LEAF01-A#sh bgp evpn route-type ip-prefix 10.1.202.0/24 detail
BGP routing table information for VRF default
Router identifier 10.1.1.6, local AS number 65001
BGP routing table entry for ip-prefix 10.1.202.0/24, Route Distinguisher: 1:200
Paths: 2 available
65000 65004 65100
10.1.1.201 from 10.1.1.4 (10.1.1.4)
Origin INCOMPLETE, metric -, localpref 100, weight 0, valid, external, ECMP head, best, ECMP contributor
Extended Community: Route-Target-AS:1:200 TunnelEncap:tunnelTypeVxlan EvpnRouterMac:50:00:00:1b:5e:8d
VNI: 100001
65000 65004 65100
10.1.1.201 from 10.1.1.5 (10.1.1.5)
Origin INCOMPLETE, metric -, localpref 100, weight 0, valid, external, ECMP, ECMP contributor
Extended Community: Route-Target-AS:1:200 TunnelEncap:tunnelTypeVxlan EvpnRouterMac:50:00:00:1b:5e:8d
VNI: 100001Figure-7
So far everything looks good. It looks like control-plane is working fine and DMZ network which is behind the firewall is properly advertised across the fabric to other leafs by means of BGP EVPN.
Now lets bring up the host 10.1.100.100 and ping DMZ host 10.1.202.100 to see what exactly happen behind the scene. As you can see looking at Figure-8 first ping failed because that host sent ARP request for local gateway,
SRV01> ping 10.1.202.100
10.1.202.100 icmp_seq=1 timeout
84 bytes from 10.1.202.100 icmp_seq=2 ttl=61 time=501.908 ms
84 bytes from 10.1.202.100 icmp_seq=3 ttl=61 time=465.055 ms
84 bytes from 10.1.202.100 icmp_seq=4 ttl=61 time=488.259 ms
84 bytes from 10.1.202.100 icmp_seq=5 ttl=61 time=605.851 msFigure-8
As always is good to look at the packet capture to analyze data plane. Figure-9 shows the output for ARP request sent from the host to its default gateway.
Figure-9
Next lets look at the actual ICMP packet sent from the host 10.1.100.100 to the DMZ host 10.1.202.100 behind the firewall.
Figure-10
As highlighted at the packet capture output above in Figure-10 you can see that outer IP packet is source from the IP 10.1.1.200 (local VTEP) to the 10.1.1.201 (remote VTEP). The VNI used for the VXLAN encapsulation is 100001. The inner IP packet was sourced from 10.1.100.100 to 10.1.202.100, and that was ICMP type request. When packet reached the remote VTEP 10.1.1.201 was de-encapsulated and sent to the firewall appliance. The firewall forwards that ICMP packet on the local segment (VLAN 202), however in this setup the DMZ host is connected to a different leaf switch. The firewall sent a packet to local leafs switches where packet was VXLAN encapsulated (VNI 100202) again and forward across the fabric to its final destination.
The Figure-11 shows packet capture for the ICMP packet however in this example is encapsulated over different VNI 100202 which mapped to DMZ VLAN 202.
Figure-11
The return packet follows the same logic which ultimately provide end-to-end connectivity.
Lets run some commands at switches to see how the control plane looks like when ICMP was completed.
On the switch where internal host 10.1.100.100 is connected, nothing really changed because the DMZ subnet is still learned through the BGP EVPN fabric from the VTEP 10.1.1.201. The Figure-12 shows vrf routing table after communication happened between these two hosts.
LEAF01-A#sh ip route vrf A
VRF: A
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian,
DP - Dynamic Policy Route
Gateway of last resort:
B E 0.0.0.0/0 [200/0] via VTEP 10.1.1.201 VNI 100001 router-mac 50:00:00:1b:5e:8d
C 10.1.100.0/24 is directly connected, Vlan100
C 10.1.201.0/24 is directly connected, Vlan201
B E 10.1.202.0/24 [200/0] via VTEP 10.1.1.201 VNI 100001 router-mac 50:00:00:1b:5e:8dFigure-12
However looking at the leaf switch where firewall appliance is connected to you can see that new BGP entry for the host 10.1.100.100/32 appeared in the routing table. The Figure-13 indicates that prefix was learned from the VTEP 10.1.1.200 over VNI 100001. This prefix is learned from other two leafs switches.
LEAF02-B#sh ip route vrf A
VRF: A
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B - BGP, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian,
DP - Dynamic Policy Route, L - VRF Leaked
Gateway of last resort:
B E 0.0.0.0/0 [200/0] via 10.1.201.254, Vlan201
B E 10.1.100.100/32 [200/0] via VTEP 10.1.1.200 VNI 100001 router-mac 50:00:00:15:f4:e8
via VTEP 10.1.1.200 VNI 100001 router-mac 50:00:00:72:8b:31
C 10.1.100.0/24 is directly connected, Vlan100
C 10.1.201.0/24 is directly connected, Vlan201
B E 10.1.202.0/24 [200/0] via 10.1.201.254, Vlan201Figure-13
Now lets try to move the virtual firewall from LEAF02 pair switches to LEAF01 pair (mimic vmotion) and see what will happen. I am going to keep running ICMP to see what is potential packet lost. Before we dive into details lets see how exactly the virtual firewall is configured from BGP perspective. The Figure-14 depicted that firewall has two BGP peers configured with 10.1.201.1 and 10.1.201.2 respectively. It’s a basic BGP configuration with adjusted timers to speed up convergence. Also please pay attention the the ARP entry on the firewall.
admin@DC-PA-01> show arp all
maximum of entries supported : 250
default timeout: 1800 seconds
total ARP entries in table : 4
total ARP entries shown : 4
status: s - static, c - complete, e - expiring, i - incomplete
interface ip address hw address port status ttl
--------------------------------------------------------------------------------
ethernet1/1 10.1.200.3 aa:aa:00:00:00:ab ethernet1/1 c 1794
ethernet1/2.201 10.1.201.1 aa:aa:00:00:00:aa ethernet1/2 c 829
ethernet1/2.201 10.1.201.2 aa:aa:00:00:00:ab ethernet1/2 c 829
ethernet1/2.202 10.1.202.100 00:50:79:66:68:20 ethernet1/2 c 1777 Figure-14
When the firewall was migrated from one pair of leafs to other pair I noted just few packet lost as depicted by the Figure-15. This is because BGP session was tear down and re-establish from the scratch.
84 bytes from 10.1.202.100 icmp_seq=36 ttl=61 time=526.204 ms
10.1.202.100 icmp_seq=37 timeout
10.1.202.100 icmp_seq=38 timeout
10.1.202.100 icmp_seq=39 timeout
*10.1.100.1 icmp_seq=40 ttl=64 time=10.449 ms (ICMP type:3, code:0, Destination network unreachable)
*10.1.100.1 icmp_seq=41 ttl=64 time=17.543 ms (ICMP type:3, code:0, Destination network unreachable)
*10.1.100.1 icmp_seq=42 ttl=64 time=25.099 ms (ICMP type:3, code:0, Destination network unreachable)
*10.1.100.1 icmp_seq=43 ttl=64 time=9.685 ms (ICMP type:3, code:0, Destination network unreachable)
*10.1.100.1 icmp_seq=44 ttl=64 time=23.379 ms (ICMP type:3, code:0, Destination network unreachable)
*10.1.100.1 icmp_seq=45 ttl=64 time=16.609 ms (ICMP type:3, code:0, Destination network unreachable)
84 bytes from 10.1.202.100 icmp_seq=46 ttl=62 time=724.519 ms
84 bytes from 10.1.202.100 icmp_seq=47 ttl=62 time=207.989 ms
84 bytes from 10.1.202.100 icmp_seq=48 ttl=62 time=266.981 ms
^C
SRV01> Figure-15
As expected BGP went down on both LEAF02 switches during the firewall migration as shown by Figure-16.
LEAF02-A#Dec 13 12:03:44 LEAF02-A Mlag: %MLAG-3-PEER_HEARTBEAT_RESUMED: MLAG resumed receivi
ng UDP heartbeats from the peer 169.254.1.2.
Dec 13 12:21:52 LEAF02-A Bgp: %BGP-3-NOTIFICATION: sent to neighbor 10.1.201.254 (VRF A AS 6
5100) 4/0 (Hold Timer Expired Error/None) 0 bytesFigure-16
Now lets look at the LEAF01 switches to see what happened. As expected new BGP peering came up. The DMZ prefix 10.1.202.0/24 and default route were received from virtual firewall. The Figure-17 shows that BGP learned two prefixes from the firewall.
LEAF01-A#sh ip bgp summary vrf A
BGP summary information for VRF A
Router identifier 10.1.100.1, local AS number 65001
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc
10.1.201.254 4 65100 554 32 0 0 00:15:17 Estab 2 2
LEAF01-B#sh ip bgp summary vrf A
BGP summary information for VRF A
Router identifier 10.1.201.2, local AS number 65001
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc
10.1.201.254 4 65100 594 69 0 0 00:16:22 Estab 2 2Figure-17
Figure-18 shows routing table for tenant VRF A which indicates that now default route and DMZ prefix on this switch is learned from directly connected BGP peer not through the VTEP 10.1.1.201 as shown above by Figure-6. You can compare Figure-18 and Figure-6 to see a difference.
LEAF01-A#sh ip route vrf A
VRF: A
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian,
DP - Dynamic Policy Route
Gateway of last resort:
B E 0.0.0.0/0 [200/0] via 10.1.201.254, Vlan201
C 10.1.100.0/24 is directly connected, Vlan100
C 10.1.201.0/24 is directly connected, Vlan201
B E 10.1.202.0/24 [200/0] via 10.1.201.254, Vlan201Figure-18
As expected the LEAF02 pair switches should now learn DMZ prefix 10.1.202.0/24 and default route over the fabric from VTEP 10.1.1.200. The Figure-19 shows that. You can compare that figure with Figure-5 and see difference before and after the firewall was migrated.
LEAF02-A#sh ip route vrf A
VRF: A
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B - BGP, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian,
DP - Dynamic Policy Route, L - VRF Leaked
Gateway of last resort:
B E 0.0.0.0/0 [200/0] via VTEP 10.1.1.200 VNI 100001 router-mac 50:00:00:15:f4
:e8
B E 10.1.100.100/32 [200/0] via VTEP 10.1.1.200 VNI 100001 router-mac 50:00:00
:15:f4:e8
via VTEP 10.1.1.200 VNI 100001 router-mac 50:00:00
:72:8b:31
C 10.1.100.0/24 is directly connected, Vlan100
C 10.1.201.0/24 is directly connected, Vlan201
B E 10.1.202.0/24 [200/0] via VTEP 10.1.1.200 VNI 100001 router-mac 50:00:00:1
5:f4:e8Figure-19
Let see if we can reach the Internet after migration. Figure-20 shows trace from internal host to the google DNS. First 8 hops are on my lab network and everything beyond hop 8 is the Internet.
SRV01> trace 8.8.8.8
trace to 8.8.8.8, 24 hops max (ICMP), press Ctrl+C to stop
1 10.1.100.1 41.406 ms 40.252 ms 144.563 ms
2 10.1.201.254 216.243 ms 145.229 ms 385.000 ms
3 10.1.200.1 479.340 ms 349.270 ms 347.351 ms
4 * * *
5 10.1.18.2 567.109 ms 392.657 ms 376.962 ms
6 10.1.18.1 431.550 ms 587.274 ms 554.308 ms
7 10.1.1.1 572.032 ms 512.087 ms 442.437 ms
8 192.168.1.1 565.444 ms 491.899 ms 489.777 ms
9 80.50.18.18 429.988 ms 617.683 ms 491.256 ms
10 80.50.18.17 482.970 ms 614.442 ms 428.976 ms
11 194.204.175.13 525.626 ms 675.046 ms 539.710 ms
12 193.251.248.153 493.095 ms 650.385 ms 445.469 ms
13 193.251.255.168 731.428 ms 532.430 ms 473.473 ms
14 * * *
15 8.8.8.8 541.027 ms 564.183 ms 717.602 ms
Figure-20
As you can see the BGP was successfully re-establish between the virtual firewall appliance and other leaf pair switches. End-to-end connectivity was maintain whit minimal impact. You can you that approach for pretty much any L4-L7 service you name. One thing to note is that both transit VLAN’s 200 and 201 are only local significant per leaf pair and they are not extended over the fabric. The figure-21 shows the VXLAN interface configuration which is identical across all leafs switches in this setup.
LEAF01-A#sh run int vxlan 1
interface Vxlan1
vxlan source-interface Loopback1
vxlan udp-port 4789
vxlan vlan 100 vni 100100
vxlan vlan 202 vni 100202
vxlan vrf A vni 100001
vxlan vrf INTERNET vni 100002
vxlan flood vtep 10.1.1.201Figure-21
As demonstrated above you can use that approach to provide dynamic routing capabilities between L4-L7 service appliances and leaf switches, if there is such a business requirement. Furthermore you can migrate virtual appliance between different leafs switches if needed. In next part I am going to look at similar scenario but with OSPF as a routing protocol between virtual appliance and leaf switches.
netmindblog 