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