vSLX is not advertising the direct routes to its EVPN neighbor

[Rajshekhar_Bira]

https://extremenetworks2com-my.sharepoint.com/:t:/g/personal/rbiradar_extremenetworks_com/ESxP4NKonV... 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...

[Erik_Auerswald]

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

[Rajshekhar_Bira]

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?

[Erik_Auerswald]

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]

[Erik_Auerswald]

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).