[c-nsp] Restrictions for NAT Integration with MPLS VPNs

Joe Maimon jmaimon at ttec.com
Fri Mar 18 13:05:48 EST 2005



Oliver Boehmer (oboehmer) wrote:
> 
> 
> Yes, this is not supported (but it works, see below).
> 
> 
>>ip vrf RED
>>  rd 10:10
>>!
>>int fa0/0/0
>>ip vrf forwarding RED
>>ip address 192.168.1.1 255.255.255.0
>>ip nat inside
>>!
>>int fa0/1/0
>>ip vrf forwarding RED
>>ip address 66.16.17.1 255.255.255.0
>>ip nat outside
>>!
> 
> 
> This configuration works, though (I tried it in 12.3(6)), but the
> current vrf-aware NAT functionality was designed around central services
> (several VRFs with overlapping IP addresses  want to access SP's central
> services, like an Internet connection), so the outside interface is
> usally in the global table.

Thats good news.
> 
> We'll release new vrf-aware NAT functionality in the upcoming 12.3(14)T
> release (due out soon)  which will also allow to translate between
> separate VRFs.
Thats even better.
> 
> Any reason you can't do NAT on the CE devices?
I can but that means managing additional nat devices and also they do 
not have a clear picture as to what interfaces may constitute 
inside/outside.

Usualy one would end up pushing as much NAT as possible out to CE simply 
because complete natting in the core has trouble scaling.


SO I would put a fairly generic acl on the CE doint nat to the internet 
for example but preventing nat between all large prefixes that *MIGHT* 
be inside interfaces upstream and on the upstream I have another nat 
that covers this.

Also some device are lacking in their nat capabilities.

Furthermore translation between vrf's is easily something required to 
provide services and not something one would like dependant on the 
(possibly) CE devices. Such as commond devices on the SP network that 
need to be accessible between all vrf's. It is nice to be able to corral 
those into their own VRF as well.


> 
> 	oli
> 
> 


More information about the cisco-nsp mailing list