vSLX is not advertising the direct routes to its EVPN neighbor

  • 0
  • 1
  • Question
  • Updated 1 month ago
https://extremenetworks2com-my.sharepoint.com/:t:/g/personal/rbiradar_extremenetworks_com/ESxP4NKonVVBg4sybgTRndEB5PJ5rq1hipb5ekYrzW4lVw?e=EnnzSJ

We are doing interop testing (L3VNI) of BGP EVPN between VOSS and vSLX

Neighbor is established, Routes are accepted from VOSS, Tunnel is Up.

But only problem we are facing is that routes are not being advertised by vSLX.


SLX-R2# sho bgp evpn sum  

  BGP4 Summary

  Router ID: 50.0.0.2   Local AS Number: 23456

  Confederation Identifier: not configured

  Confederation Peers:

  Maximum Number of IP ECMP Paths Supported for Load Sharing: 1

  Number of Neighbors Configured: 1, UP: 1

  Number of Routes Installed: 5, Uses 1025 bytes

  Number of Routes Advertising to All Neighbors: 0 (0 entries)

  Number of Attribute Entries Installed: 4, Uses 648 bytes

  Neighbor Address  AS#         State     Time     Rt:Accepted Filtered Sent     ToSend

  50.0.0.1          8404        ESTAB   1d18h25m      1        0        0        0       

 

 

 

SLX-R2# show tunnel status

Tnl id    Adm state Oper state BFD state Tnl dest IP     VeId(GRE) Ve state(GRE)

========= ========= ========== ========= =============== ========= ==============

61441     up        up                   7.7.7.7          NA         NA

 

 

We configured some loopback ip’s for testing redist and below is the config for route redistribution.

 

router bgp

local-as 23456

neighbor 50.0.0.1 remote-as 8404

neighbor 50.0.0.1 update-source 50.0.0.2

address-family ipv4 unicast

  redistribute connected

!

address-family ipv4 unicast vrf green

  redistribute connected

!

address-family ipv6 unicast

!

address-family l2vpn evpn

  neighbor 50.0.0.1 encapsulation vxlan

  neighbor 50.0.0.1 activate

!

!

 

Any idea why connected routes are not getting advertised to the EVPN neighbor?

Complete EVPN config can be found here:
https://extremenetworks2com-my.sharepoint.com/:t:/g/personal/rbiradar_extremenetworks_com/ESxP4NKonV...

Photo of Rajshekhar Biradar

Rajshekhar Biradar, Employee

  • 130 Points 100 badge 2x thumb

Posted 1 month ago

  • 0
  • 1
Photo of Erik Auerswald

Erik Auerswald, Embassador

  • 13,458 Points 10k badge 2x thumb
Hm, why did you use AS 23456? This is a special AS number used when a 4 byte AS number is used. I do not see a 4 byte AS number in your configuration. I'd recommend to use a different AS number, e.g. a private one (64512 to 65535).
Photo of Erik Auerswald

Erik Auerswald, Embassador

  • 13,458 Points 10k badge 2x thumb
Hi,

some additional info:

Usage of a Well Known Autonomous System Number `23456' (=AS_TRANS)

To facilitate compatibility and gradual upgrade, RFC4893 defines a well known 4-octet Autonomous System number for backward compatibility. This well known AS number is `23456', also known as AS_TRANS.
This well known AS number is used by a NEW BGP speaker peering with an OLD BGP speaker in two situations:

1. If a NEW BGP speaker is using a true 4-octet AS number. A true 4-octet AS number is an AS number which can not fully be represented by a 2-octet AS number. (for example AS# "100.100" can not be represented by a 2-octet AS number, where AS# "0.100" could be represented like AS# "100" towards an OLD BGP speaker, by dropping the leading 16 zero's of the full 4-octet AS number). The OLD BGP speaker expects to peer with a BGP speaker that belongs to a 2-octet Autonomous System, and hence the NEW BGP speaker will either remove the 16 leading zero's from its AS#, or it will swap the non-mappable 4-octet AS# with well known AS# "23456"

2. In similar manner, the 4-octet AS-Path is manipulated by a NEW BGP speaker peering with an OLD BGP speaker. An OLD BGP speaker can not understand any 4-octet AS numbers, and hence the NEW BGP speaker will create from its AS-Path, consisting of all 4-octet AS hops, an AS-Path which only contains 2-octet AS hops. For each entry in the AS-Path, the NEW BGP speaker will decide if it is a mappable AS# or not. If it is a mappable AS#, then the leading 16 "zeros" are removed. If the AS# is a non-mappable AS#, then the NEW BGP speaker will swap the AS hop entry with well known AS# "23456"

A side effect from the compatibility between OLD and NEW BGP speakers is that the usage of "23456" as the BGP AS# is not possible. If an OLD BGP speaker would be configured to belong to AS "23456", then this OLD BGP speaker will result as a AS-Path loop detection drop by any BGP routes that have AS# "23456" within the AS-Path list, resulting in an incomplete view from the OLD BGP speaker perspective.
An additional side effect could be if the NEW BGP speaker belongs, for example, to AS# 100.100 and the OLD BGP speaker to AS# 200. Then, there should be an eBGP session with both BGP speakers. If the OLD BGP Speaker would be wrongly configured as belonging to AS# "23456", then instead of an eBGP peering, an iBGP peering would be established between the OLD and NEW BGP speaker, which is highly undesirable, resulting in the wrong BGP behavior.

Source: https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/border-gateway-protocol-bgp/whi...
[I have added the bold/italic/underlined formatting]


Photo of Rajshekhar Biradar

Rajshekhar Biradar, Employee

  • 130 Points 100 badge 2x thumb
Thanks Erik for your response. I tried with different AS number, still routes are not being advertised.
SLX-R2# sho bgp evpn sum
  BGP4 Summary 
  Router ID: 50.0.0.2   Local AS Number: 64512
  Confederation Identifier: not configured
  Confederation Peers: 
  Maximum Number of IP ECMP Paths Supported for Load Sharing: 1
  Number of Neighbors Configured: 1, UP: 1
  Number of Routes Installed: 5, Uses 1025 bytes
  Number of Routes Advertising to All Neighbors: 0 (0 entries)
  Number of Attribute Entries Installed: 5, Uses 810 bytes
  Neighbor Address  AS#         State     Time     Rt:Accepted Filtered Sent     ToSend
  50.0.0.1          8404        ESTAB   0h1m16s       1        0        0        0        


SLX-R2# sho ip bgp sum
  BGP4 Summary 
  Router ID: 50.0.0.2   Local AS Number: 8405
  Confederation Identifier: not configured
  Confederation Peers: 
  Maximum Number of IP ECMP Paths Supported for Load Sharing: 1
  Number of Neighbors Configured: 1, UP: 1
  Number of Routes Installed: 3, Uses 615 bytes
  Number of Routes Advertising to All Neighbors: 3 (3 entries), Uses 228 bytes
  Number of Attribute Entries Installed: 2, Uses 324 bytes
  Neighbor Address  AS#         State     Time     Rt:Accepted Filtered Sent     ToSend
  50.0.0.1          8404        ESTAB   0h1m25s       0        0        0        3(NoNeg)


I am new to SLX. Are there any logs/traces i can look into to debug this further?
(Edited)
Photo of Erik Auerswald

Erik Auerswald, Embassador

  • 13,458 Points 10k badge 2x thumb
Hi,

I have never used an SLX switch, so I have no idea what you can do exactly.

I would check if the EVPN address family is active for the neighbor (on both systems), and then look into the BGP RIB for the EVPN address family. Routes need to be part of the RIB and valid (e.g. a valid next-hop) to be announced.

Then there is the newish idea of not sending eBGP NLRI info without an explicit policy configuration (RFC 8212). I do not know if SLX implements this RFC or not.

Please let us know if you find out more. :-)

Thanks,
Erik