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 (18.104.22.168/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 22.214.171.124 source GigabitEthernet 0/2 R-NAT# ping 126.96.36.199 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 188.8.131.52 (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 184.108.40.206 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 220.127.116.11 Host2$ ping 18.104.22.168
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 22.214.171.124 (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 126.96.36.199 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 188.8.131.52 source GigabitEthernet 0/2 R-NAT# ping 184.108.40.206 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 220.127.116.11 (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 18.104.22.168 (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 22.214.171.124 (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 – 126.96.36.199 (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 188.8.131.52 (Picture 9).
Picture 9: OSPF Router ID 184.108.40.206
The R2 router learns about both NAT prefixes 220.127.116.11/24 and 18.104.22.168/24 from R-NAT via OSPF (Picture 8). OSPF routes are then redistributed to iBGP (Picture 7). The DMZ route 22.214.171.124 is learned via iBGP from DMZ router (126.96.36.199).
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 188.8.131.52 (CE-1) on DMZ router is set to 150. The local preference for the route 0.0.0.0 and the 184.108.40.206 (CE-2) neighbor is 100 by default. The path via iBGP neighbor 220.127.116.11 (CE-1) is preferred because the preference value 150 is higher than 100.
Picture 10: BGP Table of Router DMZ
The path via 18.104.22.168 (R1) to prefixes 22.214.171.124 and 126.96.36.199 is preferred to the path via 188.8.131.52 because the Router-ID 184.108.40.206 (R1) is lower than Router-ID 220.127.116.11 (R2). The route 18.104.22.168 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 22.214.171.124/16 and 126.96.36.199/16 networks and received from the 188.8.131.52 (ISP-A) peer (Picture 11).
CE-1# show ip bgp
Picture 11: BGP Table of CE-1
Similarly, the router CE-2 receives the 184.108.40.206/16 and 220.127.116.11/16 routes from the 18.104.22.168(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 22.214.171.124 from the 126.96.36.199 (CE-1) peer (Picture 13). ISP-B, however receives the same route from two sources – 188.8.131.52 (ISP-A) and 184.108.40.206 (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 220.127.116.11/24, advertised to ISP-B.
Picture 14: BGP Table of ISP-B