problems with ping rates thru cisco 3845

Hello, I have a problem with a cisco 3845, 12.3(11r)T1, which has me complety stupefied, and welcome any help or comments.

When I try to ping a host thru it, it looks like I can't get a ping rate of one packet every two seconds, i.e (-i n means to send a packet every 'n' seconds):

=========================================== arraga@mauser:~$ ping -i 1 10.67.129.1 PING 10.67.129.1 (10.67.129.1) 56(84) bytes of data.

64 bytes from 10.67.129.1: icmp_seq=1 ttl=254 time=964 ms 64 bytes from 10.67.129.1: icmp_seq=3 ttl=254 time=1.59 ms 64 bytes from 10.67.129.1: icmp_seq=5 ttl=254 time=1.66 ms 64 bytes from 10.67.129.1: icmp_seq=7 ttl=254 time=1038 ms 64 bytes from 10.67.129.1: icmp_seq=9 ttl=254 time=0.982 ms 64 bytes from 10.67.129.1: icmp_seq=11 ttl=254 time=1.11 ms

--- 10.67.129.1 ping statistics ---

11 packets transmitted, 6 received, 45% packet loss, time 10003ms rtt min/avg/max/mdev = 0.982/334.663/1038.188/471.871 ms, pipe 2

arraga@mauser:~$ ping -i 0.5 10.67.129.1 PING 10.67.129.1 (10.67.129.1) 56(84) bytes of data.

64 bytes from 10.67.129.1: icmp_seq=1 ttl=254 time=1.74 ms 64 bytes from 10.67.129.1: icmp_seq=5 ttl=254 time=1.00 ms 64 bytes from 10.67.129.1: icmp_seq=9 ttl=254 time=1.32 ms 64 bytes from 10.67.129.1: icmp_seq=12 ttl=254 time=1.98 ms

--- 10.67.129.1 ping statistics ---

13 packets transmitted, 4 received, 69% packet loss, time 6035ms rtt min/avg/max/mdev = 1.001/1.514/1.984/0.381 ms

arraga@mauser:~$ ping -i 0.2 10.67.129.1 PING 10.67.129.1 (10.67.129.1) 56(84) bytes of data.

64 bytes from 10.67.129.1: icmp_seq=1 ttl=254 time=1.36 ms 64 bytes from 10.67.129.1: icmp_seq=11 ttl=254 time=0.946 ms 64 bytes from 10.67.129.1: icmp_seq=21 ttl=254 time=1.00 ms 64 bytes from 10.67.129.1: icmp_seq=29 ttl=254 time=0.965 ms

--- 10.67.129.1 ping statistics ---

30 packets transmitted, 4 received, 86% packet loss, time 5946ms rtt min/avg/max/mdev = 0.946/1.068/1.362/0.173 ms

=========================================

But if I let more than 2 secs between pings, I have 100% success.

arraga@mauser:~$ ping -i 2 10.67.129.1 PING 10.67.129.1 (10.67.129.1) 56(84) bytes of data.

64 bytes from 10.67.129.1: icmp_seq=1 ttl=254 time=1.13 ms 64 bytes from 10.67.129.1: icmp_seq=2 ttl=254 time=83.0 ms 64 bytes from 10.67.129.1: icmp_seq=3 ttl=254 time=1.05 ms 64 bytes from 10.67.129.1: icmp_seq=4 ttl=254 time=1.01 ms 64 bytes from 10.67.129.1: icmp_seq=5 ttl=254 time=157 ms 64 bytes from 10.67.129.1: icmp_seq=6 ttl=254 time=1.03 ms 64 bytes from 10.67.129.1: icmp_seq=7 ttl=254 time=0.978 ms

--- 10.67.129.1 ping statistics ---

7 packets transmitted, 7 received, 0% packet loss, time 12004ms rtt min/avg/max/mdev = 0.978/35.074/157.281/57.351 ms ============================================

Now, here comes the strange part.

The line in the access-list that lets ping to go thru is this:

fw3800#sh access-list filtrado-inbound-ri Extended IP access list filtrado-inbound-ri ... 21 permit icmp 10.0.0.0 0.255.255.255 any echo (2061 matches) ... (270 more lines).

If I change it to:

21 permit icmp 10.0.0.0 0.255.255.255 any echo log

The problem automagically goes away, as exemplified by:

root@mauser:/home/arraga # ping -i 0.1 10.67.129.1 PING 10.67.129.23 (10.67.129.23) 56(84) bytes of data.

64 bytes from 10.67.129.1: icmp_seq=1 ttl=126 time=15.3 ms 64 bytes from 10.67.129.1: icmp_seq=2 ttl=126 time=5.40 ms 64 bytes from 10.67.129.1: icmp_seq=3 ttl=126 time=5.26 ms 64 bytes from 10.67.129.1: icmp_seq=4 ttl=126 time=5.96 ms 64 bytes from 10.67.129.1: icmp_seq=5 ttl=126 time=5.20 ms 64 bytes from 10.67.129.1: icmp_seq=6 ttl=126 time=5.39 ms 64 bytes from 10.67.129.1: icmp_seq=7 ttl=126 time=5.32 ms 64 bytes from 10.67.129.1: icmp_seq=8 ttl=126 time=6.81 ms 64 bytes from 10.67.129.1: icmp_seq=9 ttl=126 time=5.57 ms

--- 10.67.129.1 ping statistics ---

9 packets transmitted, 9 received, 0% packet loss, time 1111ms rtt min/avg/max/mdev = 5.176/6.340/15.368/2.757 ms

Now i'm sending 10 icmps by second, and no one gets lost. Only one gets thru when the 'log' is not present in the access-list entry.

The interface has a double NAT (the origin and source of the echos and echo-replys are changed in the 3845), 10.67.129.1 is the nat'd address of the output interface.

Greets!

Reply to
arraga
Loading thread data ...

snipped-for-privacy@gmail.com schrieb:

[...}

First thing which makes me wonder is the different TTL in your examples. Next: What is IP 10.67.129.23 and what 10.67.129.1?

Christian

Reply to
Christian Lox

Standard practice. Routers have better thing to do than reply to ping packets every second. If they arrive too quickly, they will be ignored.

B
Reply to
Bob Goddard

The cut & paste got mixed,

10.67.129.1 is the router interface to the 10.67.129.0/24 net, and 10.67.129.23 is one of the machines in that net.

The same behaviour occurs if I ping the interface, or if I ping any of the machines behind. I got confused between the examples.

The 10.67.129.0/24 net is a nat, the real ip address of that net is in the 172.20.25.0/24 range.

So, it's like

10.0.0.0/8 | 3845 | 172.20.25.0/24 (which is nated to 10.67.129.0/24)

There's an applied access list to the inbound interface. Everything in the 10.0.0.0/8 net, when accessing the 10.67.129.0/24 net is nated to a single ip (10.66.254.1)

Best regards, Santiago

Reply to
arraga

That would make sense, but the same behaviour occurs when I try to ping any of the machines behind the router (10.67.129.23, for example).

I was pinging the interface in order to discard any possible net problem behind it.

Best regards, Santiago

Reply to
arraga

[snip]

You probably ran into some type of a bug. That would be my first guess.

couple of questions

1) Do you have redundant routes to your destination? 2) Are you rate-limiting your ICMPs (ip icmp rate-limit..." 3) Are you using any control-plane throttling?
Reply to
Hansang Bae

Since he's nat'ing it should be going through the router. Not terminating at the router. Cisco's default is (was?) 2 per second per interface (last time I checked). Maybe it was two every half a second?

Reply to
Hansang Bae

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.