Separate BGP RIBs for Labeled Routes
This chapter provides information about separate border gateway protocol (BGP) route information bases (RIBs) for labeled-unicast (BGP-LU) routes.
Applicability
The CLI in the latest update corresponds to SR Linux Release 26.3.3.
Overview
BGP separate labeled-IPv4 RIB implementation
RR-1 with separate labeled-IPv4 RIB implementation shows how route reflector RR-1 sends a labeled-IPv4 route to PE-2 with label X and next hop PE-1.
A separate RIB is used for labeled-IPv4 routes. With this implementation, client PE-2 learns the best labeled-IPv4 route and client PE-4 learns the best unlabeled IPv4 route. RR-1 does not need to set next-hop-self and traffic can be sent directly from PE-2 to PE-1 and from PE-4 to PE-3. The RR is used only for control traffic, as intended.
Seamless MPLS - Separate labeled-IPv4 implementation shows a seamless MPLS use case, which is a good example of the coexistence of labeled (AFI 1/SAFI 4) and unlabeled (AFI 1/SAFI 1) BGP sessions.
RIB architecture
System architecture with separate RIBs for labeled-unicast and unlabeled routes shows the system architecture with four separate RIBs for IPv4 and IPv6 routes.
Labeled-unicast routes from peers are stored in a labeled RIB and unlabeled routes from the same or different peers are stored in a non-labeled RIB. Both labeled and unlabeled routes can be sent and received to and from the same peer. Different sets of routes can be advertised to labeled or unlabeled peers. Labeled and unlabeled BGP sessions are using the common equal cost multipath (ECMP) and multipath limit.
More user control is provided over the RTM route import process. By default, a RIB imports all non-BGP active routes from RTM, but a user-defined route policy can be applied. Route policies can be used to reduce BGP memory usage.
The address families mapped to the RIBs are: ipv4, label-ipv4, ipv6, label-ipv6. In route policies, protocol types bgp and bgp-label can be used.
The default RTM preference for labeled IP routes is configurable (label-preference) in the bgp context of the base router or an IP-VRF. The default preference is 170.
Configuration
All the examples are based on labeled and unlabeled IPv4 addresses. For IPv6, the configuration is similar.
Example IPv4 topology shows the example topology using IPv4 addresses.
The initial configuration includes:
-
Interfaces
-
IS-IS in AS 64500 (PE-1, PE-2, PE-4)
-
LDP in AS 64500
-
Loopback addresses 10.3.3.3/32 in PE-3 and 10.4.4.4/32 in PE-4
-
Import policy "import-bgp" accepting BGP routes (match protocol bgp) on PE-1
-
Export policy "export-bgp" accepting routes from protocol local and with matching prefix on PE-3, PE-4:
# on PE-3, PE-4 (, PE-1):
enter candidate
routing-policy {
prefix-set ps-10.0.0.0 {
prefix 10.0.0.0/8 mask-length-range 32..32 {
}
}
policy rp-export-bgp {
statement stmt-10 {
match {
protocol local
prefix {
prefix-set ps-10.0.0.0
}
}
action {
policy-result accept
}
}
}The following examples are configured and verified:
Coexistence of labeled and unlabeled address families for BGP
BGP sessions shows the EBGP and IBGP sessions that are established between the nodes and the routes advertised for the loopback addresses.
PE-1 acts as RR for PE-2 and PE-4, and it is an autonomous system border router (ASBR) toward PE-3. PE-1 has two single-family connections: unlabeled IPv4 to PE-3 and labeled IPv4 to PE-4. PE-1 also has one dual-family connection to PE-2. The BGP configuration on PE-1 is as follows:
# on PE-1:
enter candidate
network-instance default {
protocols {
bgp {
admin-state enable
router-id 192.0.2.1
autonomous-system 64500
bgp-label {
labeled-unicast {
dynamic-label-block dlb-bgp-lu
}
}
afi-safi ipv4-unicast {
admin-state enable
}
afi-safi ipv4-labeled-unicast {
admin-state enable
ipv4-labeled-unicast {
next-hop-resolution {
ipv4-next-hops {
tunnel-resolution {
allowed-tunnel-types [
ldp
]
}
}
}
}
}
group grp-EBGP {
peer-as 64501
import-policy [
rp-import-bgp
]
}
group grp-IBGP {
peer-as 64500
# export-policy [
# rp-export-bgp # export policy is required in a later example
# ]
route-reflector {
client true
cluster-id 192.0.2.1
}
}
neighbor 192.0.2.2 {
peer-group grp-IBGP
afi-safi ipv4-unicast {
admin-state enable
}
afi-safi ipv4-labeled-unicast {
admin-state enable
}
}
neighbor 192.0.2.4 {
peer-group grp-IBGP
afi-safi ipv4-unicast {
admin-state disable # do not inherit from global BGP context
}
afi-safi ipv4-labeled-unicast {
admin-state enable
}
}
neighbor 192.168.13.2 {
peer-group grp-EBGP
afi-safi ipv4-unicast {
admin-state enable
}
afi-safi ipv4-labeled-unicast {
admin-state disable # do not inherit from global BGP context
}
}
}The BGP configuration on PE-2 is as follows:
# on PE-2:
enter candidate
network-instance default {
protocols {
bgp {
admin-state enable
router-id 192.0.2.2
autonomous-system 64500
bgp-label {
labeled-unicast {
dynamic-label-block dlb-bgp-lu
}
}
afi-safi ipv4-unicast {
admin-state enable
}
afi-safi ipv4-labeled-unicast {
admin-state enable
ipv4-labeled-unicast {
next-hop-resolution {
ipv4-next-hops {
tunnel-resolution {
allowed-tunnel-types [
ldp
]
}
}
}
}
}
group grp-IBGP {
peer-as 64500
}
neighbor 192.0.2.1 {
peer-group grp-IBGP
}
}The BGP configuration on PE-3 in AS 64501 is as follows:
# on PE-3:
enter candidate
network-instance default {
protocols {
bgp {
admin-state enable
router-id 192.0.2.3
autonomous-system 64501
afi-safi ipv4-unicast {
admin-state enable
}
group grp-EBGP {
peer-as 64500
export-policy [
rp-export-bgp
]
}
neighbor 192.168.13.1 {
peer-group grp-EBGP
}
}The BGP configuration on PE-4 is as follows:
# on PE-4:
enter candidate
network-instance default {
protocols {
bgp {
admin-state enable
router-id 192.0.2.4
autonomous-system 64500
bgp-label {
labeled-unicast {
dynamic-label-block dlb-bgp-lu
}
}
afi-safi ipv4-labeled-unicast {
admin-state enable
ipv4-labeled-unicast {
next-hop-resolution {
ipv4-next-hops {
tunnel-resolution {
allowed-tunnel-types [
ldp
]
}
}
}
}
}
group grp-IBGP {
peer-as 64500
export-policy [
rp-export-bgp
]
}
neighbor 192.0.2.1 {
peer-group grp-IBGP
}
}The following command on PE-1 shows that there is a dual-family connection with PE-2: IPv4 and labeled IPv4. PE-1 has a labeled IPv4 connection with PE-4 and an IPv4 connection with PE-3. PE-1 receives and uses one unlabeled route from PE-3 and re-advertises it to PE-2. PE-1 receives and uses one labeled route from PE-4 and re-advertises it to PE-2.
--{ + running }--[ ]--
A:admin@PE-1# show network-instance default protocols bgp neighbor
---------------------------------------------------------------------------------------------------------------------------------------------------
BGP neighbor summary for network-instance "default"
Peer flags: see legend after the summary when applicable.
---------------------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------------------
+------------------+--------------------------+------------------+------+----------+--------------+--------------+---------------------------------
| Net-Inst | Peer | Group | Flag | Peer-AS | State | Uptime | AFI/SAFI [Rx/Active/Tx]
| | | | s | | | |
+==================+==========================+==================+======+==========+==============+==============+=================================
| default | 192.0.2.2 | grp-IBGP | S | 64500 | established | 0d:0h:1m:55s | ipv4-labeled-unicast [0/0/1]
| | | | | | | | ipv4-unicast [0/0/1]
| default | 192.0.2.4 | grp-IBGP | S | 64500 | established | 0d:0h:1m:27s | ipv4-labeled-unicast [1/1/0]
| default | 192.168.13.2 | grp-EBGP | S | 64501 | established | 0d:0h:1m:41s | ipv4-unicast [1/1/0]
+------------------+--------------------------+------------------+------+----------+--------------+--------------+---------------------------------
---------------------------------------------------------------------------------------------------------------------------------------------------
Summary:
3 configured neighbors, 3 configured sessions are established, 0 disabled peers
0 dynamic peers
---------------------------------------------------------------------------------------------------------------------------------------------------
Peer flag legend:
S Static neighborThe unlabeled IPv4 routes on PE-1 include unlabeled routes imported from other PEs, in this case, only the loopback address 10.3.3.3/32 advertised by EBGP peer PE-3, as follows:
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance default protocols bgp routes ipv4 prefix 10.0.0.0/8 or-longer
----------------------------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.3.3.3/32" network-instance "default"
----------------------------------------------------------------------------------------------------------
Network: 10.3.3.3/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.168.13.2
Route Preference: MED is -, No LocalPref
BGP next-hop : 192.168.13.2
Path : i [64501]
Communities : None
Path 1 was advertised to:
[ 192.0.2.2 ]
----------------------------------------------------------------------------------------------------------The labeled-unicast IPv4 routes on PE-1 include labeled routes imported from other PEs, in this case, only the loopback address 10.4.4.4/32 advertised by PE-4, as follows:
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance default protocols bgp routes ipv4-labeled-unicast prefix 10.0.0.0/8 or-longer
----------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.4.4.4/32" network-instance "default"
----------------------------------------------------------------------------------------
Network: 10.4.4.4/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.4
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.4
Path : i
Communities : None
Path 1 was advertised to:
[ 192.0.2.2 ]
----------------------------------------------------------------------------------------PE-1 re-advertises prefix 10.3.3.3/32 as an unlabeled route with next-hop 192.168.13.2 and PE-2 imports the prefix 10.3.3.3/32 in its unlabeled RIB, as follows:
--{ + running }--[ ]--
A:admin@PE-2# show / network-instance default protocols bgp routes ipv4 prefix 10.0.0.0/8 or-longer
-----------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.3.3.3/32" network-instance "default"
-----------------------------------------------------------------------------------------
Network: 10.3.3.3/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.1
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.168.13.2
Path : i [64501]
Communities : None
Path 1 was advertised to:
[ ]
-----------------------------------------------------------------------------------------PE-1 re-advertises prefix 10.4.4.4/32 as a labeled IPv4 route with next-hop 192.0.2.4 and PE-2 imports the prefix 10.4.4.4/32 in its labeled RIB:
--{ + running }--[ ]--
A:admin@PE-2# show / network-instance default protocols bgp routes ipv4-labeled-unicast prefix 10.0.0.0/8 or-longer
------------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.4.4.4/32" network-instance "default"
------------------------------------------------------------------------------------------
Network: 10.4.4.4/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.1
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.4
Path : i
Communities : None
Path 1 was advertised to:
[ ]
-------------------------------------------------------------------------------------------As expected, the prefixes from address family label-ipv4 are advertised independently from the prefixes from address family ipv4.
Applying next-hop-self
PE-1 applies next-hop-self toward neighbor PE-2 shows that PE-1 applies next-hop-self for BGP updates toward PE-2.
On PE-1, next-hop-self is enabled for neighbor PE-2 only, as follows:
# on PE-1:
enter candidate
network-instance default {
protocols {
bgp {
neighbor 192.0.2.2 {
next-hop-self trueThis applies to both address families. The next hop for unlabeled route 10.3.3.3/32 is 192.0.2.1 instead of 192.168.13.2, as follows:
--{ + running }--[ ]--
A:admin@PE-2# show / network-instance default protocols bgp routes ipv4 prefix 10.0.0.0/8 or-longer
-----------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.3.3.3/32" network-instance "default"
-----------------------------------------------------------------------------------------
Network: 10.3.3.3/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.1
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.1
Path : i [64501]
Communities : None
Path 1 was advertised to:
[ ]
-----------------------------------------------------------------------------------------The labeled-unicast route 10.4.4.4/32 has next hop 192.0.2.1 instead of 192.0.2.4, as follows:
--{ + running }--[ ]--
A:admin@PE-2# show / network-instance default protocols bgp routes ipv4-labeled-unicast prefix 10.0.0.0/8
or-longer
-----------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.4.4.4/32" network-instance "default"
-----------------------------------------------------------------------------------------
Network: 10.4.4.4/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.1
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.1
Path : i
Communities : None
Path 1 was advertised to:
[ ]
-----------------------------------------------------------------------------------------On PE-1, the next-hop-self configuration for neighbor PE-2 is removed as follows:
# on PE-1:
enter candidate
network-instance default {
protocols {
bgp {
neighbor 192.0.2.2 {
delete next-hop-selfAn export policy is configured to ensure that next-hop-self is only applied for address family ipv4. The route policy is configured as follows:
# on PE-1:
enter candidate
routing-policy {
policy rp-export-nhs {
statement stmt-10 {
match {
protocol bgp
}
action {
policy-result accept
bgp {
next-hop {
set self
}
}
}
}
statement stmt-20 {
match {
protocol bgp-label
}
action {
policy-result accept
}
}
}
}The export policy "export-nhs" is configured for neighbor PE-2, as follows:
# on PE-1:
enter candidate
network-instance default {
protocols {
bgp {
neighbor "192.0.2.2" {
export-policy [
rp-export-nhs
]Applying next-hop-self to unlabeled IP-4 routes to neighbor PE-2 shows that next-hop-self is applied to unlabeled IPv4 routes only.
With this export policy, only the unlabeled route 10.3.3.3/32 has next hop 192.0.2.1, while the BGP labeled-unicast (BGP-LU) route 10.4.4.4/32 has next hop 192.0.2.4, as follows:
--{ + running }--[ ]--
A:admin@PE-2# show / network-instance default protocols bgp routes ipv4 prefix 10.0.0.0/8 or-longer
----------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.3.3.3/32" network-instance "default"
----------------------------------------------------------------------------------------
Network: 10.3.3.3/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.1
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.1
Path : i [64501]
Communities : None
Path 1 was advertised to:
[ ]
-----------------------------------------------------------------------------------------{ + running }--[ ]--
A:admin@PE-2# show / network-instance default protocols bgp routes ipv4-labeled-unicast prefix 10.0.0.0/8 or-longer
---------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.4.4.4/32" network-instance "default"
---------------------------------------------------------------------------------------
Network: 10.4.4.4/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.1
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.4
Path : i
Communities : None
Path 1 was advertised to:
[ ]
---------------------------------------------------------------------------------------The export policy "export-nhs" toward neighbor PE-2 is removed as follows:
# on PE-1:
enter candidate
network-instance default {
protocols {
bgp {
neighbor 192.0.2.2 {
delete export-policy Export policies to advertise routes as labeled or unlabeled
PE-1 advertises prefixes 10.1.1.1/32 and 10.11.11.11/32 shows that two loopback addresses are configured in PE-1 to be advertised: prefix 10.1.1.1/32 and 10.11.11.11/32. Initially, the export policy on PE-1 is identical to the export policy on PE-3 and PE-4, so there are no route policies applied for a selective export as labeled or unlabeled route.
By default, these prefixes are advertised as both labeled and unlabeled routes toward dual-family neighbor PE-2. On PE-2, the unlabeled IPv4 RIB contains prefixes 10.1.1.1/32 and 10.11.11.11/32, as follows:
--{ + running }--[ ]--
A:admin@PE-2# show / network-instance default protocols bgp routes ipv4 prefix 10.0.0.0/8 or-longer
--------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.1.1.1/32" network-instance "default"
--------------------------------------------------------------------------------------
Network: 10.1.1.1/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.1
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.1
Path : i
Communities : None
Path 1 was advertised to:
[ ]
--------------------------------------------------------------------------------------
---snip---
--------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.11.11.11/32" network-instance "default"
--------------------------------------------------------------------------------------
Network: 10.11.11.11/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.1
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.1
Path : i
Communities : None
Path 1 was advertised to:
[ ]
--------------------------------------------------------------------------------------The labeled-IPv4 RIB on PE-2 also contains prefixes 10.1.1.1/32 and 10.11.11.11/32, as follows:
--{ + running }--[ ]--
A:admin@PE-2# show / network-instance default protocols bgp routes ipv4-labeled-unicast prefix 10.0.0.0/8 or-longer
--------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.1.1.1/32" network-instance "default"
--------------------------------------------------------------------------------------
Network: 10.1.1.1/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.1
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.1
Path : i
Communities : None
Path 1 was advertised to:
[ ]
--------------------------------------------------------------------------------------
---snip---
--------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.11.11.11/32" network-instance "default"
--------------------------------------------------------------------------------------
Network: 10.11.11.11/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.1
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.1
Path : i
Communities : None
Path 1 was advertised to:
[ ]
--------------------------------------------------------------------------------------In many cases, it is not required to advertise both a labeled route and an unlabeled route. In the following example, two different routing policies are configured. The first policy is configured to advertise prefix 10.1.1.1/32 as a labeled-IPv4 route when the policy is applied in the afi-safi ipv4-labeled-unicast context for neighbor 192.0.2.2, as follows:
# on PE-1:
enter candidate
routing-policy {
prefix-set ps-10.1.1.1 {
prefix 10.1.1.1/32 mask-length-range exact {
}
}
policy rp-export-bgp-lu-1 {
default-action {
policy-result reject
}
statement stmt-10 {
match {
prefix {
prefix-set ps-10.1.1.1
}
}
action {
policy-result accept
}
}
}
}
network-instance default {
protocols {
bgp {
neighbor 192.0.2.2 {
afi-safi ipv4-labeled-unicast {
admin-state enable
export-policy [
rp-export-bgp-lu-1
]
}The second routing policy advertises prefix 10.11.11.11/32 as an unlabeled IPv4 route when the policy is applied for afi-safi ipv4-unicast:
# on PE-1:
enter candidate
routing-policy {
prefix-set ps-10.11.11.11 {
prefix 10.11.11.11/32 mask-length-range exact {
}
}
policy rp-export-bgp-11 {
default-action {
policy-result reject
}
statement stmt-10 {
match {
prefix {
prefix-set ps-10.11.11.11
}
}
action {
policy-result accept
}
}
}
}
network-instance default {
protocols {
bgp {
neighbor 192.0.2.2 {
afi-safi ipv4-unicast {
admin-state enable
export-policy [
rp-export-bgp-11
]
}Prefix 10.11.11.11/32 is received as an unlabeled route on PE-2 and stored in the unlabeled RIB, but prefix 10.1.1.1/32 is not, as follows:
--{ + running }--[ ]--
A:admin@PE-2# show / network-instance default protocols bgp routes ipv4 prefix 10.0.0.0/8 or-longer
--------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.11.11.11/32" network-instance "default"
--------------------------------------------------------------------------------------
Network: 10.11.11.11/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.1
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.1
Path : i
Communities : None
Path 1 was advertised to:
[ ]
--------------------------------------------------------------------------------------On PE-2, prefix 10.1.1.1/32 is received as a labeled route and stored in the labeled-IPv4 RIB, but prefix 10.11.11.11/32 is not, as follows:
--{ + running }--[ ]--
A:admin@PE-2# show / network-instance default protocols bgp routes ipv4-labeled-unicast prefix 10.0.0.0/8 or-longer
--------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.1.1.1/32" network-instance "default"
--------------------------------------------------------------------------------------
Network: 10.1.1.1/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.1
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.1
Path : i
Communities : None
Path 1 was advertised to:
[ ]
----------------------------------------------------------------------------------------This selective route advertisement from PE-1 reduces the memory usage for the RIBs on PE-2.
RR behavior with a mix of labeled and unlabeled BGP sessions
RR with labeled and unlabeled BGP sessions shows a slightly different setup, with all PEs in the AS 64500 and RR-1 acting as the RR for all PEs. There are no dual-family connections. PE-3 and PE-4 have an unlabeled BGP session with RR-1 and PE-2 has a labeled BGP connection with RR-1. RR-1 has add-path=2 capability configured for neighbor PE-2. RR-1 receives the same prefix 10.7.7.7/32 from two neighbors: PE-3 and PE-4.
On RR-1, BGP is configured as follows:
# on RR-1:
enter candidate
network-instance default {
protocols {
bgp {
admin-state enable
autonomous-system 64500
router-id 192.0.2.1
bgp-label {
labeled-unicast {
dynamic-label-block dlb-bgp-lu
}
}
afi-safi ipv4-labeled-unicast {
admin-state enable
ipv4-labeled-unicast {
next-hop-resolution {
ipv4-next-hops {
tunnel-resolution {
allowed-tunnel-types [
ldp
]
}
}
}
}
}
afi-safi ipv4-unicast {
admin-state enable
}
trace-options {
flag update {
}
}
group grp-IBGP {
peer-as 64500
route-reflector {
client true
cluster-id 192.0.2.1
}
}
neighbor "192.0.2.2" {
peer-group grp-IBGP
afi-safi ipv4-labeled-unicast {
admin-state enable
add-paths {
receive true
send true
send-max 2
}
}
afi-safi ipv4-unicast {
admin-state disable
}
}
neighbor "192.0.2.3" {
peer-group grp-IBGP
afi-safi ipv4-labeled-unicast {
admin-state disable
}
afi-safi ipv4-unicast {
admin-state enable
}
}
neighbor "192.0.2.4" {
peer-group grp-IBGP
afi-safi ipv4-labeled-unicast {
admin-state disable
}
afi-safi ipv4-unicast {
admin-state enable
}
}
}RR-1 receives the prefix 10.7.7.7/32 from neighbors PE-3 and PE-4, as follows:
--{ + running }--[ ]--
A:admin@RR-1# show / network-instance default protocols bgp routes ipv4 prefix 10.0.0.0/8 or-longer
------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.7.7.7/32" network-instance "default"
------------------------------------------------------------------------------------
Network: 10.7.7.7/32
Received Paths: 2
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.3
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.3
Path : i
Communities : None
Path 2: <Valid,>
Route source : neighbor 192.0.2.4
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.4
Path : i
Communities : None
Path 1 was advertised to:
[ 192.0.2.4 ]
------------------------------------------------------------------------------------Both routes are unlabeled and BGP updates from unlabeled sessions are by default not exported to a labeled-IPv4 session, as shown in Updates from unlabeled sessions not propagated to labeled sessions (default).
PE-2 does not receive prefix 10.7.7.7/32, neither as unlabeled route, nor as labeled route, as follows:
[--{ + running }--[ ]--
A:admin@PE-2# show / network-instance default protocols bgp routes ipv4 prefix 10.0.0.0/8 or-longer
--{ + running }--[ ]--
A:admin@PE-2# show / network-instance default protocols bgp routes ipv4-labeled-unicast prefix 10.0.0.0/8 or-longerA route policy is created on RR-1 to accept labeled IPv4 routes, as follows:
# on RR-1:
enter candidate
routing-policy {
prefix-set ps-10.0.0.0 {
prefix 10.0.0.0/8 mask-length-range 32..32 {
}
}
policy rp-import-bgp-to-bgp-lu {
default-action {
policy-result reject
}
statement stmt-10 {
match {
protocol bgp
prefix {
prefix-set ps-10.0.0.0
}
}
action {
policy-result accept
}
}
}This policy accepts BGP routes with matching prefixes. For route 10.7.7.7/32 to be advertised to the labeled peer PE-2, it is sufficient to configure this policy in the RIB management ipv4-labeled-unicast table, as follows:
# on RR-1:
enter candidate
network-instance default {
protocols {
bgp {
rib-management {
table ipv4-labeled-unicast {
route-table-import rp-import-bgp-to-bgp-lu
}
}For allowing unlabeled route 10.7.7.7/32 to be advertised on a labeled session, it is sufficient to have a route-table-import for labeled-IPv4 only. However, it is possible to configure RIB leaking in both ways: from unlabeled IPv4 BGP RIB to labeled-IPv4 BGP RIB and vice versa.
RIB leaking from IPv4 BGP RIB to labeled-IPv4 BGP RIB shows this RIB leaking process.
After applying this RIB leaking, RR-1 advertises prefix 10.7.7.7/32 to PE-2. Therefore, RR-1 needs to add a label to the route and RR-1 needs to set next-hop-self. RR-1 advertises only one labeled route for prefix 10.7.7.7/32, with next hop 192.0.2.1, as follows:
--{ + running }--[ ]--
A:admin@RR-1# show network-instance default protocols bgp neighbor 192.0.2.2 advertised-routes ipv4-labeled-unicast
-------------------------------------------------------------------------------------------------------------------
Peer : 192.0.2.2, remote AS: 64500, local AS: 64500
Type : static
Description : None
Group : grp-IBGP
-------------------------------------------------------------------------------------------------------------------
Origin codes: i=IGP, e=EGP, ?=incomplete
+---------------------------------------------------------------------------------------------------------------+
| Network Path-id Next Hop MED LocPref AsPath Origin |
+===============================================================================================================+
| 10.7.7.7/32 0 192.0.2.1 - 100 i |
+---------------------------------------------------------------------------------------------------------------+
-------------------------------------------------------------------------------------------------------------------
1 advertised BGP routes
-------------------------------------------------------------------------------------------------------------------The BGP update message is as follows:
2026-06-03T07:48:35.600712+00:00 RR-1 sr_bgp_mgr: bgp|16428|16537|00004|TR||D: VR default (1) Peer 1: 192.0.2.2 UPDATE: Peer 1: 192.0.2.2 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 42
Flag: 0x90 Type: 14 Len: 17 Multiprotocol Reachable NLRI:
Address Family LBL-IPV4
NextHop len 4 NextHop 192.0.2.1
10.7.7.7/32 Label 40000
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0x80 Type: 10 Len: 4 Cluster ID:
192.0.2.1On PE-2, the following labeled BGP route is imported:
--{ + running }--[ ]--
A:admin@PE-2# show / network-instance default protocols bgp routes ipv4-labeled-unicast prefix 10.0.0.0/8 or-longer detail
----------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.7.7.7/32" network-instance "default"
----------------------------------------------------------------------------------------
Network: 10.7.7.7/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.1
Route Preference : MED is -, LocalPref is 100
BGP next-hop : 192.0.2.1
Path : i
Received Label : [40000]
Communities : None
RR Attributes : No Originator-ID, Cluster-List is [ 192.0.2.1 ]
Aggregation : Not an aggregate route
Unknown Attr : None
Invalid Reason : None
Tie Break Reason : none
Route Flap Damping: None
---------------------------------------------------------------------------------------Conclusion
The BGP RIB architecture with separate RIBs for unlabeled and labeled-unicast routes supports unlabeled sessions and labeled sessions in parallel. By default, labeled routes are not advertised to unlabeled sessions and vice versa. Route-table import policies for RIB management allow route leaking between separate RIBs: unlabeled BGP RIB and labeled-unicast BGP RIB.