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 188.8.131.52
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 understand what "urgent priority" does. I also understand what ! does in a route pattern. But when they were put together, I'm confused.! is usually used on variable length dial strings, e.g. international dialing. CallManager usually ...
Hi all;I have a carrier network with NCS 5501, we deliver L2VPN service to customers, how can I configure NCS 5501 UNI interface which is Bundle-Ether interface to process LACP PDU locally ?Note that for my service, customer promise equipement (CPE) conne...
Hi all,on all our new ASR9k we are observing a loss of NTP synchronization. We have many IOS devices which do not show this issue, so obviously it is not a network problem as the NTP servers are the same for all devices (internal server). I see...
So I picked up a used 2911 to replace my aging 3825 that I use for home router and intercom system via low end cisco 69xx voip phones. Was hoping the newer unit, advertised with CME 12, would let me maybe upgrade my phones to something more colorful.Note:...