Using RFC1918 on Global table as Loopbacks
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? Kind regards, Javier Gutierrez,
* 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.
On Thu, 5 Oct 2023 at 20:45, Niels Bakker <niels=nanog@bakker.net> wrote:
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.
https://datatracker.ietf.org/doc/html/rfc6286 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 -- ++ytti
On Thu, Oct 05, 2023 at 1:42 PM, Niels Bakker <niels=nanog@bakker.net> wrote:
* 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.
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….
You need globally unique IP addresses on routers anyway, to send ICMP error packets from.
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
-- Niels.
I carry public Internet routing in a vrf, and my loopback and internal IGP interfaces are in the master/default vrf Aaron
On Oct 5, 2023, at 12:24 PM, Javier Gutierrez <GutierrezJ@westmancom.com> wrote:
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?
Kind regards,
Javier Gutierrez,
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
On Thu, Oct 5, 2023 at 9:42 AM Javier Gutierrez <GutierrezJ@westmancom.com> wrote:
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.
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 -- William Herrin bill@herrin.us https://bill.herrin.us/
participants (7)
-
Aaron1 -
Javier Gutierrez -
Niels Bakker -
Randy Bush -
Saku Ytti -
Warren Kumari -
William Herrin