Hi,
I have recently encountered some operational differences at my new organization that are not what I have been exposed to before, where the loopback of the core network devices is being set from RFC1918 while on the global routing table. I’m sure this is not a major issue but I have mostly seen that ISPs use global IPs for loopbacks on devices that would and hold global routing.
My question is, what is the most used or recommended way to do this, if I continue to use RFC1918 I will save some very much desired public address space, but would this come back to bite me in the future?
* GutierrezJ@westmancom.com (Javier Gutierrez) [Thu 05 Oct 2023, 19:25 CEST]:
I have recently encountered some operational differences at my new organization that are not what I have been exposed to before, where the loopback of the core network devices is being set from RFC1918 while on the global routing table. I'm sure this is not a major issue but I have mostly seen that ISPs use global IPs for loopbacks on devices that would and hold global routing.
My question is, what is the most used or recommended way to do this, if I continue to use RFC1918 I will save some very much desired public address space, but would this come back to bite me in the future?
The recommendation is to make Router-IDs globally unique. They're used in collision detection. What if you and a peer pick the same non globally unique address? Any session will never come up.
You need globally unique IP addresses on routers anyway, to send ICMP error packets from.
-- Niels.
1 Like
I carry public Internet routing in a vrf, and my loopback and internal IGP interfaces are in the master/default vrf
Aaron
I have recently encountered some operational differences at my new
organization that are not what I have been exposed to before, where
the loopback of the core network devices is being set from RFC1918
while on the global routing table. I'm sure this is not a major issue
but I have mostly seen that ISPs use global IPs for loopbacks on
devices that would and hold global routing.My question is, what is the most used or recommended way to do this,
if I continue to use RFC1918 I will save some very much desired public
address space, but would this come back to bite me in the future?
loopback addressing does not have to be used for router ids. so
decouple that consideraton. make up router ids; 1, 42, 3, 4, ...
whatever. they just need to be unique within the AS.
< corner case >
you may want to have your loopbacks in real global space for routers
which are on an IX. i have been having fun where an IX router is
sourcing packets from the IX interface, and responses can not come
back because the IX space is not announced globally. so one wants
to tell the protocol originating those packets (ntp, dns, whatever)
to source from the loopback. and, for replies to get back to that
loopback, it needs to be in real global space.
randy
Hi Javier,
It depends.
If the loopback is used as the address source for unnumbered
interfaces and any of the router's interfaces have differing MTUs then
you have a red-alarm fire: you've broken path MTU discovery which
breaks TCP. The problem is that the router will originate ICMP
destination unreachable, fragmentation needed messages from that
address. Those packets will then be filtered entering other networks.
Without those messages, the client TCP stack doesn't know to reduce
its packet size. It fails with the symptom that the initial connection
succeeds but then the first large data stream immediately times out
and the connection aborts after a couple minutes.
Even if you have the same MTU on all interfaces, you've still broken
traceroute since the TTL exceeded messages don't get through.
On the other hand, if the loopback is only used to anchor BGP, you
select the BGP router ID from a different address and all your
network-facing interfaces have global IP addresses then everything
should work fine. As you change the configuration over time you'll
have to be mindful that you're riding a knife edge, but nothing will
actually break.
Regards,
Bill Herrin
If the BGP Identifiers of the peers involved in the connection
collision are identical, then the connection initiated by the BGP
speaker with the larger AS number is preserved
Yes, Router-IDs should be unique within a domain, but that doesn’t mean that 1: they need to the the same as the loopback address and 2: if they are not talking to (external) peers, they don’t even have to be globally unique.
If I choose to number “core” devices from 192.168.0.0/24, and ensure that I don’t give multiple devices the same (e.g 192.168.0.42) address, everything works just fine. Note that you have the same problem with non-RFC1918 space — giving multiple devices the same “public” address ends equally poorly.
At one point, it was viewed by some as a feature to not use globally reachable addresses for loopbacks - the thought being that if you cannot target packets towards e.g. SSH / Telnet / whatever, you cannot attack / DoS the box as easily.
However, just because you can use RFC1918 space for loopbacks (and in many cases Router-IDs), it doesn’t mean that you should. Eventually you’ll decide to convert some purely iBGP speaker into an eBGP device, and will discover that both you and your peer decided to do this, and both chose 10.117.236.17 for the loopback and Router-ID….
Weeeeeell… “Need” might be a bit strong; it seems to have decreased over time, but it used to be fairly common to see 1918 space show up in traceroute. I suspect that a fair number of ICMPs are still being sourced from 1918 space, but BCP38 and similar filters are dropping them, leading to ‘* * *’. Perhaps “Assuming you don’t want to be a jackass, you need …”?
w