Best designs to use for providing reachability to remote sites/customers utilizing private IPs?

[CiscoPurpleBelt]

If you connect to multiple sites or are a transport or service provider for multiple sites that are using private IP addresses meaning some may overlap and/or be the same (e.g. 10.10.10.0 for customer A and B) what would be the best options in terms of routing. Let's say your infrastructure is small meaning maybe you don't want to do a mbgp/mpls backbone type infrastructure if you only have a couple devices or something, would perhaps configuring vrf light route leaking be the best way to go? 
Would still just building an mpls infrastructure still be best option if lets say you only have 2 routers meaning I guess they act as PE and LSR (if that is even supported)?

Also, what if you have IPSEC tunnels or something and you infrastructure is using the same subnet the remote end is using or wants to use such as 10.10.10.0 /24 what would be the best options as to my knowledge that would not be supported unless I am mistaken??

[Francesco Molino]

Hi

For ipsec, you can do natting of source subnets to solve the overlapping issues.

Now for the rest, if you want to transport meaning keep contained communications between customer B without being able to communicate with customer A and the invert, the best solution would be to build a mpls cloud (you can have a single router acting as PE and P). It will be simpler to maintain and to scale it in the future. If you have a shared zone, then you need to make sure services in this zone don't have overlapping subnets and so use the carrier reserved subnet 100.64.0.0/10 which is rarely used in a LAN.

If customer A and B needs to talk together, then you'll need to do natting.

You're post is high level and based on this, what I think fits better is what I said previously. But sure there can be other options if we have more details on what you want to do.

Does that make sense?

[CiscoPurpleBelt]

Awesome Francisco yes it does make sense.

So basically, if let's say you have an existing network that provides services as I mentioned, however right now the network is small as I mentioned (idk like 1 router and 1 switch), but you want to be able to scale easily and/or more efficient if needed in the future, I am just trying to decide what the best type of implementations would be - yes I was thinking just to go ahead and do mpls with MBGP instead of let's say VRF light or something. What other good scalable options you mentioned would there be besides these?

Also when you say shared zone, are you talking about let's say systems that must be accessed by these customers (DNS, Apps, etc.) and not between two remote customers who must communicate correct?

[Richard Burts · Accepted solution]

You ask 2 questions and the second one is easier, so let me start with it. If you have ipsec tunnel or something to a peer and that peer has a subnet that is the same as a subnet in your network such as 10.10.10.0/24 then one side or the other must do address translation. I have worked with customers in this type situation and while we normally think of not translating site to site vpn traffic it is certainly a supported feature to translate that traffic. I have done it and it works.

I am less clear about your first question. If you are a service provider or a transport provider I would think that it would be a priority to implement something that scales effectively. And something like vrf lite is probably not such a good choice. If you have a fairly small infrastructure perhaps something like GRE tunnels, or perhaps multi-point GRE might allow you to connect sites and have them communicate private address to private address. But as part of this question you bring up the possibility that customer A and customer B might be using the same private IP subnet. In that case one (or both) will need to do address translation (or you might need to do the translation for them).

[CiscoPurpleBelt]

Awesome Richard!
In regards to using mGRE/GRE, would it be better to use that along with IPSEC instead of just using IPSEC given the capability of supporting different types or traffic communication that mGRE/GRE can handle as opposed to just using IPSEC?

[Richard Burts]

You ask an interesting question about which would be better. And my answer is that it depends on how you define better. It seems to me that there are 3 possibilities to consider:

1) mGRE/GRE without encryption. This would be the most simple to configure and imposes the least processing overhead. It makes the frame slightly larger. It can transport multiple types of traffic (unicast, multicast, dynamic routing, etc). But it provides no security for the traffic passing between sites.

2) IPSEC encrypted traffic between sites (implemented with crypto map and without tunnel interfaces). This is somewhat more complex to configure and imposes some more processing overhead. It makes the frame larger to carry the IPSEC header. It provides encryption to protect unicast traffic between peers but does not support features like multicast or dynamic routing protocols.

3) mGRE/GRE with encryption. Provides the most flexibility for types of traffic. Makes the frame larger because it carries both tunnel info and IPSEC header. With features like VTI tunnels it may be somewhat easier to configure as compared to plain IPSEC.

So what makes it better? Is it ease of configuration? Is it security of the traffic? Is it frame size? Is it flexibility? And especially if you are dealing with customers (rather than just running an Enterprise network) what do your customers really want? My guess would be the flexibility and combination of features found in mGRE/GRE with IPSEC. What do you think?

[Cristian Matei · Accepted solution]

Hi,

    mGRE and GRE gives you the best of all worlds alongside with IPsec, for just 4/8 extra bytes of overhead (if using IPsec transport mode). Since we speak about IOS devices, as you want to run MPLS, your best option would be to implement:

          - FlexVPN DVTI with automatic encapsulation detection (remote side can be GRE over IPsec or VTI based IPsec, underlay and overlay can be any combination of IPv4 and/or IPv6)

          - FlexVPN Multi-SA DVTI gives you compatibility with remote devices running crypto-map based IPsec VPNs

You can also use FVRF and IVRF. You have unlimited options, there is pretty much nothing you cannot do. Here's just one reference on FlexVPN.

Regards,

Cristian Matei.

[Cristian Matei]

Hi,

  "Also when you say shared zone, are you talking about let's say systems that must be accessed by these customers (DNS, Apps, etc.) and not between two remote customers who must communicate correct?" 

     Yes, this is called shared or common services, which is nothing else but a VRF with some services (DNS, Internet), and by playing with RT values you give access to these services to multiple customers, and you can even do route filtering per customer, like for each customers give the routes for all or partial services. Here's a good design for doing it.

Regards,

Cristian Matei.