On Fri, 26 Mar 2021 at 20:21, William Herrin <bill@herrin.us> wrote:
On Fri, Mar 26, 2021 at 12:14 PM Blake Hudson <blake@ispn.net> wrote:
And here I almost went as far as to suggest unnumbered IPs.... you're plan is... well... diabolical in comparison.
Hi Blake,
I aim to please. I really wish the router vendors supported a statically configured "ICMP error from" address overriding source address selection for ICMP error messages so that you could just put RFC1918 on the router to router links instead of wasting global IP addresses on them.
Yes, in such a case, it would be extremely useful. However for bigger transit networks, it is not nice if you only see loopbacks in traceroutes, as opposed to interfaces. In this particular case: The only P2P interface that needs addressing is the link between the two routers. For an enterprise stub-AS, I would certainly compromise and use RFC1918 here as well (and use the entire /24 on the user facing interface). Other than traceroutes, this does not realistically cause an issue, *IN THIS PARTICULAR* scenario: you will not have different MTU's requiring proper PMTUD handling in this direction and some broken traceroutes won't be a problem for this business case. We can't stop huge eyeball networks from using RFC1918 addressing on P2P links, I guess we can live with a stub-AS doing it. Another alternative is to use the actual user interface to get your iBGP across, which is publicly addressed. Of course think about different failure scenarios (partitioning), but it can work too. Maybe use a different RFC1918 addressed P2P link with higher IGP costs, so the 1918 dedicated link is used for in case of LAN partitioning only, and usually you see public IP's in the traceroute. I would avoid single control plane redundancy with proprietary solutions like VSS and the likes. At some point they will tell you: for this OS upgrade, you need to take BOTH devices out, because you can't upgrade the cluster from major release X to Y, without completely bringing it down. Lukas