Date created: Wednesday, October 4, 2017 5:05:42 PM. Last modified: Thursday, November 30, 2017 4:33:30 PM
BGP PIC Limitations
References:
https://www.cisco.com/c/en/us/td/docs/switches/metro/me3600x_3800x/software/release/15-4_2_S/configuration/guide/3800x3600xscg/swiprout.html#64294
https://www.cisco.com/c/en/us/td/docs/switches/metro/me3600x_3800x/software/release/15-4_2_S/configuration/guide/3800x3600xscg/swiprout.html#13390
https://www.cisco.com/c/en/us/td/docs/switches/metro/me3600x_3800x/software/release/15-4_2_S/configuration/guide/3800x3600xscg/swiprout.html#pgfId-1539279
https://www.cisco.com/c/en/us/td/docs/switches/metro/me3600x_3800x/software/release/15-4_2_S/configuration/guide/3800x3600xscg/swiprout.html#28663
General
It is not listed in the limitations section for the BGP PIC documention for IOS or IOS-XE however, under the per-CE and per-VRF label allocation mode documentation for both IOS and IOS-XE, PIC Edge is only support with per-prefix labelling mode. PIC Edge does not support Inter-AS MPLS Option B connections either (for all IOS/IOS-XE devices confirmed by TAC, probably IOS-XR too although unconfirmed).
Cisco 7600
More details notes on the limitations with Cisco 7600s can be found here. The short version though is that for L3 VPNs, packet recirculation is required which might be OK for low traffic volumes as it halves the PPS rate of the devices, but even then, it creates a modest increase in memory usage which likely makes it unusable, even in low traffic scenarios.
By default the 7600 prefers memory-optimised CEF tables:
7606S-RSP7203CXL#show cef table Global information: Output chain build favors: platform: memory-utilization CLI: not configured operational: memory-utilization Output chain build characteristics: Inplace modify platform enable: load-sharing platform prohibit: push-counter operational for: load-sharing Collapse platform enable: load-sharing operational for: load-sharing Indirection operational for:
Configuring HFIB/PIC Core with “cef table output-chain build favor convergence-speed” produces the following output:
7606S-RSP7203CXL#show cef table Global information: Output chain build favors: platform: memory-utilization CLI: convergence-speed operational: convergence-speed Output chain build characteristics: Inplace modify platform enable: load-sharing platform prohibit: push-counter operational for: load-sharing Collapse platform enable: load-sharing operational for: load-sharing Indirection operational for: recursive-prefix IPv4-to-MPLS IPv6-to-MPLS MPLS-end-of-stack MPLS-non-end-of-stack
Cisco ASR920
ASR920s support PIC Core and it is enabled by default. This is example output from a device that has it explicitly configured:
ASR-920-24SZ-M#show cef table Global information: Output chain build favors: platform: not configured CLI: convergence-speed operational: convergence-speed Output chain build characteristics: Inplace modify operational for: load-sharing push-counter Collapse operational for: load-sharing Indirection operational for: recursive-prefix IPv4-to-MPLS IPv6-to-MPLS MPLS-end-of-stack MPLS-non-end-of-stack
Cisco ME3600X/ME3800X
With the ME switches the commands were available prior to 15.4(2)S IOS but they didn’t do anything until that version. Below is the output from an ME3600X showing that “convergence-speed” is configured/operation (which means “cef table output-chain build favor convergence-speed” has been configured) however under “Indrection” all features are shown as prohibited:
ME3600X#show cef table Global information: Output chain build favors: platform: not configured CLI: convergence-speed operational: convergence-speed Output chain build characteristics: Inplace modify platform prohibit: load-sharing push-counter operational for: Collapse operational for: load-sharing Indirection platform prohibit: recursive-prefix non-recursive-prefix IPv4-to-MPLS IPv6-to-MPLS MPLS-end-of-stack MPLS-non-end-of-stack operational for:
From 15.4(2)S onwards the following output can be seen:
ME3600X# show cef table Global information: Output chain build favors: platform: not configured CLI: not configured operational: convergence-speed Output chain build characteristics: Inplace modify platform prohibit: push-counter operational for: load-sharing Collapse operational for: load-sharing Indirection platform prohibit: IPv6-to-MPLS operational for: recursive-prefix IPv4-to-MPLS MPLS-end-of-stack MPLS-non-end-of-stack
PIC BGP Updates
Below is an example PIC topology: AS1-CPE1 advertises 1.0.0.0/24 and the preferred path between AS1 and AS2 is via the AS2-PE1 link (Local Pref 200, MED 0, weight 0). AS3-CPE1 advertises 3.0.0.0/24 and the preferred path between AS3 and AS2 is the AS2-PE3 link (Local Pref 200, MED 0, weight 0). The AS1-CPE1 link to AS2-PE2 is the PIC backup path (Local Pref 50, MED 100, weight 0). The same is true for AS3-CPE1 via AS2-PE1.
! Before removing BGP PIC Edge, the path to 3.0.0.0/24 is preferred on AS2-PE2 via its local link to AS3-CPE1 but the path to 1.0.0.0/24 is preferred via AS2-PE1 and not it's local link to AS1-CPE2: AS2-PE2#show bgp vpnv4 unicast vrf 1 BGP table version is 52, local router ID is 2.0.0.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 2.0.0.2:1 (default for vrf 1) *>i 1.0.0.0/24 2.0.0.1 0 200 0 1 ? *b x 10.0.1.18 0 50 0 1 ? AS2-PE2#show bgp vpnv4 unicast vrf 2 BGP table version is 52, local router ID is 2.0.0.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 2.0.0.2:2 (default for vrf 2) *bi 3.0.0.0/24 2.0.0.1 0 50 0 3 ? *> 10.0.1.26 0 200 0 3 ?
When removing BGP PIC Edge "no bgp advertise-best-external" AS2-PE2 will send out a BGP unreachable NLRI (MP_UNREACH_NLRI) for any paths that are backup paths via this PE. In the below example 1.0.0.0/24 is a backup path via AS2-PE2 and AS2-PE1 is the primary path to that prefix. An MP_REACH_NLRI is sent for the path for which AS2-PE2 is already the primary path (3.0.0.0/24) however it was not first explicitly withdrawn with an MP_UNREACH_NLRI and then sent again, the existing route was re-sent unmodified with the same label value (a new label was not allocated):
! After removing "bgp advertise-best-external": AS2-PE2#show bgp vpnv4 unicast vrf 1 BGP table version is 56, local router ID is 2.0.0.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 2.0.0.2:1 (default for vrf 1) *>i 1.0.0.0/24 2.0.0.1 0 200 0 1 ? * 10.0.1.18 0 50 0 1 ? AS2-PE2#show bgp vpnv4 unicast vrf 2 BGP table version is 56, local router ID is 2.0.0.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 2.0.0.2:2 (default for vrf 2) * i 3.0.0.0/24 2.0.0.1 0 50 0 3 ? *> 10.0.1.26 0 200 0 3 ?
When enabling the BGP Advertise Best External (BGP PIC Edge) feature again on AS2-PE2, the prefix for which AS2-PE2 is the primary next-hop (3.0.0.0/24) is again re-sent, unmodified without an explicit BGP WITHDRAW using the same MPLS label. The prefix for which AS2-PE2 is the backup next-hop router (1.0.0.0/24) is also sent in the MP_REACH_NLRI and this requires a label to be allocated, the same label was allocated as it was the next free label value but it could have changed:
Previous page: BGP PIC Core & Edge
Next page: BGP Selective Download