Unnumbered interfaces are point-to-point interfaces that are not explicitly configured with a dedicated IP address and subnet; instead, they borrow (or link to) an IP address from another interface on the system (the system IP address, another loopback interface, or any other numbered interface) and use it as the source IP address for packets originating from the interface. For more information about support for unnumbered interfaces, see the 7705 SAR Router Configuration Guide, Unnumbered Interfaces.
Unnumbered IP interfaces can be used via RSVP-TE for signaling traffic engineering (TE) LSPs.
Supporting RSVP-TE over unnumbered interfaces requires the ability to:
carry TE information over unnumbered links in IS-IS-TE or OSPF-TE extensions
specify unnumbered interfaces in RSVP-TE signaling
An unnumbered IP interface is identified uniquely on a router in the network by the tuple (router ID, ifindex). An LSR at each end of the link assigns a system-wide unique interface index to the unnumbered interface. IS-IS, OSPF, MPLS (RSVP-TE, LDP), and OAM use this tuple to advertise the link information, signal LSPs over the interface, or send and respond to an MPLS echo request message over an unnumbered interface.
The borrowed IP address for an unnumbered interface is configured using the following CLI command, with the default value set to the system interface address: config>router>interface>unnumbered {ip-int-name | ip-address}.
To support unnumbered TE links in IS-IS, a new sub-TLV of the extended IS reachability TLV is added, which encodes the link local identifiers and link remote identifiers as defined in RFC 5307, IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS).
To support unnumbered TE links in OSPF, a new sub-TLV of the Link TLV is added, which encodes the link local identifiers and link remote identifiers as defined in RFC 4203, \OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS).
To support unnumbered TE links in RSVP-TE, a new sub-object of the Explicit Route Object (ERO) is added to specify unnumbered links and a new sub-object of the Route Record Object (RRO) is added to record that the LSP traversed an unnumbered link, as per RFC 3477, Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE). As well, a new IF_ID RSVP_HOP object with a C-Type of 3 is added as per section 8.1.1 of RFC 3473, Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions. The IPv4 Next/Previous Hop Address field in the object is set to the borrowed IP interface address.
The unnumbered IP interface address is advertised by IS-IS-TE or OSPF-TE, and CSPF can include it in the computation of a path for a point-to-point LSP. However, this feature does not support defining an unnumbered interface as a hop in the path definition of an LSP.
A router creates an RSVP neighbor over an unnumbered interface using the tuple (router ID, ifindex). The router ID of the router that advertised an unnumbered interface index is obtained from the TE database. Therefore, if traffic engineering is disabled in IS-IS or OSPF, a non-CSPF LSP that has its next hop over an unnumbered interface will not come up at the ingress LER because the router ID of the neighbor that has the next hop of the PATH message cannot be looked up. The LSP path will remain operationally down with the error ‟noRouteToDestination”. If a PATH message is received at the LSR for which traffic engineering was disabled and the next hop for the LSP is over an unnumbered interface, a PathErr message is sent back to the ingress LER with the error code of 24 ‟Routing Problem” and an error value of 5 ‟No route available toward destination”.
All MPLS (RSVP-TE and LDP) features supported for numbered IP interfaces are supported for unnumbered interfaces, with the following exceptions:
configuration of a router ID with a value other than system interface
signaling of an LSP with an ERO based on a loose or strict hop using an unnumbered TE link in the path hop definition
signaling of a one-to-one detour LSP over an unnumbered interface
RSVP Hello messages and all Hello-related capabilities, such as Graceful-Restart Helper
RSVP refresh reduction on an unnumbered interface
The unnumbered interface feature also extends the support of LSP ping and LSP traceroute to point-to-point LSPs that have unnumbered TE links in their path.