The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes the behavior of receiving and advertising unlabeled and labeled paths over one BGP session in Cisco IOS® XR.
There are no specific requirements for this document.
This document is specific to Cisco IOS® XR, but it is not restricted to a specific software release or hardware.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Address Family Identifier (AFI) is an indication of the kind of BGP route. Examples are 1 for IPv4 and 2 for IPv6.
Subsequent Address Family Identifier (SAFI) is a further indication of the kind of route. Example are 1 for an unlabeled route and 4 for a labeled route.
Unlabeled unicast for IPv4 is AFI 1 and SAFI 1.
Labeled unicast for IPv4 is AFI 1 and SAFI 4.
Unlabeled unicast for IPv6 is AFI 2 and SAFI 1.
Labeled unicast for IPv6 is AFI 2 and SAFI 4.
Labeled unicast (LU) is often referred to as RFC 3107 “Carrying Label Information in BGP-4.”
Hereafter, U refers to unlabeled unicast, so SAFI 1 and LU refers to labeled unicast, so SAFI 4.
Note that Cisco IOS® XR needs “allocate-label all| route-policy …” or the route will not be originated or propagated to the next BGP speaker as SAFI 4.
IPv4/v6 unicast and labeled-unicast both on one BGP session was not supported on Cisco IOS® XR .
On Cisco IOS® XR, the support to have both unlabeled and labeled on one BGP session was done in 6.2.1.
When running both on one session is not supported, it is problematic as the last received update/withdraw overrides the previous one, even if they were received on another SAFI.
When you configure both SAFI 1 and 4 on the same BGP session on a router running IOS-XR code prior to IOS-XR 6.2.1, the router gives the following warning:
bgp[1051]: %ROUTING-BGP-4-INCOMPATIBLE_AFI : IPv4 Unicast and IPv4 Labeled-unicast Address families together are not supported under the same neighbor.
This warning message was introduced in IOS-XR 5.3.0 and IOS-XR 5.2.2.
The capabilities exchanged between BGP peers must match. If not, the BGP session does not come up.
This is a wireshark capture of the capability exchanged for AFI 1/SAFI 1 and AFI 1/SAFI 4 in the BGP Open message:
Image 1
Here’s an example for IOS-XR configured with LU only on a session to IOS configured with U only.
IOS-XR:
RP/0/0/CPU0:R4#show bgp neighbor 10.100.1.8
BGP neighbor is 10.100.1.8
Remote AS 65003, local AS 65003, internal link
Remote router ID 0.0.0.0
BGP state = Idle
…
Connections established 0; dropped 0
Local host: 10.100.1.4, Local port: 179, IF Handle: 0x00000000
Foreign host: 10.100.1.8, Foreign port: 33396
Last reset 00:00:14, due to BGP Notification sent: unsupported/disjoint capability
Time since last notification sent to neighbor: 00:00:14
Error Code: unsupported/disjoint capability
Notification data sent:
None
The IOS router prints a syslog message for this configuration mistake:
*Aug 8 12:40:44.719: %BGP-3-NOTIFICATION: received from neighbor 10.100.1.4 active 2/7 (unsupported/disjoint capability) 0 by
You configure “address-family ipv4 unicast” under the BGP neighbor command to enable ipv4 unicast for the BGP session.
You configure “address-family ipv6 unicast” under the BGP neighbor command to enable ipv6 unicast for the BGP session.
You configure “address-family ipv4 labeled-unicast” under the BGP neighbor command to enable ipv4 labeled unicast for the BGP session.
You configure “address-family ipv6 labeled-unicast” under the BGP neighbor command to enable ipv6 labeled unicast for the BGP session.
In IOS-XR the AFI/SAFI combination is configured per BGP peer.
This is an example for a BGP session having both SAFI 1 and 4:
router bgp 65003
address-family ipv4 unicast
redistribute connected
allocate-label all unlabeled-path
…
neighbor 10.100.1.7
remote-as 65003
update-source Loopback0
address-family ipv4 unicast
route-reflector-client
!
address-family ipv4 labeled-unicast
route-reflector-client
Notice that there is still only the "address family unicast" and not "address-family labeled-unicast" under router BGP. Both SAFI 1 and 4 paths are stored in this one BGP table.
Regardless if IOS-XR is older or newer than 6.2.1, there is only one BGP table to store the U and LU routes. This is evident by the fact that you can only configure (enable) "address-family ipv4 unicast" or "address-family ipv6 unicast" under router bgp. You cannot configure "address-family ipv4 labeled-unicast" or "address-family ipv6 labeled-unicast" under router bgp.
The U and LU path can be identical. Before IOS-XR 6.2.1, receiving the same path again but this time with or without a label, would override the previously received path. After IOS-XR 6.2.1, the two identical paths will seen as different if they only differ by the label. The path additions, deletions, or modifications are performed by the different SAFIs.
Here is an example of a route in the BGP table with AFI 1/SAFI 4. Because label allocation is enabled for all prefixes, this path will be stored with a local label. Because there is only one BGP table to store U and LU routes, the prefix shows up with both the commands “show bgp ipv4 unicast” and “show bgp ipv4 labeled-unicast”!
RP/0/0/CPU0:R4#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 5 5
Local Label: 24000
Last Modified: Aug 6 15:03:59.574 for 16:06:13
Paths: (1 available, best #1)
Advertised to update-groups (with more than one peer):
0.3 0.4
Advertised to peers (in unique update groups):
10.1.45.5
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.3 0.4
Advertised to peers (in unique update groups):
10.1.45.5
65002 65001
10.1.24.2 from 10.1.24.2 (10.100.1.2)
Received Label 24003
Origin IGP, localpref 100, valid, external, best, group-best, labeled-unicast
Received Path ID 0, Local Path ID 0, version 5
Origin-AS validity: not-found
Notice that the path is marked with “labeled-unicast”.
RP/0/0/CPU0:R4#show bgp ipv4 labeled-unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 5 5
Local Label: 24000
Last Modified: Aug 6 15:03:59.574 for 16:08:41
Paths: (1 available, best #1)
Advertised to update-groups (with more than one peer):
0.3 0.4
Advertised to peers (in unique update groups):
10.1.45.5
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.3 0.4
Advertised to peers (in unique update groups):
10.1.45.5
65002 65001
10.1.24.2 from 10.1.24.2 (10.100.1.2)
Received Label 24003
Origin IGP, localpref 100, valid, external, best, group-best, labeled-unicast
Received Path ID 0, Local Path ID 0, version 5
Origin-AS validity: not-found
Notice that the path is marked with “labeled-unicast”.
If the path is present as both U and LU, then the local Path ID is different.
RP/0/0/CPU0:R4#show bgp ipv4 labeled-unicast 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 30 30
Local Label: 24003 (no rewrite);
Flags: 0x00003028+0x00010000;
Last Modified: Aug 30 10:45:50.502 for 00:01:59
Paths: (2 available, best #1)
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.100.1.8 10.100.1.9
Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):
0.8
Path #1: Received by speaker 0
Flags: 0x4000000009060205, import: 0x20
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.100.1.8 10.100.1.9
Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):
0.8
65001, (Received from a RR-client)
10.100.1.9 (metric 2) from 10.100.1.9 (10.100.1.9)
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 29
Path #2: Received by speaker 0
Flags: 0x4080000008020205, import: 0x20
Not advertised to any peer
65001, (Received from a RR-client)
10.100.1.9 (metric 2) from 10.100.1.9 (10.100.1.9)
Received Label 24001
Origin IGP, metric 0, localpref 100, valid, internal, labeled-unicast
Received Path ID 0, Local Path ID 0, version 0
You must configure the command “allocate-label” in order for the received or sourced paths in BGP to have a local MPLS label. Without this command, the routes will not have a local label.
RP/0/0/CPU0:R4#conf t
RP/0/0/CPU0:R4(config)#router bgp 65003
RP/0/0/CPU0:R4(config-bgp)# address-family ipv4 unicast
RP/0/0/CPU0:R4(config-bgp-af)#allocate-label ?
all Allocate labels for all prefixes
route-policy Use a route policy to select prefixes for label allocation
The label allocation occurs for all routes or per the configured route-policy.
In the old implementation on IOS-XR, a warning is given when configuring both the U and LU on the same BGP session. The warning is introduced in IOS-XR releases 5.3.0, and 5.2.2. The warning is removed in IOS-XR release 6.2.1, because labeled and unlabeled are supported on the same BGP session.
Example:
RP/0/0/CPU0:ios#conf t
RP/0/0/CPU0:ios(config)#router bgp 65001
RP/0/0/CPU0:ios(config-bgp)#add ipv4 unicast
RP/0/0/CPU0:ios(config-bgp-af)#exit
RP/0/0/CPU0:ios(config-bgp)#neighbor 10.0.0.1
RP/0/0/CPU0:ios(config-bgp-nbr)#remote-as 65001
RP/0/0/CPU0:ios(config-bgp-nbr)#exit
RP/0/0/CPU0:ios(config-bgp)#neighbor 10.0.0.1
RP/0/0/CPU0:ios(config-bgp-nbr)#address-family ipv4 unicast
RP/0/0/CPU0:ios(config-bgp-nbr-af)#exit
RP/0/0/CPU0:ios(config-bgp-nbr)#address-family ipv4 labeled-unicast
RP/0/0/CPU0:ios(config-bgp-nbr-af)#commit
RP/0/0/CPU0:Aug 21 14:14:22.222 : bgp[1052]: %ROUTING-BGP-4-INCOMPATIBLE_AFI : IPv4 Unicast and IPv4 Labeled-unicast Address families together are not supported under the same neighbor.
The explanation for this error message:
This message indicates that the user has configured both IPv4 Unicast and IPv4 Labeled-unicast or IPv6 Unicast and IPv6 Labeled-unicast address families together under the same neighbor. This particular configuration is not supported.
Recommended action: Configure two neighbor sessions to the router. Configure the unicast address-family under the first neighbor session and configure the labeled-unicast address-family under the second neighbor session.
Configuration example for two BGP sessions between a pair of IOS-XR routers. Use a different (loopback) address for each BGP session.
hostname R1
interface Loopback0
ipv4 address 10.100.1.1 255.255.255.255
!
interface Loopback1
ipv4 address 10.100.1.101 255.255.255.255
!
router bgp 65001
address-family ipv4 unicast
!
neighbor 10.100.1.2
remote-as 65001
update-source Loopback0
address-family ipv4 unicast
!
!
neighbor 10.100.1.102
remote-as 65001
update-source Loopback1
address-family ipv4 labeled-unicast
!
!
hostname R2
interface Loopback0
ipv4 address 10.100.1.2 255.255.255.255
!
interface Loopback1
ipv4 address 10.100.1.102 255.255.255.255
!
router bgp 65001
address-family ipv4 unicast
!
neighbor 10.100.1.1
remote-as 65001
update-source Loopback0
address-family ipv4 unicast
!
!
neighbor 10.100.1.101
remote-as 65001
update-source Loopback1
address-family ipv4 labeled-unicast
!
!
In IOS-XR 6.2.1, both U and LU are supported on the same BGP session on the default VRF!
It does not matter if the BGP session is internal or external BGP.
U and LU on the same session is not supported for BGP speakers in any non-default VRF.
Before IOS-XR 6.2.1, all U, LU, and U + LU BGP speakers were kept in separate update groups. After IOS-XR release 6.2.1, this is no longer true. Some BGP speakers in one update group can be only U, or only LU, or both U and LU.
The following table shows the advertisement and withdraw behavior for different scenarios. There are 16 scenarios.
All applies to IOS-XR version 6.2.1 and later, unless otherwise mentioned in the comments column.
Case |
Bestpath/Addpath type |
Local label present? |
NHS or NHU |
Update-group SAFI |
Advertise or withdraw? |
Comments |
1 |
Unlabeled path i.e. no rx label |
Yes |
NHS |
SAFI-1 |
Advertise by default Withdraw with advertise local-labeled-route (safi-unicast) disable command |
Only possible after 6.5.1. |
2 |
SAFI-4 |
Advertise |
Only possible after 6.5.1. IPv4/v6 redist routes and 6PE: implicit NHS always |
|||
3 |
NHU |
SAFI-1 |
Advertise |
Only possible after 6.5.1. |
||
4 |
SAFI-4 |
Withdraw |
Only possible after 6.5.1. IPv4/v6 redist routes and 6PE: NHU ignored; implicit NHS always |
|||
5 |
No |
NHS |
SAFI-1 |
Advertise |
||
6 |
SAFI-4 |
Withdraw |
||||
7 |
NHU |
SAFI-1 |
Advertise |
|||
8 |
SAFI-4 |
Withdraw |
||||
9 |
Labeled path i.e. with rx label |
Yes |
NHS |
SAFI-1 |
Advertise by default Withdraw with advertise local-labeled-route (safi-unicast) disable command |
Before 6.2.1: default behavior is to Advertise. |
10 |
SAFI-4 |
Advertise |
||||
11 |
NHU |
SAFI-1 |
Withdraw |
Before 6.2.1: behavior is to advertise. |
||
12 |
SAFI-4 |
Advertise |
||||
13 |
No |
NHS |
SAFI-1 |
Advertise |
||
14 |
SAFI-4 |
Withdraw |
||||
15 |
NHU |
SAFI-1 |
Withdraw |
Before 6.2.1: behavior is to advertise. |
||
16 |
SAFI-4 |
Advertise |
Table 1 Advertisement behavior for iBGP and eBGP Sessions
NHS = Next Hop Self
NHU = Next Hop Unchanged.
If NHU is in effect, this means that next-hop self is not configured for an iBGP session.
Note that NHS is always the case when the BGP speaker sends to an eBGP peer.
There can be NHS or NHU towards an iBGP speaker, depending on the configuration of next-hop-self. The default behavior towards iBGP peers is NHU.
For the second column: note that the path is considered to be unlabeled or labeled only if the best-path or one of the paths marked with add-path is unlabeled or labeled.
For the route propagation it matters what characteristics the best path has. Depending on the characteristics (colums 2 to 4), it determines if the path is advertised as U, or LU, or both.
If the feature Additional Paths (ADD-PATH) is enabled and a path is marked with "add-path", the characteristics of that path also play a role how that path will be advertised.
“Local Label Present?: No” means the following: it is possible that a label is received with the received update, but the label is not installed. The local label is not installed if the command “allocate-label” is not there.
You can verify if the local label is present by looking at the prefix in detail. Use “show bgp <prefix> detail” or “show route <prefix> detail”.
In the following example, the prefix is received without a label (so over a SAFI 1 peering) and no local label is assigned:
RP/0/0/CPU0:R2#show bgp ipv4 labeled-unicast 10.100.1.5/32 detail
BGP routing table entry for 10.100.1.5/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 3 3
Flags: 0x04001001+0x00000000;
Last Modified: Sep 5 03:44:45.647 for 01:01:27
Paths: (1 available, best #1)
Advertised to update-groups (with more than one peer):
0.3
Path #1: Received by speaker 0
Flags: 0x4000000001040207, import: 0x00
Advertised to update-groups (with more than one peer):
0.3
Local, (Received from a RR-client)
10.100.1.1 (metric 2) from 10.100.1.1 (10.100.1.1)
Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 3
RP/0/0/CPU0:R2#show route 10.100.1.5/32 detail
Routing entry for 10.100.1.5/32
Known via "bgp 65001", distance 200, metric 0, type internal
Installed Sep 5 03:44:45.480 for 01:01:37
Routing Descriptor Blocks
10.100.1.1, from 10.100.1.1
Route metric is 0
Label: None
Tunnel ID: None
Extended communities count: 0
NHID:0x0(Ref:0)
Route version is 0x23 (35)
No local label
IP Precedence: Not Set
QoS Group ID: Not Set
Flow-tag: Not Set
Route Priority: RIB_PRIORITY_RECURSIVE (12) SVD Type RIB_SVD_TYPE_LOCAL
Download Priority 4, Download Version 52
No advertising protos.
By default, unlabeled paths (SAFI 1) are never labeled, even when the “allocate-label” command is configured.
As of IOS-XR release 6.5.1., there is the keyword “unlabeled-path” for the “allocate-label” command, so that also the unlabeled paths can be allocated a label.
RP/0/0/CPU0:R4#conf t
RP/0/0/CPU0:R4(config)#router bgp 65003
RP/0/0/CPU0:R4(config-bgp)# address-family ipv4 unicast
RP/0/0/CPU0:R4(config-bgp-af)#allocate-label all ?
unlabeled-path Allocate label for unlabeled paths too
<cr>
RP/0/0/CPU0:R4(config-bgp-af)#allocate-label all unlabeled-path ?
<cr>
RP/0/0/CPU0:R4(config-bgp-af)#allocate-label all unlabeled-path
RP/0/0/CPU0:R4(config-bgp-af)#commit
The path is a SAFI 1 path, so there is no received label.
Because of the “unlabeled-path” command there is now a local label.
RP/0/0/CPU0:R4#show bgp ipv4 labeled-unicast 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 16 16
Local Label: 24003 (no rewrite);
Flags: 0x01303028+0x00000000;
Last Modified: Aug 27 19:08:47.502 for 00:00:59
Paths: (1 available, best #1)
Advertised IPv4 Unicast paths to update-groups (with more than one peer):
0.3
Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):
0.7
Advertised IPv4 Labeled-unicast paths to peers (in unique update groups):
10.1.45.5
Path #1: Received by speaker 0
Flags: 0x4000000009040207, import: 0x20
Advertised IPv4 Unicast paths to update-groups (with more than one peer):
0.3
Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):
0.7
Advertised IPv4 Labeled-unicast paths to peers (in unique update groups):
10.1.45.5
65001, (Received from a RR-client)
10.100.1.10 (metric 2) from 10.100.1.10 (10.100.1.10)
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 16
RP/0/0/CPU0:R4#show route 10.100.1.1/32 detail
Routing entry for 10.100.1.1/32
Known via "bgp 65003", distance 200, metric 0
…
Route version is 0x4 (4)
Local Label: 0x5dc3 (24003)
IP Precedence: Not Set
…
This will allow the cases 1 to 4 in table 1.
To figure out why a local label is still assigned when the “allocate-label” command is removed, run the debug “debug bgp label”.
Here’s an example:
RP/0/0/CPU0:R4#debug bgp label
RP/0/0/CPU0:R4#show debug
#### debug flags set from tty 'con0_0_CPU0' ####
ip-bgp default label flag is ON with value '##########'
It is better to enable this debug for a specific prefix or group of prefixes. Here is an example:
RP/0/0/CPU0:R4#sh running-config route-policy match-prefix
route-policy match-prefix
if destination in (10.100.1.1/32) then
pass
else
drop
endif
end-policy
!
RP/0/0/CPU0:R4#debug bgp label route-policy match-prefix
RP/0/0/CPU0:R4#show debug
#### debug flags set from tty 'con0_0_CPU0' ####
ip-bgp default label flag is ON with value '######match-prefix####'
RP/0/0/CPU0:R4#con t
RP/0/0/CPU0:R4(config)#router bgp 65003
RP/0/0/CPU0:R4(config-bgp)# address-family ipv4 unicast
RP/0/0/CPU0:R4(config-bgp-af)#no allocate-label all
RP/0/0/CPU0:R4(config-bgp-af)#commit
RP/0/0/CPU0:Aug 23 12:43:02.786 : bgp[1048]: [default-lbl] (ip4u): Label computation done: table=TBL:default (1/1), net=10.100.1.1/32: netfl=0x05043001, path=0x1073ed5c(10.1.24.2/32,10.1.24.2,0,0x400000000d060001), pathrcvdlabel=24002: asbr=1, rr=0/1, nhselfcount=1: result="label required"
You can see that this router received a label for the prefix 10.100.1.1/32, is an ASBR, is not an RR, and has next-hop-self for at least one BGP session. This results in this prefix needing a local label.
The local label remains:
RP/0/0/CPU0:R4#show bgp ipv4 unicast 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 13 13
Local Label: 16002 (no rewrite);
Flags: 0x05043001+0x00000200;
Last Modified: Aug 23 12:37:11.133 for 00:05:53
Paths: (1 available, best #1)
Advertised to update-groups (with more than one peer):
0.6
Advertised to peers (in unique update groups):
10.1.46.6 10.100.1.8 10.100.1.7
Path #1: Received by speaker 0
Flags: 0x400000000d060001, import: 0x1f
Advertised to update-groups (with more than one peer):
0.6
Advertised to peers (in unique update groups):
10.1.46.6 10.100.1.8 10.100.1.7
65002 65001
10.1.24.2 from 10.1.24.2 (10.100.1.2)
Received Label 24002
Origin IGP, localpref 100, valid, external, best, group-best, import-candidate
Received Path ID 0, Local Path ID 1, version 13
Origin-AS validity: not-found
RP/0/0/CPU0:R4#show route 10.100.1.1/32 detail
Routing entry for 10.100.1.1/32
Known via "bgp 65003", distance 20, metric 0, [ei]-bgp, labeled unicast (3107)
Tag 65002, type external
Installed Aug 23 12:37:11.440 for 00:06:02
Routing Descriptor Blocks
10.1.24.2, from 10.1.24.2, BGP external
Route metric is 0
Label: 0x5dc2 (24002)
Tunnel ID: None
Extended communities count: 0
NHID:0x0(Ref:0)
Route version is 0x4 (4)
Local Label: 0x3e82 (16002)
IP Precedence: Not Set
QoS Group ID: Not Set
Route Priority: RIB_PRIORITY_NON_RECURSIVE_LOW (11) SVD Type RIB_SVD_TYPE_LOCAL
Download Priority 4, Download Version 28
No advertising protos.
The debug shows the following message when a local label is not required:
RP/0/0/CPU0:Aug 23 13:01:15.801 : bgp[1048]: [default-lbl]: Prefix 10.100.1.1/32:()doesn't require label, releasing
RP/0/0/CPU0:Aug 23 13:01:15.801 : bgp[1048]: [default-lbl]: bgp_label_release_label: perform label release onnet 10.100.1.1/32net retain 0 label_retain 0
If the prefix is in the LFIB depends if the prefix was received labeled or not and if allocate-label applies to that prefix.
The received label is 24002 for the following prefix. It is not installed in the LFIB, because BGP does not have the allocate-label command.
RP/0/0/CPU0:R4#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 4 4
Local Label: 24002
Last Modified: Aug 8 13:52:57.276 for 00:00:36
Paths: (1 available, best #1)
Advertised to update-groups (with more than one peer):
0.6
Advertised to peers (in unique update groups):
10.100.1.7
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.6
Advertised to peers (in unique update groups):
10.100.1.7
65002 65001
10.1.24.2 from 10.1.24.2 (10.100.1.2)
Received Label 24002
Origin IGP, localpref 100, valid, external, best, group-best, labeled-unicast
Received Path ID 0, Local Path ID 0, version 4
Origin-AS validity: not-found
router bgp 65003
bgp unsafe-ebgp-policy
address-family ipv4 unicast
!
RP/0/0/CPU0:R4# show mpls forwarding
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24000 Aggregate 10.1.24.0/24 default 0
24001 Aggregate 10.1.45.0/24 default 0
If the allocate-label command is present, then the local label is present in the LFIB:
router bgp 65003
bgp unsafe-ebgp-policy
address-family ipv4 unicast
allocate-label all
!
RP/0/0/CPU0:R4#show mpls forwarding
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24000 Aggregate 10.1.24.0/24 default 0
24001 Aggregate 10.1.45.0/24 default 0
24002 24002 10.100.1.1/32 10.1.24.2 0
Even if the BGP prefix is received over an LU session, but no local label is assigned, then the route is not advertised over another LU session were NHS is done. This is case 14 in table 1.This is the case if the outgoing BGP session is eBGP.
Example:
RP/0/0/CPU0:R2#show bgp ipv4 unicast 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 3 3
Flags: 0x00001001+0x00000000;
Last Modified: Aug 22 09:00:20.646 for 00:10:56
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Flags: 0x4080000001060001, import: 0x20
Not advertised to any peer
65001
10.1.12.1 from 10.1.12.1 (10.100.1.1)
Received Label 3
Origin IGP, metric 0, localpref 100, valid, external, best, group-best, labeled-unicast
Received Path ID 0, Local Path ID 0, version 3
Origin-AS validity: not-found
RP/0/0/CPU0:R2#show route 10.100.1.1/32 detail
Routing entry for 10.100.1.1/32
Known via "bgp 65002", distance 20, metric 0, labeled unicast (3107)
Tag 65001, type external
Installed Aug 22 09:00:20.416 for 00:10:59
Routing Descriptor Blocks
10.1.12.1, from 10.1.12.1, BGP external
Route metric is 0
Label: 0x100004 (1048580)
Tunnel ID: None
Binding Label: None
Extended communities count: 0
NHID:0x0(Ref:0)
Route version is 0x1 (1)
No local label
IP Precedence: Not Set
…
This is likely caused by not having the command “allocate-label” for address-family unicast under router BGP.
You will need to restart the process BGP when removing the “allocate-label” command in order for the router to remove the local labels for the BGP routes.
The new advertise local-labeled-route command in table 1 is a new command to indicate that a route with local label should not be advertised as an unlabeled route via SAFI-1.
This command is the following:
advertise local-labeled-route [disable]
This command is configured under the neighbor address-family. The function of this command is to indicate whether an IPv4/v6 route with a local label should be advertised or not to the BGP neighbor via IPv4/v6 unicast (SAFI 1).
The default behavior is to advertise routes with a local label.
The new command could also be configured as:
advertise local-labeled-route safi-unicast [disable]
This command is configured under the af-group of the BGP section. Its function is the same as the one above and applies to all BGP neighbors.
The default behavior is to advertise routes with a local label.
The line “Advertise routes with local-label via Unicast SAFI“ or “Do not advertise routes with local-label via Unicast SAFI” is present on the command" show bgp neighbor" under the address family IPv4 Unicast to indicate that the BGP speaker permits the advertisement of routes with local label or not.
Example for the default behavior:
RP/0/0/CPU0:R4#show bgp neighbor 10.1.45.5
…
For Address Family: IPv4 Unicast
BGP neighbor version 5
Update group: 0.1 Filter-group: 0.5 No Refresh request being processed
Extended Nexthop Encoding: advertised and received
Route refresh request: received 0, sent 0
0 accepted prefixes, 0 are bestpaths
Exact no. of prefixes denied : 0.
Cumulative no. of prefixes denied: 0.
Prefix advertised 2, suppressed 0, withdrawn 0
Maximum prefixes allowed 1048576
Threshold for warning message 75%, restart interval 0 min
An EoR was not received during read-only mode
Last ack version 5, Last synced ack version 0
Outstanding version objects: current 0, max 1, refresh 0
Additional-paths operation: None
Advertise routes with local-label via Unicast SAFI
…
or
RP/0/0/CPU0:R4# conf t
RP/0/0/CPU0:R4(config)#router bgp 65003
RP/0/0/CPU0:R4(config-bgp)# neighbor 10.1.45.5
RP/0/0/CPU0:R4(config-bgp-nbr)# address-family ipv4 unicast
RP/0/0/CPU0:R4(config-bgp-nbr-af)#advertise local-labeled-route disable
RP/0/0/CPU0:R4(config-bgp-nbr-af)#commit
RP/0/0/CPU0:R4#show bgp neighbor 10.1.45.5
BGP neighbor is 10.1.45.5
…
For Address Family: IPv4 Unicast
BGP neighbor version 5
Update group: 0.1 Filter-group: 0.5 (Update-group Change
pending)
No Refresh request being processed
Extended Nexthop Encoding: advertised and received
Route refresh request: received 0, sent 0
0 accepted prefixes, 0 are bestpaths
Exact no. of prefixes denied : 0.
Cumulative no. of prefixes denied: 0.
Prefix advertised 2, suppressed 0, withdrawn 0
Maximum prefixes allowed 1048576
Threshold for warning message 75%, restart interval 0 min
An EoR was not received during read-only mode
Last ack version 5, Last synced ack version 0
Outstanding version objects: current 0, max 1, refresh 0
Additional-paths operation: None
Do not advertise routes with local-label via Unicast SAFI
There are no changes in the bestpath calculation process. If a path is SAFI 1 or SAFI 4 or if the path has a label or not, makes no difference in the bestpath calculation process. Hence, there is no preference between a SAFI 1 or SAFI 4 path. This is regardless if there is SAFI 1/SAFI 4 on the same BGP session or on different sessions. So, if one BGP session is SAFI 1 and 4, and a prefix is received over both address families, then the best path calculation will pick one as the best path, since all attributes are the same. If all BGP attributes are the same between the U and LU path, the path received last, becomes the best path.
If the SAFI 1 and SAFI 4 paths are received from different BGP peers, there is always a difference in the paths leading to BGP always picking the same best path from the two paths. Even if in this case all attributes are the same, the neighbor address is different. Looking at the BGP Best Path Selection Algorithm, the path from the neighbor with the lowest neighbor address (final step 13) is picked as the best path.
Use the command “show bgp <AFI> <SAFI> <prefix> bestpath-compare” to verify the reason why the best path is best.
This preference can be made by the user, by using RPL.
Here’s an example of such RPL.
RP/0/0/CPU0:R7#show bgp ipv4 un 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 682 682
Flags: 0x00003001+0x00010000;
Last Modified: Aug 28 13:16:26.826 for 00:00:10
Paths: (2 available, best #2)
Not advertised to any peer
Path #1: Received by speaker 0
Flags: 0x4000000000020005, import: 0x20
Not advertised to any peer
65001
10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)
Origin IGP, metric 0, localpref 100, valid, internal
Received Path ID 1, Local Path ID 0, version 0
Originator: 10.100.1.10, Cluster list: 10.100.1.4
Path #2: Received by speaker 0
Flags: 0x4080000001060005, import: 0x20
Not advertised to any peer
65001
10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)
Received Label 24003
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, labeled-unicast
Received Path ID 1, Local Path ID 0, version 682
Originator: 10.100.1.10, Cluster list: 10.100.1.4
The LU path is the best.
RPL with weight is used to prefer the U path.
route-policy weight
if destination in (10.100.1.1/32) then
set weight 60000
endif
end-policy
router bgp 65003
address-family ipv4 unicast
additional-paths receive
additional-paths send
!
neighbor 10.100.1.4
remote-as 65003
update-source Loopback0
address-family ipv4 unicast
route-policy weight in
!
address-family ipv4 labeled-unicast
!
!
RP/0/0/CPU0:R7#show bgp ipv4 un 10.100.1.1/32 bestpath-compare
BGP routing table entry for 10.100.1.1/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 726 726
Last Modified: Aug 28 13:39:27.826 for 00:04:54
Paths: (2 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
65001
10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)
Origin IGP, metric 0, localpref 100, weight 60000, valid, internal, best, group-best
Received Path ID 1, Local Path ID 0, version 726
Originator: 10.100.1.10, Cluster list: 10.100.1.4
best of AS 65001, Overall best
Path #2: Received by speaker 0
Not advertised to any peer
65001
10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)
Received Label 24003
Origin IGP, metric 0, localpref 100, valid, internal, labeled-unicast
Received Path ID 1, Local Path ID 0, version 0
Originator: 10.100.1.10, Cluster list: 10.100.1.4
Lower weight than best path (path #1)
The U path is now the best.
There is no new command to prefer labeled paths over unlabeled paths. You can just configure the RPL either under address-family unicast or labeled-unicast under a BGP neighbor.
To debug the BGP update propagation in IOS-XR, you can turn on the following debug command: debug bgp update <BGP neighbor> in | out.
This will show the incoming or outgoing BGP update from or to that BGP speaker. The address family is shown as (ip4u) for unlabeled IPv4 uncast (AFI 1/SAFI 1) or as (ipv4lu) for labeled IPv4 unicast (AFI 1/SAFI 4). The equivalent occurs for IPv6.
There is a new field “labeled-unicast” that indicates that the path is learnt via SAFI 4.
Example:
RP/0/0/CPU0:R1#show bgp ipv4 unicast 10.100.1.7/32
BGP routing table entry for 10.100.1.7/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 26 26
Last Modified: Sep 4 10:45:44.551 for 00:29:11
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.100.1.4 (metric 3) from 10.100.1.102 (10.100.1.4)
Received Label 24000
Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, labeled-unicast
Received Path ID 0, Local Path ID 1, version 26
Originator: 10.100.1.4, Cluster list: 10.100.1.2
To verify if the prefix is advertised, you can use the “show bgp … neighbors” command with the keyword ”advertised-routes” at the end.
Example:
R4 advertises 10.100.1.1/32 to neighbor 10.100.1.7 twice because add-path is enabled (the two paths are different).
RP/0/0/CPU0:R4#show bgp ipv4 labeled-unicast neighbors 10.100.1.7 advertised-routes
Network Next Hop From AS Path
10.1.24.0/24 10.100.1.4 Local ?
10.1.34.0/24 10.100.1.4 Local ?
10.1.45.0/24 10.100.1.4 Local ?
10.1.46.0/24 10.100.1.4 Local ?
10.1.47.0/24 10.100.1.4 Local ?
10.1.48.0/24 10.100.1.4 Local ?
10.1.49.0/24 10.100.1.4 Local ?
10.1.104.0/24 10.100.1.4 Local ?
10.1.114.0/24 10.100.1.4 Local ?
10.100.1.1/32 10.100.1.4 10.100.1.9 65001i
10.100.1.10 65001i
10.100.1.4/32 10.100.1.4 Local ?
Processed 11 prefixes, 12 paths
The rules from table 1 apply. With Unified MPLS or Seamless MPLS, an Area Border Router (ABR) acts as route-reflector but is also the next-hop for the iBGP routes. The ABRs are in the forwarding path of the labeled traffic. The ABRs must have the explicit configuration for next-hop-self.
interface Loopback0
ipv4 address 10.100.1.7 255.255.255.255
!
interface Loopback1
ipv4 address 10.100.1.107 255.255.255.255
!
router bgp 65003
address-family ipv4 unicast
!
neighbor 10.100.1.4 -> towards loopback0 on peer
remote-as 65003
update-source Loopback0
address-family ipv4 unicast
!
!
neighbor 10.100.1.104 -> towards loopback1 on peer
remote-as 65003
update-source Loopback1
address-family ipv4 labeled-unicast
!
The U and LU paths are send/received over two different BGP sessions.
RP/0/0/CPU0:R7#show bgp ipv4 unicast 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 753 753
Flags: 0x00001001+0x00010000;
Last Modified: Aug 28 14:06:40.826 for 00:22:10
Paths: (2 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Flags: 0x4000000001060005, import: 0x20
Not advertised to any peer
65001
10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
Received Path ID 1, Local Path ID 0, version 753
Originator: 10.100.1.10, Cluster list: 10.100.1.4
Path #2: Received by speaker 0
Flags: 0x4080000000020005, import: 0x20
Not advertised to any peer
65001
10.100.1.104 (metric 2) from 10.100.1.104 (10.100.1.10)
Received Label 24003
Origin IGP, metric 0, localpref 100, valid, internal, labeled-unicast
Received Path ID 1, Local Path ID 0, version 0
Originator: 10.100.1.10, Cluster list: 10.100.1.4