cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
373
Views
0
Helpful
1
Replies

Network Virtualization-Services Edge Design Question

apos11111
Level 1
Level 1

Hello,

I have read the Network Virtualization Services Edge Design Guide (single tier routed FWSM implementation) but still can't figure out how I am going to solve the problem of overlapping customer IP addresses without using NAT (which I am currently using).

So here is the problem:

My customers' IP spaces may overlap (as I don't have any control over them). From the shared servers I need to be able to manage customer kit using customer IP addresses.

So to cover both traffic flows (inbound and outbound) here is an example with customer_A and customer_B VRFs:

A. (inbound) SSH to a box in customer_A:10.1.1.1 or customer_B:10.1.1.1 from my shared server with a unique public IP:1.1.1.1

B. (outbound) customer_A:10.1.1.2 box authenticates on my shared services TACACS box on public 1.1.1.2 - Likewise customer_B:10.1.1.2 authenticates using 1.1.1.2 too.

The PE router directly attached to the shared servers can happily differentiate between customer_A and customer_B VRF routing tables and deal with the IP overlap I am describing, however I can't see how the shared servers (in OS and application level ) can deal with that IP overlap.

Right now, we are using NAT to overome the IP overlap problem, so customer_A:10.1.1.1 gets NAT'd to a unique management IP of: 10.255.255.1 and customer_B:10.1.1.2 gets NAT'd to a different (unique) management IP of 10.255.255.255.2. That works, however, due to the amount of NATs required, this solution (using NAT) doesn't scale very well for us. Hence my investigation in network virtualization. To be honest, as much as I want to get rid of NAT, I can't see how this scenario can work without it. Any assistance/thought is greatly appreciated, in case I am missing something obvious.

Thanks

1 Reply 1

Jon Marshall
Hall of Fame
Hall of Fame

Apostolos

The PE router directly attached to the shared servers can happily differentiate between customer_A and customer_B VRF routing tables and deal with the IP overlap I am describing, however I can't see how the shared servers (in OS and application level ) can deal with that IP overlap.

Correct in what you say. VRFs allow for use of overlapping IPs but if you have a server that needs to talk to multiple VRFs using the same overlapping IP then you need a way to distinguish them from each other. So NAT is the way to do it unless your server can understand VRF labels etc. and i'm not aware of any OSs/servers that can do this.

Jon

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco