Support Support Downloads Knowledge Base Case Manager My Juniper 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

[MX/PTX] 'RPD_MPLS_INTF_MAX_LABELS_ERROR' is seen in 6PE scenario when MPLS Link-Protection or Fast Reroute is used

0

0

Article ID: KB35743 KB Last Updated: 30 Apr 2020Version: 1.0
Summary:

When tunneling IPv6 traffic over MPLS IPv6 network (6PE), the following error is seen for bypass LSP:

RPD_MPLS_INTF_MAX_LABELS_ERROR: Maximum labels exceeded - failed to stack additional label to nexthop on interface lt-0/0/0.13 nhid: 0 fnh: 0x61aa348 lspname: Bypass->12.0.0.2 label: Push 2, Push 300064, Push 299952(top)

By default, any MPLS interface has a maximum-labels limit of 3 on MX and PTX platforms. In a 6PE scenario, sometimes this number may be higher when link-protection or fast reroute is enabled.

In an ideal situation, here are the label requirements:

  • 2 labels on primary path: Transport label, either RSVP or LDP; IPv6 tunneling label
  • 3 labels on backup/bypass path: Transport label, either RSVP or LDP; IPv6 tunneling label; bypass label

For any IPv6 prefix, the BGP Protocol Next Hop (PNH) should be IPv4 compatible IPv6 address in the format of ::ffff:x.x.x.x in inet6.3, and a direct labeled path is required to reach its PNH.

In a race condition or due to other facts, IPv6 prefix PNH was resolved via default route ::/0 in inet6.0 which already required 3 labels to be pushed on bypass path.

Symptoms:

In the example below, IPv6 prefix ::8.8.8.8/128 is received from remote PE router 6.6.6.6 with PNH of ::ffff:6.6.6.6. However, route ::ffff:6.6.6.6 is missing from inet6.3. It is resolved from inet6.0. To reach the PNH, we need 2 labels on primary path and 3 labels on bypass path. An additional label needed for the actual IPv6 destination, thus label limits has exceeded the default max of 3. As a result, no bypass path is created for destination ::8.8.8.8/128.

lab> show route receive-protocol bgp 6.6.6.6 
 
inet6.0: 14 destinations, 25 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* ::8.8.8.8/128           ::ffff:6.6.6.6               100        65001 I
 
lab> show route ::ffff:6.6.6.6 
 
inet6.0: 14 destinations, 25 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
::/0               *[BGP/170] 01:21:18, localpref 100, from 5.5.5.5
                      AS path: 65002 I, validation-state: unverified
                    > to 12.0.0.2 via lt-0/0/0.12, label-switched-path r1-r5
                      to 13.0.0.2 via lt-0/0/0.13, label-switched-path Bypass->12.0.0.2
 
lab> show route forwarding-table destination ::/0 
 
Routing table: default.inet6
Internet6:
Enabled protocols: Bridging, Dual VLAN, 
Destination        Type RtRef Next hop           Type Index    NhRef Netif
default            user     0                    indr  1048622     3
                                                 ulst  1048621     2
                                                Push 2, Push 300064(top)     1351     3 lt-0/0/0.12
                                                Push 2, Push 300064, Push 299952(top)     1352     2 lt-0/0/0.13 <-- On bypass path it needs 3 labels to get PNH 

lab> show route forwarding-table destination ::8.8.8.8/128
::8.8.8.8/128      *[BGP/170] 01:40:05, localpref 100, from 6.6.6.6
                      AS path: 65001 I, validation-state: unverified
                    > to 12.0.0.2 via lt-0/0/0.12, label-switched-path r1-r5 <-- No bypass created on lt-0/0/0.13 as log indicates 
Solution:
  1. If this error appears sporadically during convergence, then it can be ignored. This is most likely due to a racing condition in updating protocol Next Hop.

  2. Create full mesh Label Switched Path across the MPLS core network to all remote PE routers.

  3. In some designs, there is no protocol Next Hop route in inet6.3 table, either through default route ::/ or sometimes LDP over RSVP tunneling. An additional label would be required. We need to increase the maximum-labels on MPLS interfaces.

Related Links

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