This article describes a product limitation related to using unnumbered interfaces between two devices (ACX, MX or QFX). If you want to use unnumbered interfaces between these two devices, you will have to configure both unnumbered links to be in an unnumbered link aggregation group (LAG) bundle as demonstrated in the article.
Junos OS does not support equal-cost multipath (ECMP) across two unnumbered links between the same devices.
Consider the following topology:
+---------+xe-1/0/0 +---------+ | +------------+ | | A | | B | |172.16.0.1|xe-1/1/0 |172.16.0.2| | +------------+ | +----------+ +---------+
On each router, both interfaces are unnumbered and inherit their addresses from the same loopback address.
user@A# run show interfaces terse | match 172.16.0.1 xe-1/0/0.0 up up inet 172.16.0.1 --> 0/0 xe-1/1/0.0 up up inet 172.16.0.1 --> 0/0 lo0.0 up up inet 172.16.0.1 --> 0/0
IGP neighborships come up without issues.
[edit] user@A# run show ospf neighbor Address Interface State ID Pri Dead 172.16.0.2 xe-1/0/0.0 Full 172.16.0.2 128 34 172.16.0.2 xe-1/1/0.0 Full 172.16.0.2 128 37
A receives B’s loopback prefix 172.16.0.2 via OSPF across both unnumbered links.
[edit] user@A# run show route 172.16.0.2 inet.0: 7 destinations, 10 routes (7 active, 1 holddown, 0 hidden) @ = Routing Use Only, # = Forwarding Use Only + = Active Route, - = Last Active, * = Both 172.16.0.2/32 @[OSPF/10] 00:01:26, metric 1 > to 172.16.0.2 via xe-1/0/0.0 to 172.16.0.2 via xe-1/1/0.0 #[Direct/0] 00:01:26, metric 1 > to 172.16.0.2 via xe-1/0/0.0 [Direct/0] 00:01:26, metric 1 > to 172.16.0.2 via xe-1/1/0.0
[edit]
# run show route 172.16.0.2
A is configured for ECMP:
set routing-options forwarding-table export lb set policy-options policy-statement lb then load-balance per-packet
Despite the ECMP configuration, A does not install both next-hops for its route to 172.16.0.2.
[edit] user@A# run show route forwarding-table destination 172.16.0.2 table default Routing table: default.inet Internet: Enabled protocols: Bridging, Destination Type RtRef Next hop Type Index NhRef Netif 172.16.0.2/32 user 0 d4:4:ff:5e:22:a5 ucst 594 2 xe-1/0/0.0 172.16.0.2/32 dest 0 d4:4:ff:5e:22:a5 ucst 594 2 xe-1/0/0.0
# run show route forwarding-table destination 172.16.0.2 table default Routing table: default.inet Internet: Enabled protocols: Bridging, Destination Type RtRef Next hop Type Index NhRef Netif 172.16.0.2/32 user 0 d4:4:ff:5e:22:a5 ucst 594 2 xe-1/0/0.0 172.16.0.2/32 dest 0 d4:4:ff:5e:22:a5 ucst 594 2 xe-1/0/0.0
This is expected behavior and occurs because the Address Resolution Protocol (ARP) protocol cannot resolve two next-hops for the same IP address (in this case, 172.16.0.2).
[edit] user@A# run show arp | match 172.16.0.2 d4:04:ff:5e:22:a5 172.16.0.2 172.16.0.2 xe-1/0/0.0 none
# run show arp | match 172.16.0.2 d4:04:ff:5e:22:a5 172.16.0.2 172.16.0.2 xe-1/0/0.0 none
This limitation on ARP also prevents A from installing the Border Gateway Protocol (BGP) routes advertised by B into its kernel.
[edit] user@A# 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: 172.16.0.2 Next hop type: Router, Next hop index: 0 Next hop: 172.16.0.2 via xe-1/0/0.0, selected Session Id: 0x0 Next hop: 172.16.0.2 via xe-1/1/0.0 Session Id: 0x0 Protocol next hop: 172.16.0.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.172.16.0.2+54045 Announcement bits (2): 0-KRT 6-Resolve tree 2 AS path: I Accepted Localpref: 100 Router ID: 172.16.0.2 Indirect next hops: 1 Protocol next hop: 172.16.0.2 Metric: 1 Indirect next hop: 0x980c200 - INH Session ID: 0x0 Indirect path forwarding next hops: 2 Next hop type: Router Next hop: 172.16.0.2 via xe-1/0/0.0 Session Id: 0x0 Next hop: 172.16.0.2 via xe-1/1/0.0 Session Id: 0x0 172.16.0.2/32 Originating RIB: inet.0 Metric: 1 Node path count: 1 Forwarding nexthops: 2 Nexthop: 172.16.0.2 via xe-1/0/0.0 Session Id: 0 Nexthop: 172.16.0.2 via xe-1/1/0.0 Session Id: 0
# run show route protocol bgp table inet extensive
To work around this limitation, use the following:
Configure both the 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 172.16.0.1/32; } } } }
172.16.0.1
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; } } } }
Another possible solution is to use numbered interfaces.
2024-10-03: Added limitation for QFX platforms. 2022-12-15: Updated non-compliant IP addresses to RFC standards; changed hostnames on command lines
Configuring An Unnumbered Interface