Best Practices for Loopback addressing (Core routers & VPN CPE)

Marc Binderberger marc at
Sun Jun 8 12:27:47 UTC 2003

Another argument for public loopback/link addresses: merging networks. 
Fairly bad when you plan to merge two networks and loopback addresses 
are not unique anymore ;-)

Regarding RIRs we haven't had real problems using public address space. 
As mentioned by Christopher: talk to them is the solution. Of course 
they will ask you if you can't use private address space - that's their 

Management in VPN networks: plan for address collisions. Anything else 
but (your own) public addresses can be used by the customers. doesn't help you for all times ("oh, we use that for our 
extranet as all partners had 10.x.x.x in use like us"). Maybe using a 
separate management VRF on the CPE and DLCI/PVC/VLAN on the CPE-PE link 
is an option. Or use management address ranges in all 3 RFC1918 
networks to lower the probability of collisions - often customers use 
only 1 or 2 address ranges. I've also seen NAT on the provider end of 
the management DLCI/PVC together with management address ranges per 
customer network.

Regards, Marc

On Friday, June 6, 2003, at 06:05  PM, m.rapoport at wrote:

> Hello,
> I was wondering what are the choices made by Service Providers on the
> loopback addressing.
> The context is an IP/MPLS Backbone providing both Internet and BGP-VPN
> services.
>  I have 2 different cases to address :
> 1)  Loopbacks on the backbone routers :
> I have the feeling that general practice is to use public IP adresses 
> for
> Core routers.
> However, considering that these loopbacks are only used for routing
> protocols (OSPF,BGP, LDP)
> and for network management (SNMP, telnet, ...) and that  these 
> addresses
> don't need to visible from public Internet
> (not seen in traceroute, not seen on Internet BGP announces ...) I am
> considering to
> use private  RFC1918 for a new Backbone deployment.
> N.B. : Assumption is that e-BGP sessions with Internet peers are done 
> on
> public interface IP, not on loopback IP.
> Is there some specific case I am missing where public loopback IP is
> required, and therefore
> private adressing would break something (maybe some Carrier-to-Carrier
> scenario ?) .
> I also plan to use RFC1918 addresses for Internet CPE routers 
> loopbacks.
> 2) Loopback on CPE routers of the MPLS VPN customers.
> For this case, the issue is to assign the adresses in a global range 
> for
> all the CPE of
> all the VPN customers.
> In fact, all these loopback will need to be part of the Network 
> Management
> VPN for supervision needs.
> Using RFC 1918 addresses might create trouble as there is a very high
> chance that the VPN customers
> are already using 1918 addresses, this might generate addresses 
> conflicts.
> Addresses unicity among all the customers is required due to the  
> Network
> Management VPN common
> to all the customers.
> Using public address guarantee unicity, but will create issues with 
> public
> registries, considering that
>  these addresses are used for internal needs.
> I am considering to use the defined in RFC 2544 and 
> listed in
> RFC 3330 as reserved for
> lab testing.
> I suppose that no VPN customer uses this prefix for its internal IP
> addressing, and as these addresses don't
> need to be announced on Internet.
> Do you suggest to use an other prefix than for this 
> purpose ?
> If you consider your adressing policy as  touchy topic in terms of
> security, don't hesitate to reply in private ...
> Regards,
Marc Binderberger    <marc at>    Powered by *BSD ;-)

More information about the NANOG mailing list