unnumbered interface bahaviour

[daniel ng]

in IOS XE, when you configure an unnumbered interface to borrow address from another interface other than loopback, it will not show up in RIB thus is not able to return the traffic. a static route needs to be configured to point to the unnumbered interface as egress.

however, in IOS XR, no static route is needed despite the unnumbered interface does not show up in RIB and FIB.

in Junos, it also does not show up in RIB but does in FIB.

what is the difference between them that causes such behaviour?

[Cristian Matei]

Hi,

@daniel ng The answer is pretty simple. At the end of the day, different NOS'es, different architecture, thus different outcome sometimes for same feature to work.

  Not sure I understood what you say by "in IOS XE, when you configure an unnumbered interface to borrow address from another interface other than loopback, it will not show up in RIB thus is not able to return the traffic. a static route needs to be configured to point to the unnumbered interface as egress." 

   Can you give a clear example of/ topology for this? For example, if you use Tunnel interfaces with unnumbered, there is no such requirement. If you use Ethernet interface with unnumbered pointing to another Ethernet interface, what would be the use case for such scenario?

Thanks,

Cristian.

[daniel ng]

sorry wrong info. even borrowing from loopback requires static route.

you are right that tunnel interface does not need static route as used in RSVP-TE and such.

i just came across a use case where i had to use the same subnet as another ethernet interface that's in use but i cant modify that and cant control other parts of the network. so i use unnumbered on another ethernet interface with longer prefix in the static route so it can reach the segment directly connecting it.

[Cristian Matei · Accepted solution]

Hi,

 @daniel ng Not only RSVP-TE or SR tunnels, but also GRE, IPinIP, IPsec; at the end of the day all of these are a form of overlay and most importantly a P2P type of connection, it makes sense it just works.

     Using unnumbered pointing on Loopback was a likewise a valid design, when the interface was of type P2P, like PPP, PPPoE, IPoE, etc.

     What you're trying to perform was not designed to be used with unnumbered (if you perform an ARP debug, you'll see the router complaining that the ARP Request is dropped due to wrong cable, meaning the router's interface is not attached to that subnet; and the WA is the static route being configured). Instead of using the static route, a feature designed to fix such cases is using the poll option when defining the unnumbered configuration; e.g instead of configuring ip unnumbered Gi1, use ip unnumbered Gi1 poll. More on this feature:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_ipv4/configuration/xe-16/ipv4-xe-16-book/ip_unnumbered_ethernet_polling_support.pdf

     In your case, why don't you use BVI/BDI, it should perfectly, it's a valid and supported design / feature, and you avoid any possible complications that can show up in future, based on whatever other features you need to add (for example dynamic routing).

Thanks,

Cristian.

[daniel ng]

bridge interface was also a consideration until i learnt i could not modify the lender interface since there was live traffic.

this is how i stumbled upon this unorthodox method.

for dynamic routing, i know IGP can use loopback for peering by unnumbered interfaces, although i dont really find it too meaningful.

ps: found that in IOS XE this method only works on IPv4 unnumbered interface. IPv6 does not actually borrow the GUA and generates its own LLA.

IOS XR does not even allow unnumbered interface on IPv6.

Junos is same as IOS XE.

[daniel ng]

tested a while with IPv6 unnumbered and found that there is no entry in RIB and FIB even if i configured static route.

the 'show ipv6 interface' command says 'Interface is unnumbered. Using address of GigabitEthernet1' but also 'No global unicast address is configured'. not sure if it really borrows anything.

IPv4 unnumbered can show the borrowed address normally.

has anyone ever managed to make IPv6 unnumbered work?

[Harold Ritter]

Hi @daniel ng ,

This "ipv6 unnumbered" command is merely a hint to the source address selection (RFC6724). When locally originated ipv6 packets are forwarded through the interface where the "ipv6 unnumbered <interface x>" command is configured, the <interface x> ipv6 address will be used as the source ipv6 address.  

There is no need to install any entry in the RIB and FIB to achieve this behavior.

Regards,

[daniel ng]

i thought source address selection was only relevant when there were multiple addresses to choose from. in my test, there was only the one address in the unnumbered interface.

so in other words, it is normal behaviour that no address is borrowed? if so, what if any is the use of 'ipv6 unnumbered' besides simply enabling IPv6 on the interface?

ps: retested on Junos version 21.4 or later where it can borrow GUA while generates its own LLA.

[Cristian Matei]

Hi,

@daniel ng I don't see any connection between IPv6 unnumbered and RFC6724, unless @Harold Ritter can clarify that. Unnumbered functionality is outlined in RFC5309, and while there is not much clarity on what to expected between IPv4 and IPv6 unnumbered scenarios, by understanding IPv4 vs. IPv6 architecture, we should / could understand what to expect in both cases, and of curse, this expectation can be overridden by each vendor as considered necessary, either because it was decided to bring some new feature by making use of unnumbered functionality, either because it was decided to address some NOS internal architecture limitation / challenge by making use of unnumbered functionality. 

   In IPv4, there is no link-local addressing and this is the point we need to start from. To enable control-plane and data-plane functions on an interface, you need an IP address, and the only way to do it in IPv4 is to assign an IPv4 address (which in the end is a routable address) on the interface or use unnumbered function. In IPv6, link-local addressing was designed to no longer need routable addresses activate on any given interface, in order to activate both the control-plane (for both host and network devices) and data-plane (for network devices) on an IPv6 interface, as ideally, the network needs to provide transit from point A to point B, without the need to have routable addresses provision on each network interconnect which results in enough challenges regarding  scale, convergence and optimization. Routable IPv6 addresses are required for multi-hop control-plane (e.g BGP, tunnelling protocols, where you can and should use Loopbacks) and for specific services provided to end hosts (where you'll assign a routable prefix to the network segment facing the hosts).

   Expectation, which gain can be override by any vendor as previously explained, is that using IPv6 unnumbered just means you enable IPv6 on the link, which means the link will generate an IPv6 link-local address using EUI-64 schema. I, for now at least, fail to see in which scenario you would need to use IPv6 unnumbered, so that you could borrow a routable IPv6 space from another interface.

Thanks,

Cristian.

[Harold Ritter]

Hi @Cristian Matei ,

RFC5309 defines unnumbered in the context of link state routing protocols. I am not sure how it relates to the current question, but I might have missed something from the OP.

As for the relevancy of RFC6724, the "ipv6 unnumbered" command has a direct effect on how SAS behaves. Please refer to the response I sent to @daniel ng . 

[Cristian Matei]

Hi,

@Harold Ritter In this case, how can you explain the following behaviour:

interface GigabitEthernet2
 ipv6 address 2001::1/64
!
interface GigabitEthernet4
 ipv6 unnumbered GigabitEthernet2
!
Router#ping 2001::1 source gigabitEthernet 2          
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001::1, timeout is 2 seconds:
Packet sent with a source address of 2001::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
!
Router#ping 2001::1 source gigabitEthernet 4
% No valid source address for destination

Thanks,

Cristian. 

[Harold Ritter]

Hi @Cristian Matei ,

Router#ping 2001::1 source gigabitEthernet 4
% No valid source address for destination

 The reason for that error is as I mentioned, you are trying to ping a GUA and the interface specified in the "ipv6 unnumbered" command does not have a GUA (or ULA for that matter). The only available ipv6 address on Gig4 is a LLA, which is rejected by the SAS, as you are pinging a GUA.

[Cristian Matei]

Hi,

@Harold Ritter For me it's expected behaviour. 

However, it seems to contradict your previous statement, that's why I made the first comment to begin with. If I misunderstood, can you explain:

This "ipv6 unnumbered" command is merely a hint to the source address selection (RFC6724). When locally originated ipv6 packets are forwarded through the interface where the "ipv6 unnumbered <interface x>" command is configured, the <interface x> ipv6 address will be used as the source ipv6 address. 

Thanks,

Cristian.

[Harold Ritter]

Hi @Cristian Matei ,

> the <interface x> ipv6 address will be used as the source ipv6 address. 

The SAS still needs to check the validity of the source address. In this case the LLA source address would be considered invalid as the destination address is a GUA.

[Cristian Matei]

Hi,

@Harold Ritter I get all that. Let me put it simpler, as this was my wonder from beginning. I completely fail to see what is the correlation between using IPv6 unnumbered and RFC6724. If you could make a specific reference to a section of the RFC and provide an example on that, would be great.

Thanks,

Cristian.