Friday, January 16, 2009

SNAT: Making it work?

This is a poorly documented feature and I really just played around with it until I got it to work. If you see anything missing or unnecessary, please comment. The one thing I worry about is I am using secondary addresses which may or may not be allowed in the lab. If you know another way, PLEASE let me know. Other than that, it was all kind of patchwork but it does the job :-)

Here is the topology:


R6 will be our test host who will telnet to R4 at 4.4.4.4. If all goes well, after we shut the link from R1 to R2 (whos is HSRP Active), R6 session will stay up. We will then look at the NAT translation table on R2 and R3.

Here is the configuration for R2:

interface FastEthernet0/0
ip address 10.0.0.2 255.255.255.0
ip nat inside
standby 1 ip 10.0.0.1
standby 1 priority 105
standby 1 preempt
standby 1 name SNAT
standby 1 track Serial1/0

interface Serial1/0
ip address 172.12.23.202 255.255.255.0 secondary
ip address 172.12.12.2 255.255.255.0
ip nat outside

ip nat Stateful id 1
redundancy SNAT
mapping-id 10

ip nat pool POOL 172.12.23.1 172.12.23.254 prefix-length 24
ip nat inside source list LAN pool POOL mapping-id 10 overload


R3 is pretty much the same except for the IP addresses:

interface FastEthernet0/0
ip address 10.0.0.3 255.255.255.0
ip nat inside
standby 1 ip 10.0.0.1
standby 1 preempt
standby 1 name SNAT
standby 1 track Serial1/0

interface Serial1/0
ip address 172.12.23.203 255.255.255.0 secondary
ip address 172.12.13.3 255.255.255.0
ip nat outside

ip nat Stateful id 1
redundancy SNAT
mapping-id 10

ip nat pool POOL 172.12.23.1 172.12.23.254 prefix-length 24
ip nat inside source list LAN pool POOL mapping-id 10 overload


I had to put secondary addresses on the serial links. These routers need to share an address space so they can use the same address to translate and so R1 and R4 no how to reach the translated address range. This secondary address range is being advertised in ospf:

R1#sho ip route 172.12.23.0
Routing entry for 172.12.23.0/24
Known via "ospf 1", distance 110, metric 128, type intra area
Last update from 172.12.12.2 on Serial1/0, 00:07:58 ago
Routing Descriptor Blocks:
* 172.12.13.3, from 172.12.35.3, 00:07:58 ago, via Serial1/1
Route metric is 128, traffic share count is 1
172.12.12.2, from 2.2.2.2, 00:07:58 ago, via Serial1/0
Route metric is 128, traffic share count is 1


Also note that the HSRP group name "SNAT" is referenced in the stateful NAT configuration. The mapping ID is then referenced in the NAT statement itself.

Let's telnet from R6 to R4, we will first verify that we route through R2:

R6#telnet R4
Translating "R4"
% Unknown command or computer name, or unable to find computer address
R6#telnet 4.4.4.4
Trying 4.4.4.4 ... Open

R4#
R4#!here we are!

Shut the interface on R1 to R2:

R1(config)#int s1/0
R1(config-if)#shut


Check back on R4. This may take awhile because HSRP still has to failover:

R4#
R4#
R4#!Hey we're still alive!
R4#
R4#exit

[Connection to 4.4.4.4 closed by foreign host]
R6#trace 4.4.4.4

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1 10.0.0.3 56 msec 48 msec 60 msec
2 172.12.13.1 132 msec 68 msec 104 msec
3 172.12.14.4 148 msec * 184 msec

We are going through R3! If we did not have SNAT, our session would have dropped when R4 noticed that our address has changed.

Let's look at our address translations:

R2#sho ip nat translations
Pro Inside global Inside local Outside local Outside global
udp 172.12.23.5:37518 10.0.0.6:37518 4.4.4.4:33441 4.4.4.4:33441
udp 172.12.23.5:39661 10.0.0.6:39661 4.4.4.4:33442 4.4.4.4:33442
udp 172.12.23.5:42398 10.0.0.6:42398 4.4.4.4:33437 4.4.4.4:33437
udp 172.12.23.5:36656 10.0.0.6:36656 4.4.4.4:33439 4.4.4.4:33439
udp 172.12.23.5:39090 10.0.0.6:39090 4.4.4.4:33438 4.4.4.4:33438
udp 172.12.23.5:35099 10.0.0.6:35099 4.4.4.4:33440 4.4.4.4:33440

R3#sho ip nat translations
Pro Inside global Inside local Outside local Outside global
udp 172.12.23.5:37518 10.0.0.6:37518 4.4.4.4:33441 4.4.4.4:33441
udp 172.12.23.5:39661 10.0.0.6:39661 4.4.4.4:33442 4.4.4.4:33442
udp 172.12.23.5:42398 10.0.0.6:42398 4.4.4.4:33437 4.4.4.4:33437
udp 172.12.23.5:36656 10.0.0.6:36656 4.4.4.4:33439 4.4.4.4:33439
udp 172.12.23.5:39090 10.0.0.6:39090 4.4.4.4:33438 4.4.4.4:33438
udp 172.12.23.5:35099 10.0.0.6:35099 4.4.4.4:33440 4.4.4.4:33440
R3#


Exactly the same! Have no idea where these ports came from, but let's watch closer at the interaction between R2 and R3.

R2#clear ip nat translation *
R3#clear ip nat translation *

R6#telnet 4.4.4.4
Trying 4.4.4.4 ... Open

R4#


Here we go:

R2#sho ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.23.6:47684 10.0.0.6:47684 4.4.4.4:23 4.4.4.4:23

R3#sho ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.23.6:47684 10.0.0.6:47684 4.4.4.4:23 4.4.4.4:23


Some more commands:

R2#sho ip snat distributed
Stateful NAT Connected Peers

SNAT: Mode IP-REDUNDANCY :: STANDBY
: State READY
: Local Address 10.0.0.2
: Local NAT id 1
: Peer Address 10.0.0.3
: Peer NAT id 1
: Mapping List 10


R3#sho ip snat distributed

Stateful NAT Connected Peers

SNAT: Mode IP-REDUNDANCY :: ACTIVE
: State READY
: Local Address 10.0.0.3
: Local NAT id 1
: Peer Address 10.0.0.2
: Peer NAT id 1
: Mapping List 10
R3#

R3 has already been updated and is ready to take over when needed.

1 comment:

  1. Hello,

    Another method to not use secondary IP is using eBGP between R1-R3 and R1-R2 and iBGP between R3-R2 and distributing into bgp the public pool used.

    ReplyDelete

Note: Only a member of this blog may post a comment.