Best practice for ptp/loopback numbering for "small" enterprise multihome setup

Fri Mar 26 20:27:06 UTC 2021

On Fri, 26 Mar 2021 at 20:21, William Herrin <bill at herrin.us> wrote:
>
> On Fri, Mar 26, 2021 at 12:14 PM Blake Hudson <blake at 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