[c-nsp] CEF issue with NAT pool with add-route keyword (NVI)
Dale Shaw
dale.shaw+cisco-nsp at gmail.com
Tue May 19 01:37:55 EDT 2009
Hi,
I've just encountered a strange problem:
<SW1>__Vlan10 --> Fa0/0__<R1>__Se0/1/0 --> Se0/1/0__<R4>
SW1's config is:
interface Loopback0
ip address 10.255.8.8 255.255.255.255
!
interface Vlan10
ip address 10.1.18.8 255.255.255.0
!
router rip
version 2
network 10.0.0.0
no auto-summary
8<---
R1's config is:
interface FastEthernet0/0
ip address 10.1.18.1 255.255.255.0
ip nat enable
!
interface Serial0/1/0
ip address 10.1.14.1 255.255.255.0
ip nat enable
!
router rip
version 2
redistribute static metric 1
network 10.0.0.0
no auto-summary
!
ip access-list standard SW1_LOOPBACK
permit host 10.255.8.8
!
ip nat pool NET188 10.1.188.1 10.1.188.254 prefix-length 24 add-route
ip nat source list SW1_LOOPBACK pool NET188
8<---
R4's config is:
interface Serial0/1/0
ip address 10.1.14.4 255.255.255.0
clock rate 128000
!
router rip
version 2
network 10.0.0.0
no auto-summary
8<---
- RIPv2 is providing full reachability between all interfaces.
- R1 is configured to translate the source IP of packets from SW1's
Lo0 IP address (10.255.8.8) to 10.1.188.x
- R4 sees the 10.1.188.0/24 route being redistributed by R1:
R1#sh ip ro 10.1.188.0
Routing entry for 10.1.188.0/24
Known via "static", distance 0, metric 0
Redistributing via rip
Advertised by rip metric 1
Routing Descriptor Blocks:
* directly connected, via NVI0
Route metric is 0, traffic share count is 1
R4#sh ip ro 10.1.188.0
Routing entry for 10.1.188.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 10.1.14.1 on Serial0/1/0, 00:00:00 ago
Routing Descriptor Blocks:
* 10.1.14.1, from 10.1.14.1, 00:00:00 ago, via Serial0/1/0
Route metric is 1, traffic share count is 1
- When telnetting from SW1's Lo0 IP to R4's loopback (10.255.4.4), a
connection is established, but it's extremely slow/patchy due to
packet loss.
- If I send a ping (same src/dst as above), I see output like this:
SW1#ping 10.255.4.4 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.255.4.4, timeout is 2 seconds:
Packet sent with a source address of 10.255.8.8
!.!.!
Success rate is 60 percent (3/5), round-trip min/avg/max = 8/11/17 ms
- If I enable 'debug ip cef drops' on R1, I see output like this:
CEF-Drop: Stalled adjacency for 0.0.0.0 on NVI0 for destination 10.1.188.1
CEF-Drop: Packet for 10.1.188.1 -- encapsulation
CEF-Drop: Stalled adjacency for 0.0.0.0 on NVI0 for destination 10.1.188.1
CEF-Drop: Packet for 10.1.188.1 -- encapsulation
- I've found two workarounds:
1) disable CEF on R1's Se0/1/0 interface:
R1#conf t
R1(config)#int s0/1/0
R1(config-if)#no ip route-cache cef
OR:
2) remove 'add-route' from the 'ip nat pool' statement, and add a
static route manually:
R1(config)#do clear ip nat nvi trans *
R1(config)#no ip nat pool NET188 10.1.188.1 10.1.188.254 prefix-length
24 add-route
R1(config)#ip nat pool NET188 10.1.188.1 10.1.188.254 prefix-length 24
R1(config)#ip route 10.1.188.0 255.255.255.0 10.1.18.8
Either workaround restores 'good' connectivity -- no packet loss, no
CEF drops evident on R1.
Has anyone else seen this behaviour? I'm running:
Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version
12.4(23), RELEASE SOFTWARE (fc1)
cheers,
Dale
More information about the cisco-nsp
mailing list