IP_SLA_Tracking_RFC_Eth

I will use the IP SLA Track lab Topology to use SW1 as a host to perform the NAT on R2, however I have given the Ethernet segment a sub-network makeover!

So to preface this I thought it was a good idea just to throw up the RFC 1918 IP address ranges, as they are easy to forget when you took your CCNA when dinosaurs roamed the internet:

RFC Ranges:

10.0.0.0 /8
172.16.0.0 /12
192.168.0.0 /16

That being said, NAT is no different today than it was in your CCNA studies, but here is a quick reminder of the terminology of address types:

  • Inside Local = Non-Routable LAN address locally
  • Inside Global = Routable Translated Local LAN address
  • Outside local = Non-Routable LAN address at a remote location
  • Outside Global = Routable Translated Remote LAN address

The term “inside” and “outside” are really about perspective as defined above, if you are on the LAN being translated it is the “inside” local, however if your a network admin on the remote LAN they’d consider your LAN an “outside” LAN.

Now Global just refers to which side the Translation took place on, taking an RFC1918 address, and translating it to a routable internet address.

The private address is never seen on the outside of the network, and the local host has no idea that NAT has occurred either, it is totally transparent except on the local router. The local router stores the NAT Mappings of “inside local” to “inside global” addresses, and when the packets come back with that “inside global” address, it checks the NAT table for the mapping to the “inside local” address and routes the packets accordingly.

Static NAT (SNAT)

Static is only appropriate if you have very few hosts that require a static NAT entry, such as web facing servers, as this requires a one-to-one mapping of “inside local” to “inside global” addresses (meaning your company will need a larger IP block from the ISP to accommodate each entry needed).

IP NAT Mappings go closest to the host that they are being translated, obviously.

Now to configure Static NAT, the best place to start is assigning the appropriate interfaces with NAT, as that is the easiest part of the config to overlook while troubleshooting:

R2(config)#int fa0/0
R2(config-if)#ip nat inside
*Mar 30 20:46:38.938: %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, changed state to up
R2(config-if)#
R2(config-if)#do sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            10.1.1.2        YES manual up                    up
Serial0/0                  172.12.123.2    YES NVRAM  up                    up
FastEthernet0/1            unassigned      YES NVRAM  administratively down down
Serial0/1                  unassigned      YES NVRAM  administratively down down
NVI0                       unassigned      NO  unset  up                    up <—- Whaaat?
Loopback2                  2.2.2.2         YES NVRAM  up                    up
R2(config-if)#
R2(config-if)#int s0/0
R2(config-if)#ip nat out
R2(config-if)#

So two strange things here, I have not seen that NVI0 form when configuring “ip nat in” on an interface (to the point it creates a new logical interface), and also that the “ip nat out” on the serial interface went through without a hiccup.

From what I researched briefly, it explains that the NVI0 interface is created to NAT addresses over different VRF domains, and that is a can of worms I am not opening tonight – So on with the configuration I proceed.

So now to actually configure the NAT statement itself:

R2(config)#ip nat inside ?
  destination  Destination address translation
  source       Source address translation

R2(config)#ip nat inside source ?
  list       Specify access list describing local addresses
  route-map  Specify route-map
  static     Specify static local->global mapping

R2(config)#ip nat inside source static ?
  A.B.C.D  Inside local IP address
  esp      IPSec-ESP (Tunnel mode) support
  network  Subnet translation
  tcp      Transmission Control Protocol
  udp      User Datagram Protocol

R2(config)#ip nat inside source static 10.1.1.100 ?
  A.B.C.D    Inside global IP address
  interface  Specify interface for global address

R2(config)#ip nat inside source static 10.1.1.100 172.12.123.100 ?
  extendable  Extend this translation when used
  mapping-id  Associate a mapping id to this mapping
  no-alias    Do not create an alias for the global address
  no-payload  No translation of embedded address/port in the payload
  redundancy  NAT redundancy operation
  route-map   Specify route-map
  vrf         Specify vrf
  <cr>

R2(config)#ip nat inside source static 10.1.1.100 172.12.123.100
R2(config)#

As you can see there are a variety of options, but being this is static, I chose static instead of an ACL or Route-Map to define some addresses. I am using SW1 as my “inside local” host, and I chose the 172.12.123.100 as the “outside global” mapping as it is a /24 address space,  though it is important to understand in the real world 1:1 static NAT’s require larger IP blocks that cost your employer more money per block so plan carefully!

To verify your NAT mappings, use command “sh ip nat translation” :

R2#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
—      172.12.123.100     10.1.1.100                      —                   —
R2#

Now to test the NAT to see if it works! Lots of output here, I will try to separate it to make sense:

SW1(config)#ip route 0.0.0.0 0.0.0.0 10.1.1.2
SW1(config)#do sh ip route

Gateway of last resort is 10.1.1.2 to network 0.0.0.0

     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, Vlan1
S*   0.0.0.0/0 [1/0] via 10.1.1.2

Verified the default route points at my NAT router:
SW1#ping 172.12.123.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.123.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
SW1#

It is not responding correctly, so I run “debug ip pack” on R1 to see if the packets are even arriving on its S0/0 interface:

R1#debug ip pack
IP packet debugging is on
R1#
ASR#6
[Resuming connection 6 to sw1 … ]

SW1#ping 172.12.123.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.123.1, timeout is 2 seconds:
.
ASR#1
[Resuming connection 1 to r1 … ]

*Mar 31 17:52:23.863: IP: tableid=0, s=172.12.123.100 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar 31 17:52:23.863: IP: s=172.12.123.100 (Serial0/0), d=172.12.123.1 (Serial0/0), len 100, rcvd 3
*Mar 31 17:52:23.863: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.100 (Serial0/0), routed via RIB
*Mar 31 17:52:23.863: IP: s=172.12.123.1 (local), d=172.12.123.100 (Serial0/0), len 100, sending
*Mar 31 17:52:23.867: IP: s=172.12.123.1 (local), d=172.12.123.100 (Serial0/0), len 100, encapsulation failed
R1#
*Mar 31 17:52:25.862: IP: tableid=0, s=172.12.123.100 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar 31 17:52:25.866: IP: s=172.12.123.100 (Serial0/0), d=172.12.123.1 (Serial0/0), len 100, rcvd 3
*Mar 31 17:52:25.866: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.100 (Serial0/0), routed via RIB
*Mar 31 17:52:25.866: IP: s=172.12.123.1 (local), d=172.12.123.100 (Serial0/0), len 100, sending
*Mar 31 17:52:25.866: IP: s=172.12.123.1 (local), d=172.12.123.100 (Serial0/0), len 100, encapsulation failed

So this debug shows the Static NAT definitely is working, as the source address and destination of packets being received / sent are 172.12.123.100, however there is some sort of encapsulation failure that I just do not care to troubleshoot this late / early.

Lets see if the translation table looks any different for SNAT, I think it only really gets interesting when using Dynamic NAT.

So I’m going to repeat 10,000 pings 10 172.12.123.1 from SW1 and look at R2’s NAT table to see if it changes at all from what we saw above:

SW1#ping 172.12.123.1 repeat 10000

Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 172.12.123.1, timeout is 2 seconds:
.
ASR#2
[Resuming connection 2 to r2 … ]

R2#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 172.12.123.100:4  10.1.1.100:4       172.12.123.1:4     172.12.123.1:4
— 172.12.123.100     10.1.1.100         —                —
R2#

So from this, when there is not information flowing through a Static NAT, the Outside values in this “sh ip nat trans” table will be empty, but when it is in use it will show you the outside local / global addresses of the destination host / network.

So now I can tell that left column is Protocol, not sure what port 4 is about (is ICMP port 4?), as that shouldn’t be a random port number I wouldn’t think until we get into PAT (Port Address Translation) or “Port Overload”

However, that is Static Nat in a nut-shell, even though I didn’t get full L3 connectivity across the NBMA I did get it to translate and at 2am on a work night that’s all that matters 🙂