07-26-2012 03:01 PM - edited 03-07-2019 08:00 AM
Hello all,
I recently ran into an issue related with a route-map, and I am not sure what caused it. I am hoping that someone on the forums can provide a logical explanation.
I connected to the router via telnet through GRE tunnel 10 on the router.
The router has PAT configured for interface gig 0/0.1. Devices on the network will get translated to the IP address of interface gig 0/0.1 based on route-map NAT_TO_SERVER, which has a match statement referencing an ACL as well as a match statement referencing exit interface tunnel 10.
I deleted route-map NAT_TO_SERVER. I did not modify anything else in the config and my telnet session to the router was not affected. I then re-created route-map NAT_TO_SERVER. Before I could re-configure any of the match statements, my telnet session to the router terminated. I was not able to reconnect to the router until it was restarted (none of modifications were saved to the startup-config).
I am looking for a detailed explanation of why my telnet session to the router terminated the moment that I recreated route-map NAT_TO_SERVER.
Below are relevant portions of the router config. Addresses, names, and values have been changed for obvious security reasons.
interface GigabitEthernet0/0.1
encapsulation dot1Q 1
ip address 192.168.1.1 255.255.255.128
no ip redirects
ip nat inside
no ip virtual-reassembly
standby 1 ip 192.168.1.3
standby 1 priority 90
standby 1 preempt
end
interface GigabitEthernet0/1
bandwidth 1536
ip address x.x.x.x 255.255.255.248
no ip redirects
no ip unreachables
no ip proxy-arp
ip verify unicast source reachable-via rx allow-default allow-self-ping
ip nat outside
ip inspect filter out
no ip virtual-reassembly
duplex auto
speed auto
no cdp enable
crypto map VPN
max-reserved-bandwidth 95
service-policy output ISP_EDGE
end
interface Tunnel10
bandwidth 1544
ip address x.x.x.x 255.255.255.252
ip nat outside
no ip virtual-reassembly
ip tcp adjust-mss 1250
load-interval 30
delay 200000
qos pre-classify
tunnel source Loopback100
tunnel destination x.x.x.x
no clns route-cache
!
end
ip nat inside source route-map NAT_TO_SERVER interface GigabitEthernet0/0.1 overload
ip nat inside source route-map NAT_TO_ISP interface GigabitEthernet0/1 overload
route-map NAT_TO_SERVER permit 10
match ip address NAT_TO_SERVER
match interface Tunnel10
!
route-map NAT_TO_ISP permit 10
match ip address NAT_TO_ISP
match interface GigabitEthernet0/1
The router is a 2901 running C2900-UNIVERSALK9-M Version 15.0(1)M5
Any assistance with this question would be appreciated. Thank you.
Solved! Go to Solution.
07-26-2012 04:18 PM
Hi Oscar,
However, why would translating everything to the 192.168.1.1 address cause my telnet session to 192.168.1.1 via tunnel 10 to terminate?
The question is - what exactly got translated? If just the packets through the tunnel then the telnet would not have dropped. However, if the outer IP header of the tunneled packets itself got NATted then that could have broken the tunnel - because suddenly, the source IP address in the outer header of GRE-encapsulated packets was rewritten to 192.168.1.1 instead of being set to the address of Loopback100.
Best regards,
Peter
07-26-2012 03:20 PM
Hello Oscar,
This is my view of what happened. When you deleted the NAT_TO_SERVER route-map, the NAT configuration referencing the non-existent route-map was probably ignored - not sure about that. However, what I am absolutely sure is that when you recreated the route-map, before you were able to enter any match commands, the route-map became essentially a "permit any" block - it had only its heading defined and no match entries inside. This caused the command
ip nat inside source route-map NAT_TO_SERVER interface GigabitEthernet0/0.1 overload
to basically apply to all packets, resulting in the packets being NATted to 192.168.1.1 indiscriminately. That is why your telnet session "froze".
Best regards,
Peter
07-26-2012 03:49 PM
Thank you for the prompt response Peter. I also concluded that all traffic would have been translated. However, why would translating everything to the 192.168.1.1 address cause my telnet session to 192.168.1.1 via tunnel 10 to terminate?
Are you suggesting that too many NAT translations occurred and overloaded the router to the point where it stopped responding?
07-26-2012 04:18 PM
Hi Oscar,
However, why would translating everything to the 192.168.1.1 address cause my telnet session to 192.168.1.1 via tunnel 10 to terminate?
The question is - what exactly got translated? If just the packets through the tunnel then the telnet would not have dropped. However, if the outer IP header of the tunneled packets itself got NATted then that could have broken the tunnel - because suddenly, the source IP address in the outer header of GRE-encapsulated packets was rewritten to 192.168.1.1 instead of being set to the address of Loopback100.
Best regards,
Peter
07-26-2012 08:52 PM
Peter,
I had not fully considered the effect that NAT could have on the GRE header of packets flowing outbound from the router. I had assumed that NAT would not touch these packets.
Once I got home I decided to put your theory to the test in my home lab, and my testing results confirm your analysis that NAT disrupted functionality of the GRE tunnel and thus resulted in termination of my telnet session. Please see below.
1. I configured Router 1 with a config similar to the one that I shared in my intial post (routing config not shown):
Router 1
interface FastEthernet0/0.1
encapsulation dot1Q 1 native
ip address 192.168.1.1 255.255.255.128
ip nat inside
ip virtual-reassembly
end
interface Serial0/0/0
ip address 192.168.100.1 255.255.255.252
ip nat outside
ip virtual-reassembly
service-module t1 timeslots 1-24
end
interface Tunnel10
ip address 10.0.1.1 255.255.255.252
ip nat outside
ip virtual-reassembly
tunnel source Loopback100
tunnel destination 172.16.1.2
end
ip nat inside source route-map NAT_TO_ISP interface Serial0/0/0 overload
ip nat inside source route-map NAT_TO_SERVER interface FastEthernet0/0.1 overload
route-map NAT_TO_ISP permit 10
match ip address NAT_TO_ISP
match interface Serial0/0/0
!
route-map NAT_TO_SERVER permit 10
match ip address NAT_TO_SERVER
match interface Tunnel10
Router 2
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES NVRAM administratively down down
Serial0/0 192.168.100.2 YES manual up up
FastEthernet0/1 unassigned YES NVRAM administratively down down
Serial0/1 unassigned YES NVRAM administratively down down
NVI0 192.168.100.2 YES unset up up
Loopback100 172.16.1.2 YES manual up up
Tunnel10 10.0.1.2 YES manual up up
2. On Router 2, pings to 192.168.1.1 (Router 1) were successful:
Router2#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
3. On Router 2, I established a telnet session to 192.168.1.1 (Router 1).
4. On Router 1, I deleted the NAT_TO_SERVER route-map and then recreated it without any match statements.
5. On Router 2, I lost my telnet session to Router1 and pings to 192.168.1.1 (Router 1) were unsuccessful:
Router2#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
6. On Router 1, I captured the following NAT debug output (not all output shown):
*Jul 27 04:28:00.495: NAT: s=172.16.1.1->192.168.1.1, d=172.16.1.2 [617]
*Jul 27 04:28:00.651: NAT: translation failed (A), dropping packet s=10.0.1.1 d=224.0.0.10
*Jul 27 04:28:02.095: NAT: translation failed (A), dropping packet s=10.0.1.1 d=10.0.1.2
*Jul 27 04:28:02.499: NAT: s=172.16.1.1->192.168.1.1, d=172.16.1.2 [618]
*Jul 27 04:28:04.499: NAT: s=172.16.1.1->192.168.1.1, d=172.16.1.2 [619]
*Jul 27 04:28:05.123: NAT: translation failed (A), dropping packet s=10.0.1.1 d=224.0.0.10
*Jul 27 04:28:06.499: NAT: s=172.16.1.1->192.168.1.1, d=172.16.1.2 [620]
*Jul 27 04:28:07.095: NAT: translation failed (A), dropping packet s=10.0.1.1 d=10.0.1.2
*Jul 27 04:28:08.503: NAT: s=172.16.1.1->192.168.1.1, d=172.16.1.2 [621]
*Jul 27 04:29:02.099: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.1.2 (Tunnel10) is down: retry limit exceeded
This debug output shows that Router 1 started to translate GRE packets to the 192.168.1.1 address, which resulted in the GRE tunnel going down. (This debug output also shows that EIGRP packets were dropped, due to the GRE tunnel going down.)
Thank you again for your quick replies and for guiding me in the right direction!
Oscar
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide