NAT Integration with MPLS VPN

[loris.marcellini]

Hi there,

I'm going through a NAT configuration in a MPLS VPN environmet, I've choosen to configure one of the 2 PE as Egress NAT PE, the translation actually occurs between 2 VRFs, the internal one which is called "mgmt" and needs to reach the remote Network and the outside one which is the "Internet".

Actually I've just applied the configs based on the guidelines found in the following post:

http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/112084-ios-nat-mpls-vpn-00.html

Scenario:

My Network topoogy is:

Router 41= Egress NAT PE

Router 42= Other PE (I've just created a loopback on it, as Source Network to be "NATTED")

Router 40= CE (I've just created a loopback on it, as remote Destination Network able to respond only to the NAT pool)

Topology attached.

Router 41 configs:

vrf definition mgmt
rd 41.41.41.41:1
route-target export 1:1
route-target import 1:1
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
vrf definition www
rd 41.41.41.41:2
route-target export 2:2
route-target import 2:2
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family

multilink bundle-name authenticated
mpls label protocol ldp
!
!
interface Loopback0
ip address 41.41.41.41 255.255.255.255
ip ospf 100 area 0
!
interface Loopback100
vrf forwarding mgmt
ip address 10.0.0.1 255.255.255.255
ip nat inside
ip virtual-reassembly in
!
interface Ethernet0/0.10
encapsulation dot1Q 10
vrf forwarding www
ip address 10.0.10.1 255.255.255.0
ip nat outside
ip virtual-reassembly in
!
interface Ethernet0/0.12
encapsulation dot1Q 12
ip address 10.0.12.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip ospf 100 area 0
mpls ip

!

router ospf 100
!
router bgp 123
bgp log-neighbor-changes
redistribute connected
neighbor 42.42.42.42 remote-as 123
neighbor 42.42.42.42 update-source Loopback0
neighbor 42.42.42.42 soft-reconfiguration inbound
!
address-family vpnv4
neighbor 42.42.42.42 activate
neighbor 42.42.42.42 send-community extended
exit-address-family
!
address-family ipv4 vrf mgmt
network 0.0.0.0
redistribute connected
redistribute static
exit-address-family
!
address-family ipv4 vrf www
network 0.0.0.0
redistribute connected
redistribute static
exit-address-family
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip nat pool DUB-PUBLIC-IP 185.185.185.1 185.185.185.254 netmask 255.255.255.0
ip nat inside source list NAT pool DUB-PUBLIC-IP vrf mgmt overload
ip route vrf mgmt 0.0.0.0 0.0.0.0 Ethernet0/0.10 10.0.10.40
ip route vrf www 0.0.0.0 0.0.0.0 10.0.10.40
!
ip access-list extended NAT
permit ip 10.0.23.0 0.0.0.255 any
permit ip 10.0.0.0 0.0.0.255 any

Router 42 Configs:

vrf definition mgmt
rd 42.42.42.42:1
route-target export 1:1
route-target import 1:1
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
vrf definition www
rd 42.42.42.42:2
route-target export 2:2
route-target import 2:2
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
!

interface Loopback0
ip address 42.42.42.42 255.255.255.255
ip ospf 100 area 0
!
interface Ethernet0/0
no ip address
!
interface Ethernet0/0.12
encapsulation dot1Q 12
ip address 10.0.12.2 255.255.255.0
ip ospf 100 area 0
mpls ip
!
interface Ethernet0/0.23
encapsulation dot1Q 23
vrf forwarding mgmt
ip address 10.0.23.2 255.255.255.0

!
!
router ospf 100
!
router bgp 123
bgp log-neighbor-changes
redistribute connected
neighbor 41.41.41.41 remote-as 123
neighbor 41.41.41.41 update-source Loopback0
neighbor 41.41.41.41 soft-reconfiguration inbound
!
address-family vpnv4
neighbor 41.41.41.41 activate
neighbor 41.41.41.41 send-community extended
exit-address-family
!
address-family ipv4 vrf mgmt
redistribute connected
exit-address-family
!
address-family ipv4 vrf www
exit-address-family

Router 40 Configs:

interface Loopback0
ip address 40.40.40.40 255.255.255.255
!
interface Ethernet0/0
no ip address
!
interface Ethernet0/0.10
encapsulation dot1Q 10
ip address 10.0.10.40 255.255.255.0

!
ip route 185.185.185.0 255.255.255.0 10.0.10.1

Everything works perfectly, the logs below are the proof the traffic is being received correctly translated:

*Jan 26 17:08:37.896: ICMP: echo reply sent, src 40.40.40.40, dst 185.185.185.1, topology BASE, dscp 0 topoid 0
*Jan 26 17:08:37.902: ICMP: echo reply sent, src 40.40.40.40, dst 185.185.185.1, topology BASE, dscp 0 topoid 0
*Jan 26 17:08:37.907: ICMP: echo reply sent, src 40.40.40.40, dst 185.185.185.1, topology BASE, dscp 0 topoid 0
*Jan 26 17:08:37.913: ICMP: echo reply sent, src 40.40.40.40, dst 185.185.185.1, topology BASE, dscp 0 topoid 0
*Jan 26 17:08:37.919: ICMP: echo reply sent, src 40.40.40.40, dst 185.185.185.1, topology BASE, dscp 0 topoid 0

Problem:

I've just tried to avoid the following route-leaking:

ip route vrf mgmt 0.0.0.0 0.0.0.0 Ethernet0/0.10 10.0.10.40

I've replaced that configuring a mutual import between VRFs so that the MGMT would knows the route to the Internet through the www VRF's imported route.

Everything looked fine at control plane, even though the NAT wasn't actually working and the traffic has started being received not translated, so no reply for that.
My question is, why? I mean, is that the same to use a Static Route allowing the Route Leaking between those VRFs and use a mutual import between them? What's the difference in doing that?

Many Thanks

Loris

[Giuseppe Larosa · Accepted solution]

Hello Loris,

>>

I've just tried to avoid the following route-leaking:

ip route vrf mgmt 0.0.0.0 0.0.0.0 Ethernet0/0.10 10.0.10.40

I've replaced that configuring a mutual import between VRFs so that the MGMT would knows the route to the Internet through the www VRF's imported route.

Everything looked fine at control plane, even though the NAT wasn't actually working and the traffic has started being received not translated, so no reply for that.

###################

The static route for leaking that you have removed makes the traffic to through the "NAT outside" interface triggering NAT action that happens only when traffic crosses a NAT inside to a NAT outside interface.

When playing with route targets the detail of the interface to be  used for the default route is lost in the forwarding plane and this makes NAT to stop to work.

This is my opinion on your issue. And compliments for the clear explanation of your setup and the link to the reference design document that you have used.

I have seen and used in the past tricks to make NAT working with L3 VPN, but the basics of NAT ( always the static routes were part of the solution), is the one I have explained before traffic flow to be NATTED must cross a network boundary from a NAT inside to a NAT outside interface.

Here the action is distributed between ingress PE and egress PE nodes, but the principle should still be valid.

Hope to help

Giuseppe

[loris.marcellini]

Hi Giuseppe,

Thank you very much for your reply and clear explanation on my question, it's actually weird sometimes 2 configurations doing the same at control-plane don't correctly work at data-plane, I'd say that it's like a dogma, you have to believe that it's like that

I'm looking forward to have another very interesting discussion with you like this.

Loris