Recently at work I ran across a weird static NAT implemention, where it had the “extendable” key word, and the router had two Internet connections (two public IPs):
ip nat inside source static 10.0.0.1 100.0.0.2 extendable
ip nat inside source static 10.0.0.1 200.0.0.2 extendable
The “extendable” option allows static NAT mappings of one Inside Local Address (private address) to multiple Inside Global addresses (public addresses), the keyword “extendable” is added to the end of the mapping statements. [cisco]
This is a good option for accessing one a server via two Internet connections, the traffic can come from any internet connection, that public address gets translated to the same private address (server address), this raises no ambiguity.
As for traffic started by the server with destination to the Internet, I didn’t found very clear information on how the router handles the ambiguity created by the fact that the SERVER address (private address) can be translated to two public addresses.
So in order two answer this question i did some testing, using the topology above.
Testing Conclusions
My conclusions where the following:
The Nat extendable works great in following direction:
- R3->R1 (ISP1 –> SERVER)
- R4->R1 (ISP2 –> SERVER)
because the isn't any ambiguity
But in the inverse direction
- R1->R3 (SERVER –> ISP1)
- R1->R4 (SERVER –> ISP2)
it depends on the on the order of intruduction of the NAT rules,
R2-CFG1
ip nat inside source static 10.0.0.1 100.0.0.2 extendable - R1->R3 - OK
ip nat inside source static 10.0.0.1 200.0.0.2 extendable - R1->R4 - NOK
or
R2-CFG2
ip nat inside source static 10.0.0.1 200.0.0.2 extendable - R1->R4 - OK
ip nat inside source static 10.0.0.1 100.0.0.2 extendable - R1->R3 - NOK
where the first introduced NAT rule is the one that works
despite of always having the same order on the running-config
ip nat inside source static 10.0.0.1 100.0.0.2 extendable
ip nat inside source static 10.0.0.1 200.0.0.2 extendable
My guess, is that it’s that this happens because the first rule is considered the main rule and second rule "extends" it (secondary rule), and when there’s ambiguity it defaults to the main rule.
Topology and Configuration
R1
==========================
hostname R1
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
duplex auto
speed auto
ip route 0.0.0.0 0.0.0.0 10.0.0.254
line con 0
logging synchronous
line aux 0
line vty 0 4
password cisco
login
R2
===========================
hostname R2
interface FastEthernet0/0
ip address 10.0.0.254 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 100.0.0.1 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 200.0.0.1 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!
ip nat inside source static 10.0.0.1 100.0.0.2 extendable
ip nat inside source static 10.0.0.1 200.0.0.2 extendable
R3
==========================
hostname R3
interface FastEthernet0/1
ip address 100.0.0.254 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
R4
==========================
hostname R4
interface FastEthernet0/1
ip address 100.0.0.254 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
Tests – Part 1
Initial NAT Table on R2
--------------------------------------------------------------
R2#show ip nat translations
Pro Inside global Inside local Outside local Outside global
--- 100.0.0.2 10.0.0.1 --- ---
--- 200.0.0.2 10.0.0.1 --- ---
Trying To Ping R3 and R4 from R1 via NAT on R2
--------------------------------------------------------------
R1#ping 100.0.0.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/21/40 ms
R1#ping 200.0.0.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
NAT Table on R2 after the Pings from R1->R3 / R1->R4
--------------------------------------------------------------
R2#show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 100.0.0.2:30 10.0.0.1:30 100.0.0.254:30 100.0.0.254:30
icmp 100.0.0.2:31 10.0.0.1:31 200.0.0.254:31 200.0.0.254:31
--- 100.0.0.2 10.0.0.1 --- ---
--- 200.0.0.2 10.0.0.1 --- ---
The ping to R4 didn't work, and you can see why on second translation in the NAT table (the "Inside Global" instead of beeing 200.0.0.2 it’s 100.0.0.2 and R4 does not know network 100.0.0.0/24, so it does not reply)
Trying To Ping R1 from R3 and R4 via NAT
--------------------------------------------------------------
R3#ping 100.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/24/36 ms
R4#ping 200.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/23/32 ms
As you can see in this direction things work great
NAT Table on R2 after the Pings from R3->R1 / R4->R1
--------------------------------------------------------------
R2#show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 100.0.0.2:5 10.0.0.1:5 100.0.0.254:5 100.0.0.254:5
icmp 200.0.0.2:7 10.0.0.1:7 200.0.0.254:7 200.0.0.254:7
--- 100.0.0.2 10.0.0.1 --- ---
--- 200.0.0.2 10.0.0.1 --- ---
Trying To Ping R3 and R4 from R1 via NAT on R2 (AGAIN)
----------------------------------------------------------
R1#ping 100.0.0.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/21/40 ms
R1#ping 200.0.0.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
This was just to see if the ping from R3->R1 and R4->R1,
could somehow influence the pings in the opposite direction
from R1->R3 / R1->R4, but no, the result is the same.
Tests – Part 2
R2 Config Change – Change the Order of the NAT Rules
--------------------------------------------------------
no ip nat inside source static 10.0.0.1 100.0.0.2 extendable
no ip nat inside source static 10.0.0.1 200.0.0.2 extendable
ip nat inside source static 10.0.0.1 200.0.0.2 extendable
ip nat inside source static 10.0.0.1 100.0.0.2 extendable
As you will see bellow instead of a success ping from R1->R3,
you will see a successful ping from R1->R4, and the running
config looks the same before and after this change:
...
ip nat inside source static 10.0.0.1 100.0.0.2 extendable
ip nat inside source static 10.0.0.1 200.0.0.2 extendable
...
Initial NAT Table on R2
---------------------------------------------------------------
R2#show ip nat translations
Pro Inside global Inside local Outside local Outside global
--- 100.0.0.2 10.0.0.1 --- ---
--- 200.0.0.2 10.0.0.1 --- ---
Trying To Ping R3 and R4 from R1 via NAT on R2
--------------------------------------------------------------
R1#ping 100.0.0.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#ping 200.0.0.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/31/60 ms
NAT Table on R2 after the Pings from R1->R3 / R1->R4
---------------------------------------------------------------
R2#show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 200.0.0.2:39 10.0.0.1:39 100.0.0.254:39 100.0.0.254:39
icmp 200.0.0.2:40 10.0.0.1:40 200.0.0.254:40 200.0.0.254:40
--- 200.0.0.2 10.0.0.1 --- ---
--- 100.0.0.2 10.0.0.1 --- ---
The ping to R3 didn't work, and you can see why on first translation in the NAT table (the "Inside Global" instead of beeing 100.0.0.2 it’s 200.0.0.2 and R3 does not know network 200.0.0.0/24, so it does not reply)
Trying To Ping R1 from R3 and R4 via NAT
--------------------------------------------------------------
R3#ping 100.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/24 ms
R4#ping 200.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/23/24 ms
NAT Table on R2 after the Pings from R3->R1 / R4->R1
--------------------------------------------------------------
R2#show ip nat translations
R2#show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 100.0.0.2:6 10.0.0.1:6 100.0.0.254:6 100.0.0.254:6
icmp 200.0.0.2:8 10.0.0.1:8 200.0.0.254:8 200.0.0.254:8
--- 200.0.0.2 10.0.0.1 --- ---
--- 100.0.0.2 10.0.0.1 --- ---
Trying To Ping R3 and R4 from R1 via NAT on R2 (AGAIN)
--------------------------------------------------------------
R1#ping 100.0.0.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#ping 200.0.0.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/28
This was just to see if the ping from R3->R1 and R4->R1,
could somehow influence the pings in the opposite direction
from R1->R3 and from R1->R4, but no, the result is the same.
As stated before in the conclusions above:
- R1->R3 (SERVER –> ISP1) –– OK on Tests - Part 1
- R1->R4 (SERVER –> ISP2) –– OK on Tests - Part 2
the order of the introduction off the NAT static matters, because only the first rule is used, because of the ambiguity.
Links
- http://www.ciscopress.com/articles/article.asp?p=25273&seqNum=4
- http://www.cisco.com/en/US/technologies/tk648/tk361/tk438/technologies_white_paper09186a0080091cb9.html
- Example: http://ccie4all.wordpress.com/2013/01/12/nat-with-extendable-keyword/
- Small Example: http://network-101.blogspot.pt/2011/05/nat-extendable-option.html
- http://www.routerie.com/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=50;t=003660
- http://network-101.blogspot.pt/2011/05/nat-extendable-option.html?m=1
http://www.dslreports.com/forum/r24372553-Nat-Extendable-Command - http://network-101.blogspot.pt/2011/05/nat-extendable-option.html?m=1
