Best Practices for Loopback addressing (Core routers & VPN CPE)
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,
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.
Or, you could use a seperate class C or whatever fits yoru backbone for loopbacks and router interfaces.. Just don't advertise that block. That way you use non-rfc1918 on the backbone, and yet outside people cannot get to it since you dont advertise it to the world... It's just me but i am against using rfc1918 on any part of a backbone. -hc
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,
-- Sincerely, Haesu C. TowardEX Technologies, Inc WWW: http://www.towardex.com E-mail: haesu@towardex.com Cell: (978) 394-2867
On 6/6/03 10:05 AM, "m.rapoport@completel.fr" <m.rapoport@completel.fr> wrote:
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.
If the BGP Identifier, which is used for connection collision resolution and path selection (among others seemingly random things) conflicts you'll have issues. In my experience even mediocre IP addressing frameworks typically don't have issues with RIRs when space is appropriately justified (i.e., there typically aren't issues with loopback and inter-router address space justification). What I'd be more concerned with is loopback IP allocation and it's effect on aggregation, stability, and other network policies (e.g., source-interface type stuff). For example, using a single contiguous block for all loopback IPs significantly simplifies filtering policies. OTOH, you may opt to provide more optimal aggregation and allocate loopback IPs from the same block as p-t-p IPs (per router, POP, region or other) such that less information needs to be carried internally in your IGP (or BGP). RFC 2519 provides some guidelines for inter-domain route aggregation. A slew of other documents and books provide IP address allocation guidelines as well. -danny
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,
On Fri, 6 Jun 2003, Daniel Golding wrote:
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...
Well, as you mentioned, it's fairly infrequent that these situations arise, but it's not unheard of. However, in this case, you can always take an IP address out of the interface pool and create another loopback address specifically for the purpose of load balancing to the peer/customer. I'm actually not advocating using 1918 address space in the backbone, just trying to point out a solution to a problem. :) Guy
In situations like this, I find it helpful to provision an additional loopback interface for each peer that has more than one connection to the same router. This lets us remain in control of our own destiny rather than relying on outside parties to do reconfiguration when circuits need to get moved between routers. I wouldn't agree with the original poster's statement that using address space obtained from one of the public registries for internal purposes will be an issue. ARIN, et al shouldn't have a problem with using address space obtained from them for internal uses (i.e. not announced to the public internet) If you have concerns about how they might react to this, I'd suggest engaging them directly for advice on how to structure your request. In my past experience, I've found it easier to discuss my request with ARIN prior to submitting it, just to be sure they understand what I'm intending to do, and that I'm giving them all of the necessary data. The last thing you want to do is have that dialogue once they're already reviewing your request, it's likely to make the process take far longer than necessary. FWIW, I am loathe to use address space that is not publically routable for anything I can't rip apart and renumber inside of a few hours. There are a many ways to give yourself a headache that are far more enjoyable. :-) Chris Daniel Golding wrote:
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,
participants (6)
-
Christopher B. Zydel -
Daniel Golding -
Danny McPherson -
Guy Tal -
Haesu -
m.rapoport＠completel.fr