Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Route Map Question

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.

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Route Map Question

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

4 REPLIES
Cisco Employee

Route Map Question

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

New Member

Route Map Question

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?

Cisco Employee

Route Map Question

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

New Member

Re: Route Map Question

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

276
Views
0
Helpful
4
Replies
CreatePlease to create content