Egress PE NAT44

Load nat44.vpn.lab1.init.cfg

#IOS-XE
config replace flash:nat44.vpn.lab1.init.cfg

#IOS-XR
configure
load bootflash:nat44.vpn.lab1.init.cfg
commit replace
y

L3VPN is fully setup. The R1-R2 link is in the global table, and is an internet connection. R2 learns 8.8.8.8/32 via R1 over the BGP session.

Using the egress PE NAT technique, allow any networks in RFC1918 space from VPN_A and VPN_B to NAT to the internet, using R2’s Gi2.12 address.

Answer

#R2
vrf definition VPN_A
 rd 100:1
 route-target export 100:1
 route-target import 100:1
 !
 address-family ipv4
 exit-address-family
!
vrf definition VPN_B
 rd 100:2
 route-target export 100:2
 route-target import 100:2
 !
 address-family ipv4
 exit-address-family
!
ip route vrf VPN_A 0.0.0.0 0.0.0.0 100.1.2.1 global
ip route vrf VPN_B 0.0.0.0 0.0.0.0 100.1.2.1 global
!
router bgp 100
 add ipv4 vrf VPN_A
  redistribute static
  default-information originate
 add ipv4 vrf VPN_B
  redistribute static
  default-information originate
!
!
int gi2.12
 ip nat outside
int gi2.23
 ip nat inside
int gi2.24
 ip nat inside
!
ip access-l ext RFC1918
 permit ip 10.0.0.0 0.255.255.255 any
 permit ip 172.16.0.0 0.15.255.255 any
 permit ip 192.168.0.0 0.0.255.255 any
!
ip nat inside source list RFC1918 interface gi2.12 vrf VPN_A overload
ip nat inside source list RFC1918 interface gi2.12 vrf VPN_B overload

Explanation

The egress PE NAT feature allows a single egress PE to provide VRF-to-global NATing for multiple VRFs. The egress PE enables NAT inside on the MPLS interfaces, and uses the service label to determine the VRF of the incoming packet. This is used as additional information in the stateful NAT entry.

To begin, we must define all of the VRFs locally on R2.

#R2
vrf definition VPN_A
 rd 100:1
 route-target export 100:1
 route-target import 100:1
 !
 address-family ipv4
 exit-address-family
!
vrf definition VPN_B
 rd 100:2
 route-target export 100:2
 route-target import 100:2
 !
 address-family ipv4
 exit-address-family

We then need to originate a default route and advertise it via VPNv4. R2 configures a static route that points to R1 in the default VRF, which is redistributed into the BGP VRF.

#R2
ip route vrf VPN_A 0.0.0.0 0.0.0.0 100.1.2.1 global
ip route vrf VPN_B 0.0.0.0 0.0.0.0 100.1.2.1 global
!
router bgp 100
 add ipv4 vrf VPN_A
  redistribute static
  default-information originate
 add ipv4 vrf VPN_B
  redistribute static
  default-information originate

Finally we configure the NAT rules. An extended ACL is used to match RFC1918-sourced traffic. NAT inside is set on the MPLS interfaces, which will receive the VPN traffic, and NAT outside is set on the external-facing interface which is in the default VRF. One NAT rule per VRF is required.

#R2
int gi2.12
 ip nat outside
int gi2.23
 ip nat inside
int gi2.24
 ip nat inside
!
ip access-l ext RFC1918
 permit ip 10.0.0.0 0.255.255.255 any
 permit ip 172.16.0.0 0.15.255.255 any
 permit ip 192.168.0.0 0.0.255.255 any
!
ip nat inside source list RFC1918 interface gi2.12 vrf VPN_A overload
ip nat inside source list RFC1918 interface gi2.12 vrf VPN_B overload

Verification

We can ping 8.8.8.8 from the loopback of each CE:

R2 is able to keep track of which VRF the packet belongs to based on the incoming service label. This is kept as a flag on the NAT entry. When return traffic arrives on Gi1.12, the NAT entry contains which VRF the traffic must be NATed back to.

For this reason, VRF-to-VRF cannot work on the egress PE. Let’s say that interface Gi2.12 was in an INET VRF. The customer VRFs could import the 0/0 route from the INET VRF. However, all traffic from any customer VRF would arrive at R2 with the INET VRF service lable. R2 can no longer differentiate between VRFs. This is why we are forced to do VRF-to-default NAT when using the egress PE NAT feature.