Skip to content

Interpreting VXLAN EVPN BGP Output - Type-5 Routes

The BGP output from a show bgp l2vpn evpn command is normally very long and sometimes confusing to understand. In this guide, I will walk through a sample output of a type-5 route and show why we get all the output and what it means.

Before reading this, it implies that you understand what route distinguishers and route targets are in relation to BGP and how they are used. Without background knowledge of these constructs, it may be hard(er) to follow.

A type-5 route is an IP prefix based route, it is essentially an encapsulated version of a normal ipv4/ipv6 AFI BGP route.

In this example, I have two border leaves which connect outside of the fabric. These are sending a default 0.0.0.0/0 route back into the fabric which is being advertised to the fabric via an external firewall. All of this lives inside a VRF called OVERLAY-TENANT1 in an L3VNI vni-100999.

The topology has vPC switches and 2 spines acting as route reflectors.

This is the full output we get:

LEAF-5# show bgp l2vpn evpn 0.0.0.0
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.0.0.5:4
BGP routing table entry for [5]:[0]:[0]:[0]:[0.0.0.0]/224, version 382
Paths: (2 available, best #2)
Flags: (0x000002) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not in HW

  Path type: internal, path is valid, not best reason: Neighbor Address, no labeled nexthop
  Gateway IP: 0.0.0.0
  AS-Path: 64520 , path sourced external to AS
    10.0.1.3 (metric 81) from 10.0.0.2 (10.0.0.2)
      Origin incomplete, MED not set, localpref 100, weight 0
      Received label 100999
      Extcommunity: RT:64500:100999 SOO:64500:102 ENCAP:8 Router MAC:5005.0000.1b08
      Originator: 10.0.0.5 Cluster list: 10.0.0.2 

  Advertised path-id 1
  Path type: internal, path is valid, is best path, no labeled nexthop
             Imported to 2 destination(s)
             Imported paths list: OVERLAY-TENANT1 L3-100999
  Gateway IP: 0.0.0.0
  AS-Path: 64520 , path sourced external to AS
    10.0.1.3 (metric 81) from 10.0.0.1 (10.0.0.1)
      Origin incomplete, MED not set, localpref 100, weight 0
      Received label 100999
      Extcommunity: RT:64500:100999 SOO:64500:102 ENCAP:8 Router MAC:5005.0000.1b08
      Originator: 10.0.0.5 Cluster list: 10.0.0.1 

  Path-id 1 not advertised to any peer

Route Distinguisher: 10.0.0.6:4
BGP routing table entry for [5]:[0]:[0]:[0]:[0.0.0.0]/224, version 187
Paths: (2 available, best #2)
Flags: (0x000002) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not in HW

  Path type: internal, path is valid, not best reason: Neighbor Address, no labeled nexthop
  Gateway IP: 0.0.0.0
  AS-Path: 64520 , path sourced external to AS
    10.0.1.4 (metric 81) from 10.0.0.2 (10.0.0.2)
      Origin incomplete, MED not set, localpref 100, weight 0
      Received label 100999
      Extcommunity: RT:64500:100999 SOO:64500:102 ENCAP:8 Router MAC:5006.0000.1b08
      Originator: 10.0.0.6 Cluster list: 10.0.0.2 

  Advertised path-id 1
  Path type: internal, path is valid, is best path, no labeled nexthop
             Imported to 2 destination(s)
             Imported paths list: OVERLAY-TENANT1 L3-100999
  Gateway IP: 0.0.0.0
  AS-Path: 64520 , path sourced external to AS
    10.0.1.4 (metric 81) from 10.0.0.1 (10.0.0.1)
      Origin incomplete, MED not set, localpref 100, weight 0
      Received label 100999
      Extcommunity: RT:64500:100999 SOO:64500:102 ENCAP:8 Router MAC:5006.0000.1b08
      Originator: 10.0.0.6 Cluster list: 10.0.0.1 

  Path-id 1 not advertised to any peer

Route Distinguisher: 10.0.0.7:4    (L3VNI 100999)
BGP routing table entry for [5]:[0]:[0]:[0]:[0.0.0.0]/224, version 367
Paths: (2 available, best #1)
Flags: (0x000002) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not in HW

  Advertised path-id 1
  Path type: internal, path is valid, is best path, no labeled nexthop
             Imported from 10.0.0.5:4:[5]:[0]:[0]:[0]:[0.0.0.0]/224 
  Gateway IP: 0.0.0.0
  AS-Path: 64520 , path sourced external to AS
    10.0.1.3 (metric 81) from 10.0.0.1 (10.0.0.1)
      Origin incomplete, MED not set, localpref 100, weight 0
      Received label 100999
      Extcommunity: RT:64500:100999 SOO:64500:102 ENCAP:8 Router MAC:5005.0000.1b08
      Originator: 10.0.0.5 Cluster list: 10.0.0.1 

  Path type: internal, path is valid, not best reason: Router Id, no labeled nexthop
             Imported from 10.0.0.6:4:[5]:[0]:[0]:[0]:[0.0.0.0]/224 
  Gateway IP: 0.0.0.0
  AS-Path: 64520 , path sourced external to AS
    10.0.1.4 (metric 81) from 10.0.0.1 (10.0.0.1)
      Origin incomplete, MED not set, localpref 100, weight 0
      Received label 100999
      Extcommunity: RT:64500:100999 SOO:64500:102 ENCAP:8 Router MAC:5006.0000.1b08
      Originator: 10.0.0.6 Cluster list: 10.0.0.1 

  Path-id 1 not advertised to any peer

The route itself is [5]:[0]:[0]:[0]:[0.0.0.0]/224

  • [5] - Route is type-5
  • [0] - IP Prefix to follow is a /0
  • [0.0.0.0] - IP Prefix
  • /224 - Length of the entry

Thats what a breakdown of the routing entry looks like. Though, its not very easy to tell with that route, here is another:

[5]:[0]:[0]:[16]:[10.2.0.0]/224

  • [5] - Route is type-5
  • [16] - IP Prefix to follow is a /16
  • [10.2.0.0] - IP Prefix
  • /224 - Length of the entry

First off, the routes are grouped into Route Distinguishers. This does exactly what it says, its allows the routes to be distinguished. I am using rd auto in this topology so it picks the RD for me.

We see the following RDs:

  • 10.0.0.5:4
  • 10.0.0.6:4
  • 10.0.0.7:4

When using rd auto and when talking about an L3VNI, the first part of the RD (before the : ) is the BGP router ID of the device it corresponds to. The other section (after the : ) is the local ID for the VRF its part of:

LEAF-5# show bgp evi 100999 | inc ID|RD|VRF
  L3VNI ID                     : 100999 (L3-100999)
  RD                           : 10.0.0.7:4
  Associated IP-VRF            : OVERLAY-TENANT1

This matches the above output which is for the L3VNI.

10.0.0.5 and 10.0.0.6 are the Border Leaves in the fabric, these devices are where the route actually comes from. Within those two RDs in the main output, we see two routes each, this is one from each Route Reflector, we can tell that by checking the Cluster list on the routes. This is an attribute that the RR adds to prevent it from learning its own routes, as using RRs bends the BGP loop prevention rules....shhhh.

The best route from the 10.0.0.5 and 10.0.0.6 RDs, both say they are Imported to 2 destination(s). One being the L3VNI itself and the other is the VRF for the tenant.

The route distinguisher for 10.0.0.7:4 can be considered the 'local' RD. Under that, we see the best routes from the 10.0.0.5 and 10.0.0.6 RDs. These say Imported from 10.0.0.X:4 on them to confirm this. BGP best path selects only one of the routes under 10.0.0.7:4 and that is pushed into the IP routing table for the VRF:

LEAF-5# show ip route 0.0.0.0 vrf OVERLAY-TENANT1
IP Route Table for VRF "OVERLAY-TENANT1"

0.0.0.0/0, ubest/mbest: 2/0
    *via 10.0.1.3%default, [200/0], 01:30:32, bgp-64500, internal, tag 64520, segid: 100999 tunnelid: 0xa000103 encap: VXLAN
    *via 10.0.1.4%default, [200/0], 02:56:26, bgp-64500, internal, tag 64520, segid: 100999 tunnelid: 0xa000104 encap: VXLAN

However, I have the maximum-paths ibgp 2 command under the VRF in BGP so I get both paths in the IPv4 Unicast table.

For the local RD routes:

Route Distinguisher: 10.0.0.7:4    (L3VNI 100999)
BGP routing table entry for [5]:[0]:[0]:[0]:[0.0.0.0]/224, version 367
Paths: (2 available, best #1)
Flags: (0x000002) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not in HW

  Advertised path-id 1
  Path type: internal, path is valid, is best path, no labeled nexthop
             Imported from 10.0.0.5:4:[5]:[0]:[0]:[0]:[0.0.0.0]/224 
  Gateway IP: 0.0.0.0
  AS-Path: 64520 , path sourced external to AS
    10.0.1.3 (metric 81) from 10.0.0.1 (10.0.0.1)
      Origin incomplete, MED not set, localpref 100, weight 0
      Received label 100999
      Extcommunity: RT:64500:100999 SOO:64500:102 ENCAP:8 Router MAC:5005.0000.1b08
      Originator: 10.0.0.5 Cluster list: 10.0.0.1 

  Path type: internal, path is valid, not best reason: Router Id, no labeled nexthop
             Imported from 10.0.0.6:4:[5]:[0]:[0]:[0]:[0.0.0.0]/224 
  Gateway IP: 0.0.0.0
  AS-Path: 64520 , path sourced external to AS
    10.0.1.4 (metric 81) from 10.0.0.1 (10.0.0.1)
      Origin incomplete, MED not set, localpref 100, weight 0
      Received label 100999
      Extcommunity: RT:64500:100999 SOO:64500:102 ENCAP:8 Router MAC:5006.0000.1b08
      Originator: 10.0.0.6 Cluster list: 10.0.0.1 

  Path-id 1 not advertised to any peer

We see the same type of attributes we come to expect with BGP. With this route specifically, we can see that its come from outside of the ASN, which makes sense with it coming from an external router. The only RT is the one for the L3VNI and we see the VNID as the Received label too. The metric is the IGP (OSPF) metric to the next hop. The Router MAC is the MAC address of the NVE interface of the next hop we are sending to. Any packets sent using this route will be destined for that MAC address so that the receiving VTEP knows what to do with it:

Image

And with that, you should hopefully have a better understanding of type-5 routes and how to read the output from them and work out why there is so much of it. Lots of it is duplicated, but the most important section is the one with the local L3VNI RD.