Configure Service VRF EVPN VxLAN on Catalyst 9000 Switches

Available Languages

Download Options

PDF (732.8 KB)
View with Adobe Reader on a variety of devices
ePub (735.3 KB)
View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle) (508.7 KB)
View on Kindle device or Kindle app on multiple devices

Updated:February 7, 2023

Document ID:220205

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.

Introduction

This document describes the route-leaking configuration for EVPN (Ethernet VPN) VXLAN (Virtual Extensible LAN) in different scenarios.

Prerequisites

It is recommended that you are familiar with Unicast EVPN VxLAN feature, BGP.

Requirements

This guide assumes BGP, NVE peers are already correct. If there are issues with basic EVPN VxLAN bring up (Unicast ping failure, BGP, NVE peers down, and so on) please reference BGP, EVPN, route/switch troubleshoot guides as necessary.

Note: Service VRF configuration examples are supported for IPv4 only.

Components Used

The information in this document is based on these software and hardware versions:

C9300
C9400
C9500
C9600

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Note: Consult the appropriate configuration guide for the commands that are used in order to enable these features on other Cisco platforms.

Configure

The route-leaking feature is widely used in the case of building “Shared VRF” services or connection of Border nodes to the firewall. Usually, Border Leafs are the nodes where route-leaking is configured.

The route-leaking between VRFs for EVPN/VXLAN on Cisco IOS® XE is not performed at the BGP level as usual. EVN (Easy Virtual Network) feature is used instead.

Network Diagram

Service VRF network diagram

Generic Route Leaking

In this example, route-leaking from VRF “green” and “blue” to VRF “vrf-service” planned be configured on the Border node.

Check the routing table for VRF “green” and “blue” on the Border:

Border#show ip route vrf green

<…snip…>

      10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B        10.1.1.0/24 [200/0] via 172.16.254.3, 01:19:43, Vlan901
B        10.1.2.0/24 [200/0] via 172.16.254.3, 01:19:43, Vlan901
B        10.255.1.11/32 [200/0] via 172.16.254.3, 01:19:43, Vlan901
B        10.255.1.12/32 [200/0] via 172.16.254.4, 01:19:43, Vlan901
C        10.255.1.13/32 is directly connected, Loopback11

Border#show ip route vrf blue

<…snip…>

      10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B        10.2.1.0/24 [200/0] via 172.16.254.3, 01:20:28, Vlan902
B        10.2.2.0/24 [200/0] via 172.16.254.3, 01:20:28, Vlan902
B        10.255.2.11/32 [200/0] via 172.16.254.3, 01:20:28, Vlan902
B        10.255.2.12/32 [200/0] via 172.16.254.4, 01:20:28, Vlan902
C        10.255.2.13/32 is directly connected, Loopback12

Configuration to import all routes from the VRF “green” to VRF “vrf-service”

vrf definition vrf-service
 rd 3:3
 !
 address-family ipv4
  route-replicate from vrf green unicast all
  route-target export 3:3
  route-target import 3:3
 exit-address-family

Verify routing table of the VRF "vrf-service" on the Border contains routes from VRF “green”

Border#show ip route vrf vrf-service

Routing Table: vrf-service
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
       n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       H - NHRP, G - NHRP registered, g - NHRP registration summary
       o - ODR, P - periodic downloaded static route, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR
       & - replicated local route overrides by connected

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
B   +    10.1.1.0/24 [200/0] via 172.16.254.3, 00:00:42, Vlan901 
B   +    10.1.1.11/32 [200/0] via 172.16.254.3, 00:00:28, Vlan901 
B   +    10.255.1.11/32 [200/0] via 172.16.254.3, 01:32:49, Vlan901 
B   +    10.255.1.12/32 [200/0] via 172.16.254.4, 01:32:49, Vlan901 
C   +    10.255.1.13/32 is directly connected, Loopback11
C        10.255.3.13/32 is directly connected, Loopback13

Observe that routes from VRF “green” are replicated to the VRF “vrf-service” and marked in the routing table with “+”.

Route Leaking with Filtering

Route replication can be done with filtering. Route-maps are used for this purpose.

Replicate only prefix 10.255.2.12 from VRF “blue” to VRF “vrf-service”.

ip prefix-list PL-BLUE-2-VRF-SERVICE permit 10.255.2.12/32
!
route-map RM-BLUE-2-VRF-SERVICE permit 10 
 match ip adderess prefix-list PL-BLUE-2-VRF-SERVICE

Configure the replication with filter

vrf definition vrf-service
 rd 3:3
 !
 address-family ipv4
  route-replicate from vrf green unicast all
  route-replicate from vrf blue unicast all route-map RM-BLUE-2-VRF-SERVICE
  route-target export 3:3
  route-target import 3:3
exit-address-family

Observe the routing table for VRF “vrf-service” contains the prefix 10.255.2.12/32 originating in the VRF “blue”:

Border#show ip route vrf VRF-SERVICE

<…snip…>

      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
B   +    10.1.1.0/24 [200/0] via 172.16.254.3, 00:09:38, Vlan901
B   +    10.1.1.11/32 [200/0] via 172.16.254.3, 00:09:24, Vlan901
B   +    10.255.1.11/32 [200/0] via 172.16.254.3, 01:41:45, Vlan901
B   +    10.255.1.12/32 [200/0] via 172.16.254.4, 01:41:45, Vlan901
C   +    10.255.1.13/32 is directly connected, Loopback11
B   +    10.255.2.12/32 [200/0] via 172.16.254.4, 01:41:45, Vlan902 <-- 
C        10.255.3.13/32 is directly connected, Loopback13

Default Route Advertisement Only & Track of Default Route

Connectivity between hosts connected to Leafs with an external network is built over the Border.

Usually, Border receives default route only or default route plus summary routes.
To optimize of the routing table on Leafs, it is possible to advertise only the default route from the Border.

The default route is received in VRF “vrf-service”/”Shared service”.

This route could be replicated into VRF “green” but replicated route cannot be re-advertised. It is required to configure the default route advertisement in BGP for VRF “green”.
The static route with track object can be configured to avoid a blackhole situation when the default route in VRF “green” is advertised, but the default route in VRF “vrf-serrvice” is not present.

Review the topology

Default-Route Advertisement Only with Track

Verify the default route is received on the Border Node:

Border#show ip route vrf vrf-service 0.0.0.0

Routing Table: red
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 65001", distance 20, metric 0, candidate default path
  Tag 65002, type external
  Last update from 192.168.3.2 00:13:32 ago
  Routing Descriptor Blocks:
  * 192.168.3.2, from 192.168.3.2, 00:13:32 ago
      opaque_ptr 0x7FA2A139FE50 
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65002
      MPLS label: none

Border#show ip cef vrf vrf-service 0.0.0.0/0 
0.0.0.0/0 
  nexthop 192.168.3.2 TenGigabitEthernet1/0/5.3903

Track 1 checks reachability of the default route in the VRF “vrf-service”.

track 1 ip route 0.0.0.0 0.0.0.0 reachability
 ip vrf vrf-service

Verify the default route is present in the VRF “vrf-service” and the track object is “Up”.

Border#show track 1
Track 1
  IP route 0.0.0.0 0.0.0.0 reachability
  Reachability is Up (BGP)
    2 changes, last change 00:23:12
  VPN Routing/Forwarding table "vrf-service"
  First-hop interface is TenGigabitEthernet1/0/5.3903
  Tracked by:
    Static IP Routing 0

Configure the default route in the VRF “green” with track option

!
ip route vrf green 0.0.0.0 0.0.0.0 TenGigabitEthernet1/0/5.3903 192.168.3.2 track 1
!

Border#show ip route vrf green 0.0.0.0

Routing Table: green
Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 1, metric 0, candidate default path
  Redistributing via bgp 65001
  Advertised by bgp 65001
  Routing Descriptor Blocks:
  * 192.168.3.2, via TenGigabitEthernet1/0/5.3903
      Route metric is 0, traffic share count is 1

Default route advertisement is configured under BGP process for the VRF “green”

router bgp 65001
!
<...snip...>
 !
 address-family ipv4 vrf green
  advertise l2vpn evpn
  redistribute static
  redistribute connected
  default-information originate
 exit-address-family
!
<...snip...>

Verify default route is advertised to L2VPN EVPN AF like route-type 5 and propagated over the fabric

Border#show bgp l2vpn evpn rd 1:1 route-type 5 0 0.0.0.0 0
BGP routing table entry for [5][1:1][0][0][0.0.0.0]/17, version 622
Paths: (1 available, best #1, table EVPN-BGP-Table)
  Advertised to update-groups:
     2         
  Refresh Epoch 1
  Local, imported path from base
    192.168.3.2 (via vrf red) from 0.0.0.0 (172.16.255.6)
      Origin incomplete, metric 0, localpref 100, weight 32768, valid, external, best
      EVPN ESI: 00000000000000000000, Gateway Address: 0.0.0.0, local vtep: 172.16.254.6, VNI Label 50901, MPLS VPN Label 27
      Extended Community: RT:1:1 ENCAP:8 Router MAC:0C75.BD67.EF48
      rx pathid: 0, tx pathid: 0x0
      Updated on Jul 8 2022 10:41:40 UTC

Check EVPN, routing, cef information on Leaf-01

Leaf-01#show bgp l2vpn evpn rd 1:1 route-type 5 0 0.0.0.0 0
BGP routing table entry for [5][1:1][0][0][0.0.0.0]/17, version 595
Paths: (2 available, best #2, table EVPN-BGP-Table)
  Not advertised to any peer
  Refresh Epoch 7
  Local
    172.16.254.6 (metric 3) (via default) from 172.16.255.2 (172.16.255.2)
      Origin incomplete, metric 0, localpref 100, valid, internal
      EVPN ESI: 00000000000000000000, Gateway Address: 0.0.0.0, VNI Label 50901, MPLS VPN Label 0
      Extended Community: RT:1:1 ENCAP:8 Router MAC:0C75.BD67.EF48
      Originator: 172.16.255.6, Cluster list: 172.16.255.2
      rx pathid: 0, tx pathid: 0
      Updated on Jul 8 2022 10:41:40 UTC
  Refresh Epoch 7
  Local
    172.16.254.6 (metric 3) (via default) from 172.16.255.1 (172.16.255.1)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      EVPN ESI: 00000000000000000000, Gateway Address: 0.0.0.0, VNI Label 50901, MPLS VPN Label 0
      Extended Community: RT:1:1 ENCAP:8 Router MAC:0C75.BD67.EF48
      Originator: 172.16.255.6, Cluster list: 172.16.255.1
      rx pathid: 0, tx pathid: 0x0
      Updated on Jul 8 2022 10:41:40 UTC

Leaf-01#show ip route vrf green 0.0.0.0

Routing Table: green
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 65001", distance 200, metric 0, candidate default path, type internal
  Last update from 172.16.254.6 on Vlan901, 02:07:17 ago
  Routing Descriptor Blocks:
  * 172.16.254.6 (default), from 172.16.255.1, 02:07:17 ago, via Vlan901
      opaque_ptr 0x7FC3606F4D80 
      Route metri c is 0, traffic share count is 1
      AS Hops 0
      MPLS label: none

Leaf-01#show ip cef vrf green 0.0.0.0/0
0.0.0.0/0
  nexthop 172.16.254.6 Vlan901

The reverse route from the Fabric to the External network is originated from BGP like a summary route

!
ip route vrf vrf-service 10.0.0.0 255.0.0.0 Null0
!
router bgp 65001
<…snip…>
!
address-family ipv4 vrf vrf-service
  advertise l2vpn evpn
  aggregate-address 10.0.0.0 255.0.0.0 summary-only
  redistribute static
  redistribute connected
  neighbor 192.168.3.2 remote-as 65002
  neighbor 192.168.3.2 activate
 exit-address-family
!
<…snip…>

Check the routing table on the Leaf-01 in the VRF “green” and ping remote IP address 192.168.255.1

Leaf-01#show ip route vrf green 192.168.255.1                                                                                                                                             

Routing Table: green
% Network not in table

Leaf-01#show ip route vrf green 0.0.0.0  

Routing Table: green
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 65001", distance 200, metric 0, candidate default path, type internal
  Last update from 172.16.254.6 on Vlan901, 05:15:19 ago
  Routing Descriptor Blocks:
  * 172.16.254.6 (default), from 172.16.255.1, 05:15:19 ago, via Vlan901
      opaque_ptr 0x7FC3606F4D80 
      Route metric is 0, traffic share count is 1
      AS Hops 0
      MPLS label: none

Leaf-01#show ip cef vrf green 0.0.0.0/0
0.0.0.0/0
  nexthop 172.16.254.6 Vlan901 

Leaf-01#ping vrf green 192.168.3.2 source 10.255.1.11             
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.2, timeout is 2 seconds:
Packet sent with a source address of 10.255.1.11 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

If the default route is lost on the Border in the VRF “vrf-service” the track object goes down, the static route in the VRF “green” is removed from the RIB, and the default route advertised in the BGP is removed

### Border ###
Border#show ip route vrf vrf-service 0.0.0.0  

Routing Table: vrf-service
% Network not in table

Border#show track 1
Track 1
  IP route 0.0.0.0 0.0.0.0 reachability
  Reachability is Down (no ip route)     <-- Track object is down
    3 changes, last change 00:03:15
  VPN Routing/Forwarding table "vrf-service"
  First-hop interface is unknown
  Tracked by:
    Static IP Routing 0

Border#show ip route vrf green 0.0.0.0

Routing Table: green
% Network not in table

Border#show bgp l2vpn evpn rd 1:1 route-type 5 0 0.0.0.0 0
% Network not in table

### Leaf ###
Leaf-01#show ip route vrf green 0.0.0.0

Routing Table: green
% Network not in table

The default route from the VRF “green” to the VRF “vrf-service” must be filtered

vrf definition vrf-service
 rd 3:3
 !
 address-family ipv4
  route-replicate from vrf green unicast all route-map RM-GREEN-2-VRF-SERVICE
  route-target export 3:3
  route-target import 3:3
 exit-address-family

ip prefix-list PL-DEFAULT seq 5 permit 0.0.0.0/0
!
route-map RM-GREEN-2-VRF-SERVICE deny 10 
 match ip address prefix-list PL-DEFAULT
!
route-map RM-GREEN-2-VRF-SERVICE permit 20

Caution: Because of the delay between lost the default route and the track object goes down, the static default route is replicated from VRF “green” to the VRF “vrf-service” and keep the track object up. As a result, the default route is advertised to the Fabric and blackhole the traffic.

Default Route Advertisement Only with Redundant Borders

This section provided an example case where redundant borders are used.

Note: In this example we used BGP additional-path feature. Another option is to use different RD on the Border-01 and Border-02 could be used for advertising BOTH default routes from both Borders to the Leafs.

Review the topology

Redundant Borders

Both Border-01 and Border-02 receives default route from EXT-01 and EXT-02 respectively.

From Border-01

Border-01#show ip route vrf vrf-service 0.0.0.0  

Routing Table: vrf-service
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 65001", distance 20, metric 0, candidate default path
  Tag 65002, type external
  Last update from 192.168.3.2 00:00:06 ago
  Routing Descriptor Blocks:
  * 192.168.3.2, from 192.168.3.2, 00:00:06 ago
      opaque_ptr 0x7F68E5AC02A0 
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65002
      MPLS label: none

Border-01#show ip cef vrf vrf-service 0.0.0.0/0
0.0.0.0/0
  nexthop 192.168.3.2 TenGigabitEthernet1/0/5.3903

From Border-02

Border-02#show ip route vrf vrf-service 0.0.0.0

Routing Table: vrf-service
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 65001", distance 20, metric 0, candidate default path
  Tag 65002, type external
  Last update from 192.168.4.2 01:22:08 ago
  Routing Descriptor Blocks:
  * 192.168.4.2, from 192.168.4.2, 01:22:08 ago
      opaque_ptr 0x7FE529FF3D48 
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65002
      MPLS label: none

Border-02#show ip cef vrf vrf-service 0.0.0.0/0
0.0.0.0/0
  nexthop 192.168.4.2 TenGigabitEthernet1/0/5.3904

The same approach is used in dual Border configuration like in previous example - static default route with tracking.

Configure Border-01/02 track, static route for the default in vrf "green", bgp config for advertisement.

track 1 ip route 0.0.0.0 0.0.0.0 reachability
 ip vrf vrf-service
!
ip route vrf green 0.0.0.0 0.0.0.0 TenGigabitEthernet1/0/5.3903 192.168.3.2 track 1
!
router bgp 65001
!
<...snip...>
 !
 address-family ipv4 vrf green
  advertise l2vpn evpn
  redistribute static
  redistribute connected
  default-information originate
 exit-address-family
!
<...snip...>

Verify on Spines that default routes from both Borders are received

Spine-01#show bgp l2vpn evpn                         
BGP table version is 25, local router ID is 172.16.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1
 * ia [5][1:1][0][0][0.0.0.0]/17
                      172.16.254.7             0    100      0 ?
 *>i                   172.16.254.6             0    100      0 ?
 * i                   172.16.254.6             0    100      0 ?
<...snip...>

Spine-02#show bgp l2vpn evpn 
BGP table version is 75, local router ID is 172.16.255.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1
 * i  [5][1:1][0][0][0.0.0.0]/17
                      172.16.254.6             0    100      0 ?
 * ia                  172.16.254.7             0    100      0 ?
 *>i                   172.16.254.6             0    100      0 ?
<...snip...>

Configure on Spines to propagate BOTH default routes BGP additional-path

router bgp 65001
!
<...snip...>
!
 address-family l2vpn evpn
  bgp additional-paths select all best 2
  bgp additional-paths send receive
<...snip...>
  neighbor 172.16.255.3 advertise additional-paths best 2
<...snip...>
  neighbor 172.16.255.4 advertise additional-paths best 2
!
<...snip...>

Observe this configuration changes the default best-only propagation and instead advertises BOTH routes

Spine-01#show bgp l2vpn evpn neighbors 172.16.255.3 advertised-routes 
BGP table version is 25, local router ID is 172.16.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1
 *>i  [5][1:1][0][0][0.0.0.0]/17
                      172.16.254.6             0    100      0 ? <-- best path
 * ia [5][1:1][0][0][0.0.0.0]/17
                      172.16.254.7             0    100      0 ? <-- addtional path (note the a flag indicating this)
<...snip...>

Observe on the Leaf we see 4 BGP default routes

Leaf-01#sh bgp l2vpn evpn 
BGP table version is 63, local router ID is 172.16.255.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf green)
 * i  [5][1:1][0][0][0.0.0.0]/17
                      172.16.254.7             0    100      0 ?
 * ia                  172.16.254.7             0    100      0 ?
 *>i                   172.16.254.6             0    100      0 ?
 * i                   172.16.254.6             0    100      0 ?
<...snip...>

Leaf-01#sh bgp l2vpn evpn route-type 5 0 0.0.0.0 0
BGP routing table entry for [5][1:1][0][0][0.0.0.0]/17, version 64
Paths: (4 available, best #3, table EVPN-BGP-Table)
  Not advertised to any peer
  Refresh Epoch 4
  Local
    172.16.254.7 (metric 3) (via default) from 172.16.255.2 (172.16.255.2)
      Origin incomplete, metric 0, localpref 100, valid, internal
      EVPN ESI: 00000000000000000000, Gateway Address: 0.0.0.0, VNI Label 50901, MPLS VPN Label 0
      Extended Community: RT:1:1 ENCAP:8 Router MAC:0C75.BD68.E548
      Originator: 172.16.255.7, Cluster list: 172.16.255.2
      rx pathid: 0x1, tx pathid: 0
      Updated on Aug 24 2022 16:52:56 UTC
  Refresh Epoch 1
  Local
    172.16.254.7 (metric 3) (via default) from 172.16.255.1 (172.16.255.1)
      Origin incomplete, metric 0, localpref 100, valid, internal
      EVPN ESI: 00000000000000000000, Gateway Address: 0.0.0.0, VNI Label 50901, MPLS VPN Label 0
      Extended Community: RT:1:1 ENCAP:8 Router MAC:0C75.BD68.E548
      Originator: 172.16.255.7, Cluster list: 172.16.255.1
      rx pathid: 0x1, tx pathid: 0
      Updated on Aug 24 2022 16:49:48 UTC
  Refresh Epoch 1
  Local
    172.16.254.6 (metric 3) (via default) from 172.16.255.1 (172.16.255.1)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      EVPN ESI: 00000000000000000000, Gateway Address: 0.0.0.0, VNI Label 50901, MPLS VPN Label 0
      Extended Community: RT:1:1 ENCAP:8 Router MAC:0C75.BD67.EF48
      Originator: 172.16.255.6, Cluster list: 172.16.255.1
      rx pathid: 0x0, tx pathid: 0x0
      Updated on Aug 24 2022 16:49:48 UTC
  Refresh Epoch 4
  Local
    172.16.254.6 (metric 3) (via default) from 172.16.255.2 (172.16.255.2)
      Origin incomplete, metric 0, localpref 100, valid, internal
      EVPN ESI: 00000000000000000000, Gateway Address: 0.0.0.0, VNI Label 50901, MPLS VPN Label 0
      Extended Community: RT:1:1 ENCAP:8 Router MAC:0C75.BD67.EF48
      Originator: 172.16.255.6, Cluster list: 172.16.255.2
      rx pathid: 0x0, tx pathid: 0
      Updated on Aug 24 2022 16:52:56 UTC

Configuration on the Leaf is shown here

router bgp 65001
!
<...snip...>
!
 address-family l2vpn evpn
  bgp additional-paths receive
<...snip...>
!
 address-family ipv4 vrf green
  import path selection all
  maximum-paths ibgp 2
<...snip...>

Verify on the Leaf routing table we see two routes to both Borders

Leaf-01#show ip route vrf green

Routing Table: green
<...snip...>

Gateway of last resort is 172.16.254.7 to network 0.0.0.0

B*    0.0.0.0/0 [200/0] via 172.16.254.7, 00:02:15, Vlan901
                [200/0] via 172.16.254.6, 00:02:15, Vlan901
<...snip...>

Leaf-01#show ip cef vrf green 0.0.0.0/0
0.0.0.0/0
  nexthop 172.16.254.6 Vlan901
  nexthop 172.16.254.7 Vlan901

Observe what happens in case of lost of the default route from Border-01.

Border-01#show ip route vrf vrf-service 0.0.0.0

Routing Table: vrf-service
% Network not in table

Track goes down

Border-01#show track 1
Track 1
  IP route 0.0.0.0 0.0.0.0 reachability
  Reachability is Down (no ip route)
    5 changes, last change 00:00:56
  VPN Routing/Forwarding table "vrf-service"
  First-hop interface is unknown
  Tracked by:
    Static IP Routing 0

On the Spines we see route only from Border-02

Spine-01#show bgp l2vpn evpn                                            
BGP table version is 27, local router ID is 172.16.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1
 * i  [5][1:1][0][0][0.0.0.0]/17
                      172.16.254.7             0    100      0 ?
 *>i                   172.16.254.7             0    100      0 ?
<...snip...>

On the Leaf we see route only from Border-02

Leaf-01#show bgp l2vpn evpn 
BGP table version is 68, local router ID is 172.16.255.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf green)
 *>i  [5][1:1][0][0][0.0.0.0]/17
                      172.16.254.7             0    100      0 ?
 * i                   172.16.254.7             0    100      0 ?
<...snip...>

Leaf-01#sh bgp l2vpn evpn route-type 5 0 0.0.0.0 0
BGP routing table entry for [5][1:1][0][0][0.0.0.0]/17, version 68
Paths: (2 available, best #1, table EVPN-BGP-Table)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    172.16.254.7 (metric 3) (via default) from 172.16.255.1 (172.16.255.1)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      EVPN ESI: 00000000000000000000, Gateway Address: 0.0.0.0, VNI Label 50901, MPLS VPN Label 0
      Extended Community: RT:1:1 ENCAP:8 Router MAC:0C75.BD68.E548
      Originator: 172.16.255.7, Cluster list: 172.16.255.1
      rx pathid: 0x0, tx pathid: 0x0
      Updated on Aug 24 2022 17:17:31 UTC
  Refresh Epoch 4
  Local
    172.16.254.7 (metric 3) (via default) from 172.16.255.2 (172.16.255.2)
      Origin incomplete, metric 0, localpref 100, valid, internal
      EVPN ESI: 00000000000000000000, Gateway Address: 0.0.0.0, VNI Label 50901, MPLS VPN Label 0
      Extended Community: RT:1:1 ENCAP:8 Router MAC:0C75.BD68.E548
      Originator: 172.16.255.7, Cluster list: 172.16.255.2
      rx pathid: 0x0, tx pathid: 0
      Updated on Aug 24 2022 17:17:31 UTC

Only one route is present in the routing table and in CEF on the Leaf-01

Leaf-01#show ip route vrf green                   

Routing Table: green
<...snip...>

Gateway of last resort is 172.16.254.7 to network 0.0.0.0

B*    0.0.0.0/0 [200/0] via 172.16.254.7, 00:04:02, Vlan901
<...snip...>

Leaf-01#show ip cef vrf green 0.0.0.0/0
0.0.0.0/0
  nexthop 172.16.254.7 Vlan901

Related Information

Revision History

Revision	Publish Date	Comments
1.0	08-Feb-2023	Initial Release

Contributed by

Dmytro Vishchuk

Was this Document Helpful?

Feedback

Contact Cisco

Open a Support Case
(Requires a Cisco Service Contract)