BGP Unlabeled and Labeled Unicast in the Same Session: Label-Unicast Unique Mode

Cisco IOS XE provides a mode called "label-unicast unique". With this mode enabled, in BGP sessions that include unlabeled unicast and labeled unicast, the unlabeled and labeled forms of a given prefix are treated as unique. This improves interoperability with other operating systems that also treat these as unique, such as Cisco IOS XR.

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.

Figure 1. Non-unique Mode: Unlabeled and Labeled Forms of a Prefix Considered Equivalent, Stores Only Last Route Received
Figure 2. "Label-Unicast Unique" Mode: Unlabeled and Labeled Forms of a Prefix Considered Unique, Routes for Each Stored Separately

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.

Restrictions

  • BGP additional-paths is not supported with the label-unicast unique feature configured.

Configuration

Symmetrical Configuration

The term "symmetrical" applies to sessions between BGP speakers that both treat unlabeled and labeled prefixes as unique, for inbound (when receiving) and outbound (when advertising). This is the ideal scenario. An example would be a device using Cisco IOS XE communicating with a device using Cisco IOS XR.

See below for details of configuring symmetrical devices.

Two Cisco IOS XE Devices

In this configuration example:

  • Device A: Using Cisco IOS XE. Configured with IP address 10.0.0.1, Autonomous System (AS) identifier 100.

  • Device B: Using Cisco IOS XE. Configured with IP address 10.0.0.2, AS identifier 200.

On device A, in router configuration mode:

router bgp 100
neighbor 10.0.0.2 remote-as 200
neighbor 10.0.0.2 update in labeled-unicast unique
neighbor 10.0.0.2 update out labeled-unicast unique
address-family ipv4 unicast
neighbor 10.0.0.2 send-label

On device B, in router configuration mode:

router bgp 200
neighbor 10.0.0.1 remote-as 100
neighbor 10.0.0.1 update in labeled-unicast unique
neighbor 10.0.0.1 update out labeled-unicast unique
address-family ipv4 unicast
neighbor 10.0.0.1 send-label

One Cisco IOS XE Device and One Other Device

In this configuration example:

  • Device A: Using Cisco IOS XE. Configured with IP address 10.0.0.1, Autonomous System (AS) identifier 100.

  • Device B: Using Cisco IOS XR. Configured with IP address 10.0.0.2, AS identifier 200.

The configuration steps are required only on device A, running IOS XE.

On device A, in router configuration mode:

router bgp 100
neighbor 10.0.0.2 remote-as 200
neighbor 10.0.0.2 update in labeled-unicast unique
neighbor 10.0.0.2 update out labeled-unicast unique
address-family ipv4 unicast
neighbor 10.0.0.2 send-label

Asymmetrical Configuration

The term "asymmetrical" applies to sessions between BGP speakers, where one speaker treats unlabeled and labeled prefixes as unique for inbound and as equivalent for outbound; and the other speaker treats unlabeled and labeled prefixes as equivalent for inbound and unique for outbound.

This is not ideal, but arises in some network scenarios.

In this configuration example:

  • Device A: Using Cisco IOS XE. Configured with IP address 10.0.0.1, Autonomous System (AS) identifier 100.

  • Device B: Using Cisco IOS XE. Configured with IP address 10.0.0.2, AS identifier 200.

On device A, in router configuration mode:

router bgp 100
neighbor 10.0.0.2 remote-as 200
neighbor 10.0.0.2 update-labeled in unicast unique
address-family ipv4 unicast
neighbor 10.0.0.2 send-label

On device B, in router configuration mode:

router bgp 200
neighbor 10.0.0.1 remote-as 100
neighbor 10.0.0.1 update-labeled out unicast unique
address-family ipv4 unicast
neighbor 10.0.0.1 send-label