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/ACX] Limitations of unnumbered interfaces

0

0

Article ID: KB35112 KB Last Updated: 19 Dec 2019Version: 1.0
Summary:

This document describes a product limitation regarding unnumbered interfaces between two routers (ACX or MX). 
 

Symptoms:

Junos does not support ECMP across 2 unnumbered links between the same devices.

Consider the topology below:

+---------+xe-1/0/0     +---------+
|         +-------------+         |
|    A    |             |    B    |
| 1.1.1.1 |xe-1/1/0     | 2.2.2.2 |
|         +-------------+         |
+---------+             +---------+

On each router, both interfaces are unnumbered and inherit their addresses from the same loopback address.

user@test# run show interfaces terse | match 1.1.1.1
xe-1/0/0.0              up    up   inet     1.1.1.1   --> 0/0
xe-1/1/0.0              up    up   inet     1.1.1.1   --> 0/0
lo0.0                   up    up   inet     1.1.1.1   --> 0/0

IGP neighborships come up without issues.

[edit]
user@test# run show ospf neighbor
Address      Interface       State     ID          Pri  Dead
2.2.2.2      xe-1/0/0.0      Full      2.2.2.2     128    34
2.2.2.2      xe-1/1/0.0      Full      2.2.2.2     128    37

A receives B’s loopback prefix 2.2.2.2 via OSPF across both unnumbered links.

[edit]
user@test# run show route 2.2.2.2

inet.0: 7 destinations, 10 routes (7 active, 1 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both

2.2.2.2/32         @[OSPF/10] 00:01:26, metric 1
                    > to 2.2.2.2 via xe-1/0/0.0
                      to 2.2.2.2 via xe-1/1/0.0
                   #[Direct/0] 00:01:26, metric 1
                    > to 2.2.2.2 via xe-1/0/0.0
                    [Direct/0] 00:01:26, metric 1
                    > to 2.2.2.2 via xe-1/1/0.0

A is configured for ECMP:

set routing-options forwarding-table export lb
set policy-options policy-statement lb then load-balance per-packet

In spite of ECMP, A does not install both next hops for its route to 2.2.2.2

[edit]
user@test# run show route forwarding-table destination 2.2.2.2 table default
Routing table: default.inet
Internet:
Enabled protocols: Bridging,
Destination        Type RtRef Next hop           Type Index    NhRef Netif
2.2.2.2/32         user     0 d4:4:ff:5e:22:a5   ucst      594     2 xe-1/0/0.0
2.2.2.2/32         dest     0 d4:4:ff:5e:22:a5   ucst      594     2 xe-1/0/0.0

This is expected behavior and arises because ARP cannot resolve two next hops for the same IP address (in this case, 2.2.2.2).

[edit]
user@test# run show arp | match 2.2.2.2
d4:04:ff:5e:22:a5 2.2.2.2     2.2.2.2     xe-1/0/0.0      none

This limitation on ARP also prevents A from installing BGP routes advertised by B into its kernel.

[edit]
user@test# run show route protocol bgp table inet extensive

inet.0: 8 destinations, 11 routes (8 active, 1 holddown, 0 hidden)
100.100.100.0/24 (1 entry, 1 announced)
TSI:
KRT queued (pending) add 
  100.100.100.0/24 -> {indirect(-)}
        *BGP    Preference: 170/-101
                Next hop type: Indirect, Next hop index: 0
                Address: 0x48def8c
                Next-hop reference count: 4
                Source: 2.2.2.2
                Next hop type: Router, Next hop index: 0
                Next hop: 2.2.2.2 via xe-1/0/0.0, selected
                Session Id: 0x0
                Next hop: 2.2.2.2 via xe-1/1/0.0
                Session Id: 0x0
                Protocol next hop: 2.2.2.2
                Indirect next hop: 0x980c200 - INH Session ID: 0x0
                State: <Active Int Ext>
                Local AS:   100 Peer AS:   100
                Age: 28   Metric2: 1
                Validation State: unverified
                Task: BGP_100.2.2.2.2+54045
                Announcement bits (2): 0-KRT 6-Resolve tree 2
                AS path: I
                Accepted
                Localpref: 100
                Router ID: 2.2.2.2
                Indirect next hops: 1
                        Protocol next hop: 2.2.2.2 Metric: 1
                        Indirect next hop: 0x980c200 - INH Session ID: 0x0
                        Indirect path forwarding next hops: 2
                                Next hop type: Router
                                Next hop: 2.2.2.2 via xe-1/0/0.0
                                Session Id: 0x0
                                Next hop: 2.2.2.2 via xe-1/1/0.0
                                Session Id: 0x0
                           2.2.2.2/32 Originating RIB: inet.0
                             Metric: 1                Node path count: 1
                             Forwarding nexthops: 2
                                    Nexthop: 2.2.2.2 via xe-1/0/0.0
                                    Session Id: 0
                                    Nexthop: 2.2.2.2 via xe-1/1/0.0
                                    Session Id: 0
Solution:

Workaround:

  1. Configure both unnumbered links to be in an unnumbered LAG bundle.

    chassis {
        aggregated-devices {
            ethernet {
                device-count 1;
            }
        }
    }
    interfaces {
        xe-1/0/0 {
            gigether-options {
                802.3ad ae0;
            }
        }
        xe-1/2/0 {
            gigether-options {
                802.3ad ae0;
            }
        }
        ae0 {
            unit 0 {
                family inet {
                    unnumbered-address lo0.0;
                }
            }
        }
        lo0 {
            unit 0 {
                family inet {
                    address 1.1.1.1/32;
                }
            }
        }
    }
  2. Convert both links to numbered

    interfaces {
        xe-1/0/0 {
            unit 0 {
                family inet {
                    address 10.10.10.1/30;
                }
            }
        }
        xe-1/1/0 {
            unit 0 {
                family inet {
                    address 10.10.10.2/30;
                }
            }
        }
    }

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