Cisco Nexus 9000 Series NX-OS VXLAN Configuration Guide, Release 9.2(x)
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter covers insertion of Layer 4 – Layer 7 network services (firewall, load balancer, and so on) in a VXLAN fabric.
As opposed to traditional 3-tier network topologies, in which L4-L7 services are connected to the switches hosting the default
gateway (aggregation/distribution), L4-L7 services in VXLAN fabrics are typically connected to the leaf or border switches,
often referred to as services leafs.
You can attach a L4-L7 services device to a VXLAN fabric in various ways. This chapter addresses the considerations you must
take depending on how the L4-L7 services device is attached and the requirements of the device and the network.
Integrating Layer 3 Firewalls in VXLAN Fabrics
This section provides details on how to integrate a firewall within a VXLAN EVPN fabric. A Layer-3 firewall involves separating
different security zones.
When integrating a Layer-3 firewall in a VXLAN EVPN fabric with a distributed Anycast Gateway, each of these zones must correspond
to a VRF/tenant on the fabric. The traffic within a tenant is routed by the fabric. Traffic between the tenants is routed
by the firewall. This scenario often refers to an inter-tenant or tenant edge firewall.
Consider two zones: an inside zone and an outside zone. This scenario requires a VRF definition on the fabric. You can call
the VRFs the inside VRF and the outside VRF. Traffic between subnets within the same VRF is routed on the VXLAN fabric using
the distributed gateway. Traffic between VRFs is routed by the firewall where the rules are applied.
Figure 1. Topology Overview with Firewall Attachment
Single-Attached Firewall with Static Routing
If the firewall does not support running a routing protocol, you must have static routes on each VTEP pointing to the firewall
as the next hop. The firewall also has static routes pointing to the Anycast Gateway IP as the next hop. The challenge with
a static route is that the VTEP with an active firewall must be the one advertising the routes to the fabric. One way to accomplish
this is to track the active firewall reachability via HMM and use this tracking to advertise routes into the fabric. When
the active firewall is connected to VTEP A, VTEP A has a static route that tracks where the route is advertised if the firewall
IP is learned as the HMM route. When the firewall fails and the standby firewall takes over, VTEP A learns the firewall IP
using BGP, and VTEP B learns the firewall IP using HMM. VTEP A withdraws the route, and VTEP B advertises the route into the
fabric. See the following example.
VTEP A and VTEP B:
Vlan 10
Name inside
Vn-segment 10010
Vlan 20
Name outside
Vn-segment 10020
Interface VLAN 10
Description inside_vlan
VRF member INSIDE
IP address 10.1.1.254/24
fabric forwarding mode anycast-gateway
Interface VLAN 20
Description outside_vlan
VRF member OUTSIDE
IP address 20.1.1.254/24
fabric forwarding mode anycast-gateway
interface nve1
no shutdown
host-reachability protocol bgp
source-interface loopback1
member vni 10010
mcastgroup 239.1.1.1
member vni 10020
mcastgroup 239.1.1.1
member vni 1001000 associate-vrf
member vni 1002000 associate-vrf
track 10 ip route 10.1.1.1/32 reachability hmm
vrf member INSIDE
!
VRF context INSIDE
Vni 1001000
IP route 20.1.1.0/24 10.1.1.1 track 10
track 20 ip route 20.1.1.1/32 reachability hmm
vrf member OUTSIDE
!
VRF context OUTSIDE
Vni 1001000
IP route 10.1.1.0/24 20.1.1.1 track 20
VTEPA# show track 10 Track 10
IP Route 20.1.1.1/32 Reachability Reachability is UP
VTEPA# show ip route 20.1.1.0/24 vrf INSIDE
IP Route Table for VRF "INSIDE"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
20.1.1.0/24, ubest/mbest: 1/0
*via 10.1.1.1 [1/0], 00:00:08, static
Firewall Failure on VTEP A caused the track to go down causing VTEP A to withdraw the static route.
VTEPA# show track 20 Track 20
IP Route 20.1.1.1/32 Reachability Reachability is DOWN
VTEPA# show ip route 20.1.1.0/24 vrf INSIDE
IP Route Table for VRF "RED"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
Route not found
Recursive Static Routes Distributed to the Rest of the Fabric
With this approach, the static routes are configured wherever the inside or outside VRF exists. As the next-hop is reachable
through host routes (EVPN Route-Type2), the change of the active firewall to standby and vice versa is only seen locally and
doesn’t introduce any churn to the other VXLAN fabric. This approach can help to better scale and improve convergence.
Any VTEP:
VRF context OUTSIDE
Vni 1002000
IP route 10.1.1.0/24 20.1.1.1
! static route on VTEP pointing to Firewall next hop
! firewall VIP 20.1.1.1
VRF context INSIDE
Vni 1001000
IP route 20.1.1.0/24 10.1.1.1
! static route on VTEP pointing to Firewall next hop
! firewall VIP 10.1.1.1
Redistribute Static Routes into BGP and Advertise to the Rest of the Fabric
Through redistribution, we make the route toward the active firewall shown to the VTEP where it resides. The route is seen
as a prefix route (EVPN Route-Type5), and as such, only the route toward the VTEP with the active firewall is seen. In the
case of a firewall active/standby change, the tracking needs to detect the change and inform all of the remote VTEPs of this
change. This behavior is equal to a route "delete" followed by an "add." This approach needs to notify all VTEPs with the
VRF, and hence a wider churn can be seen.
Figure 2. Dual-Attached Firewall with Static Routing
VTEP A and VTEP B:
Vlan 10
Name inside
Vn-segment 10010
Vlan 20
Name outside
Vn-segment 10020
interface nve1
no shutdown
host-reachability protocol bgp
source-interface loopback1
member vni 10010
mcastgroup 239.1.1.1
member vni 10020
mcastgroup 239.1.1.1
member vni 1001000 associate-vrf
member vni 1002000 associate-vrf
Interface VLAN 10
Description inside_vlan
VRF member INSIDE
IP address 10.1.1.254/24
fabric forwarding mode anycast-gateway
Interface VLAN 20
Description outside_vlan
VRF member OUTSIDE
IP address 20.1.1.254/24
fabric forwarding mode anycast-gateway
VRF context INSIDE
Vni 1001000
IP route 20.1.1.0/24 10.1.1.1
! static route on VTEP pointing to Firewall next hop
! firewall VIP 10.1.1.1
VRF context OUTSIDE
Vni 1002000
IP route 10.1.1.0/24 20.1.1.1
! static route on VTEP pointing to Firewall next hop
! firewall VIP 20.1.1.1
router bgp 65000
vrf INSIDE
address-family ipv4 unicast
redistribute static route-map INSIDE-to-BGP
vrf OUTSIDE
address-family ipv4 unicast
redistribute static route-map OUTSIDE-to-BGP
Single-Attached Firewall with eBGP Routing
If the firewall supports BGP, one option is to use BGP as a protocol between the firewall and the service VTEP. Peering using
the anycast IP is not supported. The recommended design is to use dedicated loopback IPs on each VTEP and peer using the loopback.
As long as the loopback interfaces are not advertised via EVPN, the same IP address could be used on all of the belonging
VTEPs. We recommend using individual IP addresses on a per-VTEP basis.
Reachability to the loopback from the firewall can be configured using a static route on the firewall, pointing to the Anycast
Gateway IP on the VTEPs.
In the following example, an eBGP peering is established from the VTEPs, which are in AS 65000, and the firewall in AS 65002.
The BGP peering with iBGP is not supported.
Note
When having eBGP peering to active/standby firewalls connected to different VTEPs, export-gateway-ip must be enabled.
Do not use Anycast Gateway for BGP peerings.
VTEP A:
Vlan 10
Name inside
Vn-segment 10010
Vlan 20
Name outside
Vn-segment 10020
Interface VLAN 10
Description inside_vlan
VRF member INSIDE
IP address 10.1.1.254/24
fabric forwarding mode anycast-gateway
Interface loopback100
Vrf member INSIDE
Ip address 172.16.1.253/32
Interface VLAN 20
Description outside_vlan
VRF member OUTSIDE
IP address 20.1.1.254/24
fabric forwarding mode anycast-gateway
Interface loopback101
Vrf member OUTSIDE
Ip address 172.18.1.253/32
router bgp 65000
vrf INSIDE
! peer with Firewall Inside
neighbor 10.1.1.0/24 remote-as 65123
update-source loopback100
ebgp-multihop 5
address-family ipv4 unicast
local-as 65051 no-prepend replace-as
vrf OUTSIDE
! peer with Firewall Outside
neighbor 20.1.1.0/24 remote-as 65123
update-source loopback101
ebgp-multihop 5
address-family ipv4 unicast
local-as 65052 no-prepend replace-as
VTEP B:
Vlan 10
Name inside
Vn-segment 10010
Vlan 20
Name outside
Vn-segment 10020
Interface VLAN 10
Description inside_vlan
VRF member INSIDE
IP address 10.1.1.254/24
fabric forwarding mode anycast-gateway
Interface loopback100
Vrf member INSIDE
Ip address 172.16.1.254/32
Interface VLAN 20
Description outside_vlan
VRF member OUTSIDE
IP address 20.1.1.254/24
fabric forwarding mode anycast-gateway
Interface loopback101
Vrf member OUTSIDE
Ip address 172.18.1.254/32
router bgp 65000
vrf INSIDE
! peer with Firewall Inside
neighbor 10.1.1.0/24 remote-as 65123
update-source loopback100
ebgp-multihop 5
address-family ipv4 unicast
local-as 65051 no-prepend replace-as
vrf OUTSIDE
! peer with Firewall Outside
neighbor 20.1.1.0/24 remote-as 65123
update-source loopback101
ebgp-multihop 5
address-family ipv4 unicast
local-as 65052 no-prepend replace-as
With the VXLAN fabric generally being in a single BGP Autonomous System (AS), the AS of the inside VRF and the outside VRF
is the same. BGP does not install routes that are received from its own AS. Therefore, we need to adjust the AS-path to override
this rule. Various approaches exist, including disabling the rule that BGP drops routes from its own AS, which has further
implications to the network. To keep all of the BGP protection mechanics in place, the “local-as” approach allows you to mimic
routes being originated from a different AS. We recommend inserting the “local-as #ASN# no-prepend replace-as” on each firewall
peering with different “local-as” per VRF.
Figure 3. eBGP AS-Path Check
Dual-Attached Firewall with eBGP Routing
If the firewall supports BGP, one option is to use BGP as a protocol between the firewall and the service VTEP. Peering using
the anycast IP is not supported. The recommended design is to use dedicated loopback IPs on each VTEP and peer using the loopback.
As long as the loopback interfaces are not advertised via EVPN, the same IP address could be used on all of the belonging
VTEPs. We recommend using individual IP addresses on a per-VTEP basis. For vPC environments, it is required.
Reachability to the loopback from the firewall can be configured using a static route on the firewall, pointing to the Anycast
Gateway IP on the VTEPs.
In vPC deployments, you must have a per-VRF peering via a vPC peer-link. In addition to the per-VRF peering, you can enable
the advertisement of prefix routes (EVPN Route-Type 5) using the advertise-pip command. For vPC with fabric peering, the per-VRF peering is not necessary, and the advertisement of prefix routes (EVPN
Route-Type5) is required.
In the following example, an eBGP peering is established from the VTEPs, which are in AS 65000, and the firewall in AS 65002.
The BGP peering with iBGP is not supported.
Figure 4. Dual-Attached Firewall with eBGP
Note
When having eBGP peering to active/standby firewalls connected to different VTEPs, export-gateway-ip must be enabled.
Do not use Anycast Gateway for BGP peerings.
VTEP A:
Vlan 10
Name inside
Vn-segment 10010
Vlan 20
Name outside
Vn-segment 10020
Interface VLAN 10
Description inside_vlan
VRF member INSIDE
IP address 10.1.1.254/24
fabric forwarding mode anycast-gateway
Interface loopback100
Vrf member INSIDE
Ip address 172.16.1.253/32
Interface VLAN 20
Description outside_vlan
VRF member OUTSIDE
IP address 20.1.1.254/24
fabric forwarding mode anycast-gateway
Interface loopback101
Vrf member OUTSIDE
Ip address 172.18.1.253/32
router bgp 65000
vrf INSIDE
! peer with Firewall Inside
neighbor 10.1.1.0/24 remote-as 65123
update-source loopback100
ebgp-multihop 5
address-family ipv4 unicast
local-as 65051 no-prepend replace-as
vrf OUTSIDE
! peer with Firewall Outside
neighbor 20.1.1.0/24 remote-as 65123
update-source loopback101
ebgp-multihop 5
address-family ipv4 unicast
local-as 65052 no-prepend replace-as
VTEP B:
Vlan 10
Name inside
Vn-segment 10010
Vlan 20
Name outside
Vn-segment 10020
Interface VLAN 10
Description inside_vlan
VRF member INSIDE
IP address 10.1.1.254/24
fabric forwarding mode anycast-gateway
Interface loopback100
Vrf member INSIDE
Ip address 172.16.1.254/32
Interface VLAN 20
Description outside_vlan
VRF member OUTSIDE
IP address 20.1.1.254/24
fabric forwarding mode anycast-gateway
Interface loopback101
Vrf member OUTSIDE
Ip address 172.18.1.254/32
router bgp 65000
vrf INSIDE
! peer with Firewall Inside
neighbor 10.1.1.0/24 remote-as 65123
update-source loopback100
ebgp-multihop 5
address-family ipv4 unicast
local-as 65051 no-prepend replace-as
vrf OUTSIDE
! peer with Firewall Outside
neighbor 20.1.1.0/24 remote-as 65123
update-source loopback101
ebgp-multihop 5
address-family ipv4 unicast
local-as 65052 no-prepend replace-as
Per-VRF Peering via vPC Peer-Link
VTEP A and VTEP B:
vlan 3966
! vlan use for peering between the vPC VTEPS
vlan 3967
! vlan use for peering between the vPC VTEPS
system nve infra-vlans 3966,3967
interface vlan 3966
vrf memner INSIDE
ip address 100.1.1.1/31
interface vlan 3967
vrf memner OUTSIDE
ip address 100.1.2.1/31
router bgp 65000
vrf INSIDE
neighbor 100.1.1.0 remote-as 65000
update-source vlan 3966
next-hop self
address-family ipv4 unicast
vrf OUTSIDE
neighbor 100.1.2.0 remote-as 65000
update-source vlan 3967
next-hop self
address-family ipv4 unicast
The routes learned in each VRF are advertised to the rest of the fabric via BGP EVPN updates.
Single-Attached Firewall with OSPF
The following example shows a configuration snippet from VTEP A running OSPF peering with the firewall.
SVIs are defined on the VTEP for both inside and outside VRFs. The VTEP peers with the firewall on each of these VRFs dynamically
learn routing information to go from one VRF to the other.
VTEP A and VTEP B:
vlan 10
name inside
vn-segment 10010
vlan 20
name outside
vn-segment 10020
interface VLAN 10
Description inside_vlan
VRF member INSIDE
IP address 10.1.1.254/24
IP router ospf 1 area 0
fabric forwarding mode anycast-gateway
Interface VLAN 20
Description outside_vlan
VRF member OUTSIDE
IP address 20.1.1.254/24
IP router ospf 1 area 0
fabric forwarding mode anycast-gateway
interface nve1
no shutdown
host-reachability protocol bgp
source-interface loopback1
member vni 10010
mcastgroup 239.1.1.1
member vni 10020
mcastgroup 239.1.1.1
member vni 1001000 associate-vrf
member vni 1002000 associate-vrf
router ospf 1
router-id 192.168.1.1
vrf INSIDE
VRF OUTSIDE
VTEPA# show ip route ospf-1 vrf OUTSIDE
IP Route Table for VRF "OUTSIDE"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.1.1.0/24, ubest/mbest: 1/0
*via 20.1.1.1 Vlan20, [110/41], 1w5d, ospf-1, intra
VTEPA# show ip route ospf-1 vrf INSIDE
IP Route Table for VRF "INSIDE"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
20.1.1.0/24, ubest/mbest: 1/0
*via 10.1.1.1 Vlan10, [110/41], 1w5d, ospf-1, intra
This route is then redistributed into BGP and advertised through the EVPN fabric so that all other VTEPs have all routes in
each VRF pointing to VTEP A as the next hop.
Redistribute OSPF Routes into BGP and Advertise to the Rest of the Fabric
Traffic is VXLAN encapsulated from VTEP to services VTEP and decapsulated and sent to the firewall. The firewall enforces
the rules and sends the traffic to the services VTEP on the inside VRF. This traffic is then VXLAN encapsulated and sent to
the destination VTEP where traffic is decapsulated and sent to the end client.
Firewall Failover
When the active firewall fails and the standby firewall takes over, routes are withdrawn from service VTEP A and advertised
to the fabric by service VTEP B.
Dual-Attached Firewall with OSPF
Cisco NX-OS supports dynamic OSPF peering over vPC using Layer 3, which enables firewall connectivity using vPC and establishes
OSPF peering over this link. The VLAN used to establish peering between the Cisco Nexus 9000 switches and the firewall must
be a non-VXLAN-enabled VLAN.
Figure 5. Dual-Attached Firewall with OSPF
Note
Do not use Anycast Gateway for OSPF adjacencies.
VTEP A:
Vlan 10
Name inside
Vlan 20
Name outside
Interface VLAN 10
Description inside_vlan
VRF member INSIDE
IP address 10.1.1.253/24
Ip router ospf 1 area 0
Interface VLAN 20
Description outside_vlan
VRF member OUTSIDE
IP address 20.1.1.253/24
Ip router ospf 1 area 0
vpc domain 100
layer3 peer-router
peer-gateway
peer-switch
peer-keepalive destination x.x.x.x source x.x.x.x peer-gateway
ipv6 nd synchronize
ip arp synchronize
router ospf 1
vrf INSIDE VRF OUTSIDE
VTEP B:
Vlan 10
Name inside
Vlan 20
Name outside
Interface VLAN 10
Description inside_vlan
VRF member INSIDE
IP address 10.1.1.254/24
Ip router ospf 1 area 0
Interface VLAN 20
Description outside_vlan
VRF member OUTSIDE
IP address 20.1.1.254/24
Ip router ospf 1 area 0
vpc domain 100
layer3 peer-router
peer-gateway
peer-switch
peer-keepalive destination x.x.x.x source x.x.x.x peer-gateway
ipv6 nd synchronize
ip arp synchronize
router ospf 1
vrf INSIDE VRF OUTSIDE
VTEPA# show ip route ospf-1 vrf OUTSIDE
IP Route Table for VRF "OUTSIDE"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.1.1.0/24, ubest/mbest: 1/0
*via 20.1.1.1 Vlan20, [110/41], 1w5d, ospf-1, intra
VTEPA# show ip route ospf-1 vrf INSIDE
IP Route Table for VRF "INSIDE"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
20.1.1.0/24, ubest/mbest: 1/0
*via 10.1.1.1 Vlan10, [110/41], 1w5d, ospf-1, intra
Redistribute OSPF Routes into BGP and Advertise to the Rest of the Fabric
In this deployment model, the VXLAN fabric is a Layer 2 fabric, and the default gateway resides on the firewall.
For example:
vlan 10
name WEB
vn-segment 10010
vlan 20
name APPLICATION
vn-segment 10020
vlan 30
name DATABASE
vn-segment 10030
interface nve1
no shutdown
host-reachability protocol bgp
source-interface loopback1
member vni 10010
mcastgroup 239.1.1.1
member vni 10020
mcastgroup 239.1.1.1
member vni 10030
mcastgroup 239.1.1.1
The firewall has a logical interface in each VNI and is the default gateway for all endpoints. Every inter-VNI communication
flows through the firewall. Take special care with the sizing of the firewall so that it does not become a bottleneck. Therefore,
use this design in environments with low-bandwidth requirements.
Figure 6. Firewall as Default Gateway with a Layer-2 VXLAN Fabric
Transparent Firewall Insertion
Transparent firewalls or Layer 2 firewalls (including IPS/IDS) typically bridge between an inside VLAN and outside VLAN and
inspect traffic as it traverses through them. VLAN stitching is done by placing the default gateway for the service on the
inside VLAN. The Layer 2 reachability to this gateway is done on the outside VLAN.
Overview of EVPN with Transparent Firewall Insertion
The topology contains the following types of VLANs:
Internal VLAN (a regular VXLAN on ToR leafs with Anycast Gateway)
Firewall untrusted VLAN X
Firewall trusted VLAN Y
In this topology, the traffic that goes from VLAN X to other VLANs must go through a transparent Layer 2 firewall that is
attached to the service leafs. This topology utilizes an approach of an untrusted VLAN X and a trusted VLAN Y. All ToR leafs
have a Layer 2 VNI VLAN X. There is no SVI for VLAN X. The service leafs that are connected to the firewall have Layer 2 VNI
VLAN X, non-VXLAN VLAN Y, and SVI Y with an HSRP gateway.
Overview of EVPN with Transparent Firewall Insertion
Note
For VXLAN EVPN, we recommend using the distributed Anycast Gateway with transparent firewall insertion. Doing so allows all
VLANs to be VXLAN enabled. When using an HSRP/VRRP-based First-Hop Gateway, the VLAN for the SVI can't be VXLAN enabled and
should reside on a vPC pair for redundancy.
EVPN with Transparent Firewall Insertion Example
Example of EVPN with Transparent Firewall Insertion
vlan 94
description untrusted_vlan
vn-segment 100094
vlan 95
description trusted_vlan
vpc domain 10
peer-switch
peer-keepalive destination 10.1.59.160
peer-gateway
auto-recovery
ip arp synchronize
interface Vlan2
description vpc_backup_svi_for_overlay
no shutdown
no ip redirects
ip address 10.10.60.17/30
no ipv6 redirects
ip router ospf 100 area 0.0.0.0
ip ospf bfd
ip pim sparsemode
interface Vlan95
description SVI_for_trusted_vlan
no shutdown
mtu 9216
vrf member Ten-1
no ip redirects
ip address 10.0.94.2/24
hsrp 0
preempt priority 255
ip 10.0.94.1
interface nve1
member vni 100094
mcast-group 239.1.1.1
router bgp 64500
routerid 1.1.2.1
neighbor 1.1.1.1 remote-as 64500
address-family l2vpn evpn
send-community extended
neighbor 1.1.1.2 remote-as 64500
address-family l2vpn evpn
send-community extended
vrf Ten-1
address-family ipv4 unicast
network 10.0.94.0/24 /*advertise /24 for SVI 95 subnet; it is not VXLAN anymore*/
advertise l2vpn evpn
evpn
vni 100094 l2
rd auto
route-target import auto
route-target export auto
Service Leaf 2 Configuration Using HSRP
vlan 94
description untrusted_vlan
vnsegment 100094
vlan 95
description trusted_vlan
vpc domain 10
peer-switch
peer-keepalive destination 10.1.59.159
peer-gateway
auto-recovery
ip arp synchronize
interface Vlan2
description vpc_backup_svi_for_overlay
no shutdown
no ip redirects
ip address 10.10.60.18/30
no ipv6 redirects
ip router ospf 100 area 0.0.0.0
ip pim sparsemode
interface Vlan95
description SVI_for_trusted_vlan
no shutdown
mtu 9216
vrf member Ten-1
no ip redirects
ip address 10.0.94.3/24
hsrp 0
preempt priority 255
ip 10.0.94.1
interface nve1
member vni 100094
mcastgroup 239.1.1.1
router bgp 64500
router-id 1.1.2.1
neighbor 1.1.1.1 remote-as 64500
address-family l2vpn evpn
send-community extended
neighbor 1.1.1.2 remote-as 64500
address-family l2vpn evpn
send-community extended
vrf Ten-1
address-family ipv4 unicast
network 10.0.94.0/24 /*advertise /24 for SVI 95 subnet; it is not VXLAN anymore*/
advertise l2vpn evpn
evpn
vni 100094 l2
rd auto
route-target import auto
route-target export auto
Show Command Examples
Display information about the ingress leaf learned local MAC from host:
switch# sh mac add vl 94 | i 5b|MAC
* primary entry, G - Gateway MAC, (R) Routed - MAC, O - Overlay MAC
VLAN MAC Address Type age Secure NTFY Ports
* 94 d8b1.9071.5beb dynamic 0 F F Eth1/1
Display information about the service leaf found MAC of host:
Note
In VLAN 94, the service leaf learned the host MAC from the remote peer by BGP.
switch# sh mac add vl 94 | i VLAN|eb
VLAN MAC Address Type age Secure NTFY Ports
* 94 d8b1.9071.5beb dynamic 0 F F nve1(1.1.2.1)
switch# sh mac add vl 94 | i VLAN|eb
VLAN MAC Address Type age Secure NTFY Ports
* 94 d8b1.9071.5beb dynamic 0 F F nve1(1.1.2.1)
switch# sh mac add vl 95 | i VLAN|eb
VLAN MAC Address Type age Secure NTFY Ports
+ 95 d8b1.9071.5beb dynamic 0 F F Po300
switch# sh mac add vl 95 | i VLAN|eb
VLAN MAC Address Type age Secure NTFY Ports
+ 95 d8b1.9071.5beb dynamic 0 F F Po300
Display information about service leaf learned ARP for host on VLAN 95:
switch# sh ip arp vrf ten-1
Address Age MAC Address Interface
10.0.94.101 00:00:26 d8b1.9071.5beb Vlan95
Service Leaf learns 9.9.9.9 from EVPN.
switch# sh ip route vrf ten-1 9.9.9.9
IP Route Table for VRF "Ten-1"
'*' denotes best ucast nexthop
'**' denotes best mcast nexthop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
9.9.9.9/32, ubest/mbest: 1/0
*via 1.1.2.7%default, [200/0], 02:57:27, bgp64500,internal, tag 65000 (evpn) segid: 10011
tunnelid: 0x1
010207 encap: VXLAN
Display information about the border leaf learned host routes by BGP:
switch# sh ip route 10.0.94.101
IP Route Table for VRF "default"
'*' denotes best ucast nexthop
'**' denotes best mcast nexthop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.0.94.0/24, ubest/mbest: 1/0
*via 10.100.5.0, [20/0], 03:14:27, bgp65000,external, tag 6450
Feedback