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

[Marc Binderberger <marc () sniff de>]

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 
job!

Management in VPN networks: plan for address collisions. Anything else 
but (your own) public addresses can be used by the customers. 
198.18.0.0/15 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 () completel fr 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 198.18.0.0/15 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 198.18.0.0/15 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 () sniff de>    Powered by *BSD ;-)