[j-nsp] Independent /32s for Interfaces - anybody doing that?

[Vincent Bernat]

 ❦ 31 mai 2016 13:12 CEST, v <vekt0r7 at gmx.net> :

> I just read about using independent /32 addresses for interfaces and I
> would like to know whether anybody uses that. Found the following
> information about such a configuration:
> -This means that there is no relation between the addresses on the two ends of an interface
> -This relies on the IGP to provide this relationship
> -This significantly reduces the burden of address management and synchronization
> -Also, reconfiguration of topology is much easier
>
> Are there more pros and cons than that?
> Does anyone have experience with such a configuration?

Hi!

I believe that you are talking about unnumbered interfaces: you put a
/32 on a loopback and you tell other interfaces to use the loopback
address. For example:

interfaces {
    lo0 {
        unit 1 {
            family inet {
                address 203.0.113.3/32;
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family inet {
                unnumbered-address lo0.1;
            }
        }
    }
    ge-0/0/2 {
        unit 0 {
            family inet {
                unnumbered-address lo0.1;
            }
        }
    }
}

I find this scheme very convienent:

 1. You can use only one public IP address for the whole equipment.

 2. You have less configuration to do and this is less error-prone. An
    IGP like OSPF would make each router discover the addresses of all
    other routers automatically.

Unfortunately, the support vary widely accross vendors. I believe the
support is pretty good with Cisco. With Juniper, it really depends on
the equipment. The MX has pretty good support, but has some limitations
(for example, static BFD + unnumbered doesn't work). The QFX doesn't
support unnumbered interfaces in various places (like for example, on an
IRB interface). From what I have been told, Juniper has no plan to fix
that. Cumulus supports them too (but I can't testify on the completeness
of the support). Other vendors may have no support at all for this, so
you get into some kind of vendor-lockin if you rely on this.
-- 
Program defensively.
            - The Elements of Programming Style (Kernighan & Plauger)