PE NAT
Did you know that NAT on IOS can be VRF-aware? You can NAT hosts from multiple VRFs to the same IP address, or pool of IP addresses. This can be used to easily offer internet access to an L3VPN service.
There are two types of PE NAT: Ingress and Egress. As the name suggests, Ingress NAT is when you NAT at the Ingress PE. In this case, the NAT function is potentially distributed among several PEs. Egress NAT is when you NAT at the Egress PE, which is typically only a single PE. (The PE that connects to the external shared service).
The beauty of NAT for L3VPN is that the router handles “remembering” which VRF the source came from, using a pointer in the NAT translation table which we will see in the lab.
The downside of PE NAT is that you must NAT to an interface in the global table. So PE NAT can really only be used if you run your internet routing in the global table. If you want to NAT to another VRF, you cannot use egress PE NAT. Instead you need to use ingress PE NAT and you need to leak routes for the underlying IGP address (which will be used as a NAT) to the target VRF. This is a huge burden, and I believe it is for this reason that we don’t see this feature used much in the real world. More often we will see the CPE doing NAT, with route leaking between VRFs using RTs.
Lab
We will use the following topology:
The setup so far is a standard L3VPN configuration that you are familiar with. CustomerA and CustomerB each have their own VRF. Gi2 on PE2 is in the global table and represents internet connectivity.
Here are the startup configs:
Egress PE NAT
PE2 will provide NAT and a route to the internet, acting as the egress PE. To do this, PE2 needs to add the customer VRFs and inject a default route into each L3VPN.
Both CustomerA and CustomerB should now have a default route in their routing table:
Next, all we need to do is enable NAT on PE2. Gi1 will be the inside interface, and Gi2 will be the outside interface. It may seem a little strange that Gi1, a core interface, is the inside interface, but the router will automatically decipher the VRF the traffic belongs to via the MPLS label. This happens because we specify that the NAT translation is for each VRF.
We’ll now ping 8.8.8.8 from both customer routers:
By checking the verbose NAT translations on PE2, we can see how this works:
You can see above that the router is able to keep track of which VRF each client belongs to. In this case, both customers are using 10.1.1.1 as the source IP, but they are differentiated based on the MPLS label as traffic arrives from PE1 ingress on Gi1.
On PE1, you can see that the 0/0 route injected by PE2 for each VRF has a different MPLS service label. When traffic arrives on Gi1, PE2 uses this label to figure out which VRF the traffic belongs to.
The problem with Egress PE VRF-to-VRF NAT
Now you can understand the problem that occurs if you want to NAT to another VRF using egress PE NAT.
If you use RTs to inject a 0/0 route from another VRF into the customer VRFs, traffic ingressing Gi1 on PE2 will all appear with the same service label, which is for the shared-service VRF. PE2 will not be able to differentiate between the different customer VRFs, because all traffic has the same service label (representing the shared-service VRF).
Let’s try this out to really understand what happens:
Of course, we would also need the SHARED vrf to have reachability to the customer VRFs, but this is enough to demonstrate why this doesn’t work in the first place.
The customer routers have a 0/0 route again, but traffic ingressing Gi1 has the same service label for vrf SHARED (label 20) whether traffic comes from CustomerA or CustomerB.
Ping from CustomerA
Ping from CustomerB
To solve this, we would need to use ingress PE NAT.
Ingress PE NAT
Functionaly, PE NAT for the ingress PE works just like PE NAT for the egress PE. The difference is that you will be NATing to an address that is known in the core IGP. This is a bit ugly. I suppose you would need to have public addressing between core routers for this to work. For this lab, we’ll just pretend that 10.1.2.0/24 is reachable on the internet.
To preform ingress PE NAT on PE1, we use the same configuration as we saw for egress PE NAT on PE2:
Next, PE2 will need to route 10.1.2.0/24 back to the global table on the SHARED VRF. Return traffic from 8.8.8.8 will be destined for 10.1.2.1.
Both customer routers can ping 8.8.8.8 again. They are both being NATed to 10.1.2.2.
Further Reading
Last updated