[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