Overview
Devices operating with the Border Gateway Protocol (BGP) are termed BGP speakers. They maintain a Routing Information Base (RIB) that stores routing information for other BGP speakers in the network. The RIB includes a separate “Adjacent Routing Information Base, Incoming” (Adj-RIB-In) component for each BGP speaker, storing routing information received from that specific speaker.
For a given BGP speaker, neighboring speakers are considered peers. Typically, a speaker has only one peering relationship with another BGP speaker, but in some cases it may have multiple peering relationships with another BGP speaker. Typically, unless the multi-session feature is used, only one session is established for each peering relationship.
When a BGP speaker advertises unicast routes to its peers, it sends an UPDATE message. The routes include a prefix and possibly a label.
-
Unlabeled unicast (uses SAFI 1): Unicast prefix only.
-
Labeled unicast (uses SAFI 4): Unicast prefix, and an MPLS label associated to that prefix.
Note |
SAFI = Subsequent Address Family Identifier |
Unlabeled and Labeled Unicast in the Same Session
In a single session, two BGP speakers can use both unlabeled and labeled unicast. Different BGP implementations handle this differently. When keeping track of the latest route information for a given prefix:
-
(a) Some systems treat all unlabeled or labeled forms of a prefix as equivalent. These systems store the route information provided by the most recent update for the prefix, whether unlabeled or labeled.
-
(b) Other systems treat each form of the prefix, whether unlabeled (SAFI 1) or labeled (SAFI 4), as unique. With these systems, the Adj-RIB-In for each peer stores routing information separately for the unlabeled prefix and the labeled prefix.
For a BGP session to propagate routes correctly, the way that one speaker sends a prefix must match the way that the other side receives the prefix. If they are not matched, the routes will not be received correctly. In that case, the receiver will then install the routes incorrectly, but without indicating any error, so the problem may go unaddressed.
Before Cisco IOS XE Gibraltar 16.12.1, IOS XE used only the method described in (a) above. It supported unlabeled and labeled unicast in the same session, but only among Cisco IOS XE speakers. Any two forms of the same prefix, whether unlabeled or labeled, were considered equivalent. For a given peer, the last received version of route information for any specific prefix was stored in the Adj-RIB-In, regardless of whether it was unlabeled or labeled.
Beginning with release 16.12.1, Cisco IOS XE provides a mode called "label-unicast unique", which supports sessions with BGP speakers that handle each form (unlabeled or labeled) of a prefix as unique. In this mode, the Adj-RIB-In for a given peer can store two routes for the same prefix, one route for unlabeled (received as SAFI 1) and one route for labeled (received as SAFI 4).
In this mode:
-
Inbound processing: The device can store one labeled path and one unlabeled path from a neighbor.
-
Outbound processing: The device executes update-generation twice, once for SAFI 1 and once for SAFI 4. Prefixes are advertised and withdrawn independently for each SAFI. In most scenarios, a prefix is only advertised in one of the SAFI types, but this depends on policy and may not be true in all cases.
The following figures show some of the difference in behavior that "label-unicast unique" mode provides by storing route information separately for unlabeled and labeled forms of the same prefix.
Interoperability
The "label-unicast unique" mode improves interoperability between Cisco IOS XE and operating systems, such as Cisco IOS XR, that treat unlabeled and labeled forms of a prefix as unique.
Backward Compatibility
To preserve backward compatibility, Cisco IOS XE Gibraltar 16.12.1 operates by default in the same mode as in previous releases. To change to the "label-unicast unique" mode, use the update {in|out} labeled-unicast unique command.