Extended Community enables split-horizon procedures for multihomed sites. The ESI Label field represents an ES by the advertising PE, and it is used in split-horizon filtering by other PEs that are connected to the same multihomed Ethernet segment.
ESI Label in extended community is encoded in 24 bits. It further needs to be decoded into 20-bit MPLS label. RFC does not explicitly mention which bits should be omitted during decode procedure.
RFC 8317 gives explicit example on how it should be implemented:
When extended community is advertised along with the MAC/IP Advertisement route (for known unicast traffic), the Leaf-Indication flag MUST be set to one and the Leaf label SHOULD be set to zero. When this extended community is advertised along with the EAD-ES route (with an ESI of zero) for BUM traffic to enable egress filtering on disposition PEs, the Leaf label MUST be set to a valid MPLS label (i.e., a non-reserved, assigned MPLS label [RFC3032]) and the Leaf-Indication flag SHOULD be set to zero. The value of the 20-bit MPLS label is encoded in the high-order 20 bits of the Leaf label field. The receiving PE MUST ignore the Leaf-Indication flag. A non-valid MPLS label, when sent along with the EAD-ES route, should be ignored and logged as an error.
To adhere to RFC 8317 recommendations Cisco is changing the way MPLS label being encoded/decoded from Extended Community:
In earlier releases Cisco was using the lower 20 bits of this extended community to encode the SHG label.
Cisco is changing the SHG label encoding to be done from higher 20 bits of extended community.
According to this change routers in same ethernet-segment running with old and new behavior will decode extended community differently, which may lead to inconsistent SHG labels on peering EVPN PE routers. In most of the cases both will just drop BUM packets with incorrect SHG label (in their perspective) but in certain conditions (e.g. when label incorrectly read as NULL) it may cause remote PE to accept such packets and forward to CE potentially causing a loop.
Today Multi-Vendor behavior:
- Cisco IOS-XR and IOS-XE both do bit-shift into higher-order bits of extended community to derive a Label
- Nokia and JunOS is also doing it
Example of output
PE1 (new IOS-XR): RP/0/RSP0/CPU0:PE1#show evpn ethernet-segment interface bundle-Ether 8 det
Local SHG label : 24012
Remote SHG labels : 1
2048 : nexthop 18.104.22.168
BGP extended community on PE1 (upper 20 bits): 0000 0101 1101 1100 1100 0000 --- 24012
PE2(OLD IOS-XR): BGP extended community on PE1 (lower 20 bits): 0000 0101 1101 1100 1100 0000 --- 384192
Today I was studying the seamless MPLS approach from this page:https://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/116127-configure-technology-00.html But there is a point where I really struggle.See the picture below.H...
Quick Question please, In MPLS network with VRFs, there are two labels on the packet, one is the MP-BGP label and the other is LDP label. Does the MP-BGP label have EXP bit? Or it's only on the LDP label? Thank you
Having an issue where the amount of radius sessions are not in sync with the BNG sessions. We use IPoE for authentication, so any COAs that need to sent from radius to the bng need to be known by radius and that is where the issue lies. ...
I'm reviewing our hardware for replacement planning, and have most of the EoS dates, except for the following:ASR-9001A9K-MPA-20X1GEA9K-MPA-4X10GEA9K-MPA-8X10GE Any info or references are appreciated. Thanks,Phil