Support Support Downloads Knowledge Base Apex Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[M/MX/PTX/T] How to set both inet unicast and inet labeled unicast NLRI for a BGP peer

0

0

Article ID: KB37086 KB Last Updated: 18 Jun 2021Version: 1.0
Summary:

This article demonstrates how to configure both inet unicast and inet labeled unicast Network Layer Reachability Information (NLRI) for a Border Gateway Protocol (BGP) peer if required.

Symptoms:

When both the inet unicast and inet labeled unicast address families are enabled for a BGP neighbor, the following message is displayed during commit:

R1_re# set protocols bgp group BGP_RR family inet unicast 

[edit]
R1_re# set protocols bgp group BGP_RR family inet labeled-unicast 

[edit]
R1_re# commit and-quit 
[edit protocols]
  'bgp'
    Error in neighbor 192.168.2.2 of group BGP_RR:
peer cannot have both inet unicast and inet labeled-unicast nlri
error: configuration check-out failed

[edit]
Cause:

BGP-LU has the following behavior by default. 

  1. If a router learns a BGP-LU prefix, it will place it in the inet.0 table.

  2. If a BGP route exists in the inet.0 table, the router will advertise it with a label. 

In the following example, R1 is receiving a prefix from its eBGP peer (AS65001) without any label and is advertising it with a label to its RR. R1 has established an iBGP session with RR with family inet labeled-unicast. 

Note: In the above topology, R1 is Router 1 and RR is the Route Reflector. R1 has eBGP neighborship with two different Autonomous Systems: 65001 and 65005.

R1_re> show route receive-protocol bgp 10.1.1.2 detail 

inet.0: 70 destinations, 70 routes (70 active, 0 holddown, 0 hidden)
* 172.16.1.0/24 (1 entry, 1 announced)
     Accepted
     Nexthop: 10.1.1.2
     AS path: 65001 I 
================================================

R1_re> show route advertising-protocol bgp 192.168.2.2 detail 

inet.0: 70 destinations, 70 routes (70 active, 0 holddown, 0 hidden)
* 172.16.1.0/24 (1 entry, 1 announced)
 BGP group BGP_RR type Internal
     Route Label: 299872
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [65002] 65001 I 
     Entropy label capable
==========================

RR> show bgp summary    
Groups: 1 Peers: 4 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0               
                      50         50          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.1.1             65002      4          2       0       2           7 Establ
  inet.0: 50/50/50/0
==================================================

RR> show route receive-protocol bgp 192.168.1.1 detail 

inet.0: 70 destinations, 70 routes (70 active, 0 holddown, 0 hidden)
* 172.16.1.0/24 (1 entry, 1 announced)
     Accepted
     Route Label: 299872
     Nexthop: 192.168.1.1
     Localpref: 100
     AS path: 65001 I 
     Entropy label capable, next hop field matches route next hop

In the above output, you see that RR places these labeled prefixes in the inet.0 table. When a router receives BGP prefixes from a particular neighbor, it will add the standard unicast prefixes into inet.0.

However, if that router receives a Labeled-Unicast prefix from the same neighbor, by default, it cannot add this prefix into inet.0 as well. This is the reason that you cannot configure both families simultaneously. These prefixes then have to go into inet.3.

Note: You need to configure a next-hop self-policy to make R1 as the next-hop when you re-advertise eBGP-learned prefixes into iBGP. However, when you re-advertise BGP unicast into BGP-LU, the next-hop changes by default without requiring configuration.

Solution:

To be able to use both inet unicast and inet labeled-unicast families, you need to change the standard behavior of BGP-LU to allow a labeled unicast prefix into the inet.3 table. With this, you can keep the standard BGP prefixes and the labeled-unicast prefixes separate.

R1_re# set protocols bgp group BGP_RR family inet unicast 
                                                           
R1_re# set protocols bgp group BGP_RR family inet labeled-unicast rib inet.3  

[edit]
R1_re# commit check 
configuration check succeeds

R1 has an eBGP peer (AS65005) with the inet labeled-unicast family enabled. It is receiving labeled BGP prefixes from this peer. 

The following output shows how R1 is advertising these prefixes to RR.

R1_re> show route advertising-protocol bgp 192.168.2.2 

inet.0: 70 destinations, 70 routes (70 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.1.0/24           Self                         100        65001 I
* 172.16.2.0/24           Self                         100        65001 I
* 172.16.3.0/24           Self                         100        65001 I
* 172.16.4.0/24           Self                         100        65001 I
* 172.16.5.0/24           Self                         100        65001 I

inet.3: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.0.0.0/24             Self                         100         65005 I
* 10.0.1.0/24             Self                         100         65005 I
* 10.0.2.0/24             Self                         100         65005 I
* 10.0.3.0/24             Self                         100         65005 I
* 10.0.4.0/24             Self                         100         65005 I

As shown above, R1 is adding the standard BGP prefixes into inet.0 and labeled BGP prefixes into inet.3.

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search