Cart
In this post we look at a combination of features (NVI, VRF NAT and route leaking) that can be used to give Internet access to sites in an MPLS VPN. In some topologies the Internet belongs to an actual VRF and providing Internet access is trivial, as you can import and export route targets as needed. In other topologies the Internet belongs to the global table and providing Internet access requires a different, if not less-intuitive, configuration. Throw in private addressing, and it gets a little more complex.
The diagram is below and the rest of this post assumes a working MPLS VPN already configured for VPNA and VPNB.
Router NET is simulating a host on the Internet and is advertising its loopback 24.1.1.1 via IPv4 BGP to AS64512. PE1 is using its loopback1 interface for NAT and advertising this address into IPv4 BGP as well.
PE1#sho ip bgp | inc 24.1.1.1 *>i24.1.1.1/32 39.100.1.2 0 100 0 65000 i PE1#ping 24.1.1.1 sou lo 1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 24.1.1.1, timeout is 2 seconds: Packet sent with a source address of 39.101.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/100/120 ms
PE1 and PE2 are VPNv4 peers only in the interests of completion, we will not test connectivity to other sites. The first thing we need to do is inject a default route to VPNA and VPNB.
PE1(config)#router bgp 64512 PE1(config-router)#address-family ipv4 vrf VPNB PE1(config-router-af)#neighbor 10.1.0.1 default-originate PE1(config-router-af)# address-family ipv4 vrf VPNA PE1(config-router-af)#neighbor 10.0.0.1 default-originate
Verify they have been received.
CE1#sho ip bgp | be \*> *> 0.0.0.0 10.0.0.2 0 0 64512 i *> 10.0.1.1/32 0.0.0.0 0 32768 i
Next, on PE1 we need to add a route to router NET in the VRF with a global next-hop.
PE1(config)#ip route vrf VPNA 24.1.1.1 255.255.255.255 39.0.0.2 global PE1(config)#ip route vrf VPNB 24.1.1.1 255.255.255.255 39.0.0.2 global
That takes care of routing, now on to the fun stuff! Create two ACLs for each VPN, and then create two NAT statements. See if you can recognize the slight difference in the nat command syntax.
PE1(config)#ip access-list standard VPNA PE1(config-std-nacl)# permit 10.0.1.1 PE1(config-std-nacl)#ip access-list standard VPNB PE1(config-std-nacl)# permit 10.1.1.1 PE1(config-std-nacl)#exit PE1(config)#ip nat source list VPNA interface Loopback1 vrf VPNA overload PE1(config)#ip nat source list VPNB interface Loopback1 vrf VPNB overload
Notice we did not use the familiar “ip nat inside source….” commands. With the NVI configuration, we no longer need to specify inside and outside interfaces. Lastly, enable NAT on the appropriate interfaces, this includes both VRF interfaces, the outgoing interface and the loopback used for NAT.
PE1(config)#int s1/1 PE1(config-if)#ip nat enable *Aug 15 10:35:02.111: %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, changed state to up PE1(config-if)#int s1/2 PE1(config-if)#ip nat enable PE1(config-if)#int s1/0 PE1(config-if)#ip nat enable PE1(config-if)#int loop 1 PE1(config-if)#ip nat enable
The NVI0 interface comes up as soon as you enter the ip nat enable command. This interface is used internally and no configuration is required (or possible). Let’s test connectivity and run some commands to verify.
CE1#ping 24.1.1.1 sou lo 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 24.1.1.1, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 132/177/224 ms CE2#ping 24.1.1.1 sou lo 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 24.1.1.1, timeout is 2 seconds: Packet sent with a source address of 10.1.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 112/159/224 ms PE1#sho ip nat nvi translations Pro Source global Source local Destin local Destin global icmp 24.1.1.1:7 24.1.1.1:7 39.101.1.1:7 10.1.1.1:7 icmp 24.1.1.1:23 24.1.1.1:23 39.101.1.1:23 10.0.1.1:23
The NAT Virtual Interface (NVI) was introduced in 12.3T so look out for it on the SP lab and the R&S!
Regards, Bryan (Post by Bryan Bartik)
Tags: MPLS VPN
Bryan, So if the requirement explicitly does not prevent us using NVI, we can go ahead and do this on the SP lab right since this is much simpler than inside vs outside NAT setup.
As long as the IOS is 12.3 or greater which is what it will be for the CCIE SP.
Bryan, So if the requirement explicitly does not prevent us using NVI, we can go ahead and do this on the SP lab right since this is much simpler than inside vs outside NAT setup.
As long as the IOS is 12.3 or greater which is what it will be for the CCIE SP.
Hello Prasanna, I would say of course! As long as you meet the requirements and don’t break the rules, the solution should be accepted.
Hello Prasanna, I would say of course! As long as you meet the requirements and don’t break the rules, the solution should be accepted.
Prasanna
The NVI was developed for VRF Aware NAT so this is the method that should be used.
Prasanna
The NVI was developed for VRF Aware NAT so this is the method that should be used.
can we use route-map for the source list?
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtnatvi.html#wp1046679
it said that routemaps is not supported,
tks
Just a quick question – where or what is 39.0.0.2 in the ip route…. global statements?