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 22.214.171.124
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
I am having problems with NCS540 after power outage.
When the device loses grid connectivity, it will not reboot when AC comes back on.
Devices power LED's are blinking green (dual PSU) and all interfaces are down, problem is resolved with manu...
Listen: https://smarturl.it/CCRS9E19Follow us: twitter.com/ciscochampionsNetworks can be complex and often unpredictable. Traffic from over-the-top applications, automated systems, malicious attacks, or variations from simple operational errors...
Dear Cisco Team,Does the line card A9K-4T16GE-TR support PTP configuration?In docs I found that on 6.2.x is supported but on 6.4.2 is not. https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r6-2/sysman/configuration/guide/b-system-m...
Hi guys,thanks for a great resource! I'm looking at this document on the topic:Cisco IOS-XR BGP with MPLS Designs It says in section 4 that in order to make the exchange (In image 3) work ASBR3 needs to have a dummy iBGP neighbor conf...