Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Daniel Golding
  • Date: Fri Jun 06 13:53:32 2003

Consider the situation where you have a peer or customer who needs to do
ebgp multihop peering from loopback to loopback. This happens
infrequently, but it does happen. You need public IP address space to
(reasonably) make this work. I know you are assuming this won't happen,
but the day you need to provision two OC-12s to the same provider or peer,
and want to load balance them effectively...

Thanks,
Dan

On Fri, 6 Jun 2003 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,
>
>
>
>





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.