In the last part of our tutorial (view previous part) we will verify that our configuration works properly. Let’s start with the R-NAT router.
As a first step, we are going to check whether NAT is working as expected. The source IP address of traffic going out of the interface Gi0/0 is being translated to an IP address from the NAT pool ISP-A (220.127.116.11/24). Multiple inside local addresses must be translated to a single inside global address as port address translations (PAT) or NAT overload is configured. Issue the ping command multiple times and check the NAT translation table on R-NAT.
R-NAT# ping 18.104.22.168 source GigabitEthernet 0/2 R-NAT# ping 22.214.171.124 source GigabitEthernet 0/2
Picture 1: NAT Translation Table when Traffic is Sent out of Gi0/0
The protocol is ICMP and an inside local address 172.16.0.1 is translated to the inside global address 126.96.36.199 (NAT pool ISP-A). Notice the numbers 14 and 15 mapped to the IP address. Those are ICMP identifiers included in the ICMP header of the IP packet (Picture 2). Their map associated ICMP echo requests to echo replies.
Picture 2: ICMP header of translated IP Packet
Now we will check whether PAT is in use issuing the ping command to 188.8.131.52 from two hosts (172.16.0.100 and 172.16.0.101), connected to the interface Gi0/2 of the R-NAT router. First, let’s delete the NAT translation table of R-NAT.
R-NAT# clear ip nat translation * Host1$ ping 184.108.40.206 Host2$ ping 220.127.116.11
Picture 3: NAT Translation Table when Traffic is Sent out of Gi0/0 from Two Hosts
PAT is in use because the router R-NAT has translated the inside local addresses 172.16.0.100 and 172.16.0.101 to a single inside global address 18.104.22.168 (Picture 3).
It is time to check the NAT translation table when ICMP echo request is sent out of the interface Gi0/1. The inside local address is dynamically mapped to the inside global address 22.214.171.124 when traffic is forwarded out of the Gi0/1. ICMP identifier is 16 inside the ICMP header of the IP packets related to the first ping command (Picture 4). ICMP identifier is 17 for the IP packets related to the second ping command.
R-NAT# clear ip nat translation * R-NAT# ping 126.96.36.199 source GigabitEthernet 0/2 R-NAT# ping 188.8.131.52 source GigabitEthernet 0/2
Picture 4: NAT Translation Table when Traffic is Sent out of Gi0/1
When the link between CE-1 and ISP-A is active, router R-NAT installs OSPF E2 external type route with a route metric 5 received from 184.108.40.206 (R1) into its routing table (Picture 5).
R-NAT# show ip route 0.0.0.0
Picture 5: OSPF E2 Route Installed in Routing Table of R-NAT when Link Between CE-1 and ISP-A is Active
Now, check the BGP table on R1. The R1 router learns the default route via iBGP from 220.127.116.11 (CE-1) (Picture 6).
R1# show ip bgp | begin Network
Picture 6: Default Route in BGP Table of R1 Learned via iBGP from CE-1
R2 learns the default route via iBGP from 18.104.22.168 (CE-2) (Picture 7). However, the route is not installed into the routing table of R2 because it is rejected. There is a default route with a better Administrative Distance (AD) 110 received from another source – 22.214.171.124 (R-NAT) learned via OSPF (Picture 8). The AD of iBGP route is 200. Therefore, a default route advertised by R-NAT with a lower AD 110 is installed into the routing table of R2.
R2# show ip bgp | begin Network
Picture 7: Default Route in BGP Table of R2 Learned via iBGP from CE-2
R2# show ip route ospf
Picture 8: Default Route in Routing Table of R2 Learned from OSPF
R1 is the originator of the default route advertised to R-NAT via OSPF and received by R2. Notice the OSPF router ID 126.96.36.199 (Picture 9).
Picture 9: OSPF Router ID 188.8.131.52
The R2 router learns about both NAT prefixes 184.108.40.206/24 and 220.127.116.11/24 from R-NAT via OSPF (Picture 8). OSPF routes are then redistributed to iBGP (Picture 7). The DMZ route 18.104.22.168 is learned via iBGP from DMZ router (22.214.171.124).
Let’s check the BGP table of the DMZ router located in DMZ (Picture 10). The router learns the default route from two sources. The local preference for default route 0.0.0.0 via 126.96.36.199 (CE-1) on DMZ router is set to 150. The local preference for the route 0.0.0.0 and the 188.8.131.52 (CE-2) neighbor is 100 by default. The path via iBGP neighbor 184.108.40.206 (CE-1) is preferred because the preference value 150 is higher than 100.
Picture 10: BGP Table of Router DMZ
The path via 220.127.116.11 (R1) to prefixes 18.104.22.168 and 22.214.171.124 is preferred to the path via 126.96.36.199 because the Router-ID 188.8.131.52 (R1) is lower than Router-ID 184.108.40.206 (R2). The route 220.127.116.11 is originated locally. The default weight for locally originated routes is 32768.
Let’s inspect the BGP table of CE-1. CE-1 contains a full Internet routing table size, simulated by the 18.104.22.168/16 and 22.214.171.124/16 networks and received from the 126.96.36.199 (ISP-A) peer (Picture 11).
CE-1# show ip bgp
Picture 11: BGP Table of CE-1
Similarly, the router CE-2 receives the 188.8.131.52/16 and 184.108.40.206/16 routes from the 220.127.116.11(ISP-B) peer (Picture 12).
Picture 12: BGP Table of CE-2
As the last step of our verification, we will examine the BGP tables of both ISPs. (Picture 13 and 14).
Picture 13: BGP Table of ISP-A
ISP-A learns the DMZ route 18.104.22.168 from the 22.214.171.124 (CE-1) peer (Picture 13). ISP-B, however receives the same route from two sources – 126.96.36.199 (ISP-A) and 188.8.131.52 (CE-2). (Picture 14). The path via ISP-A is being installed into the routing table of ISP-B because a path with the shortest AS_PATH is preferred. The requirement is to forward inbound traffic from the Internet to DMZ via CE-1 when a link between CE-1 and ISP-A is active and via CE-2 when the link is down. Therefore, we have configured CE-2 to prepend as-path three times with its own AS 64501 for the route 184.108.40.206/24, advertised to ISP-B.
Picture 14: BGP Table of ISP-B