nanog mailing list archives
Re: Best practice for ptp/loopback numbering for "small" enterprise multihome setup
From: Lukas Tribus <lukas () ltri eu>
Date: Fri, 26 Mar 2021 21:27:06 +0100
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
Current thread:
- Best practice for ptp/loopback numbering for "small" enterprise multihome setup vom513 (Mar 26)
- Re: Best practice for ptp/loopback numbering for "small" enterprise multihome setup Randy Bush (Mar 26)
- Re: Best practice for ptp/loopback numbering for "small" enterprise multihome setup Tom Beecher (Mar 26)
- Re: Best practice for ptp/loopback numbering for "small" enterprise multihome setup Blake Hudson (Mar 26)
- Re: Best practice for ptp/loopback numbering for "small" enterprise multihome setup William Herrin (Mar 26)
- Re: Best practice for ptp/loopback numbering for "small" enterprise multihome setup Blake Hudson (Mar 26)
- Re: Best practice for ptp/loopback numbering for "small" enterprise multihome setup William Herrin (Mar 26)
- Re: Best practice for ptp/loopback numbering for "small" enterprise multihome setup Lukas Tribus (Mar 26)
- Re: Best practice for ptp/loopback numbering for "small" enterprise multihome setup Blake Hudson (Mar 26)
- Re: Best practice for ptp/loopback numbering for "small" enterprise multihome setup Blake Hudson (Mar 26)
- Re: Best practice for ptp/loopback numbering for "small" enterprise multihome setup Randy Bush (Mar 26)
- Re: Best practice for ptp/loopback numbering for "small" enterprise multihome setup Lukas Tribus (Mar 26)
- Re: Best practice for ptp/loopback numbering for "small" enterprise multihome setup William Herrin (Mar 26)
- Re: Best practice for ptp/loopback numbering for "small" enterprise multihome setup Lukas Tribus (Mar 26)