Hi,
On Sun, 26 Jul 1998 sthaug@nethelp.no wrote:
> We have had reasonable success with rate limiting ICMP (using CAR) on a
> 7500 with HSSI (running at E3, 34 Mbps). We recently switched our main
> external connection from HSSI to POSIP (155 Mbps), and the rate limiting
> no longer works the same way - or at least the *statistics* certainly
> don't work the same way.
>
> This is the access-list:
>
> permit icmp any any
> deny ip any any
>
> and this is how we use it on the input side:
>
> rate-limit input access-group 198 160000 8000 8000 conform-action transmit exceed-action drop
>
> Here is a typical example of "show int posip5/0/0 rate" at approximately
> 2 second intervals:
>
> params: 160000 bps, 8000 limit, 8000 extended limit
> conformed 5274 packets, 2177696 bytes; action: transmit
> exceeded 0 packets, 0 bytes; action: drop
> last packet: 6328ms ago, current burst: 0 bytes
> last cleared 00:05:34 ago, conformed 52000 bps, exceeded 0 bps
>
> params: 160000 bps, 8000 limit, 8000 extended limit
> conformed 5274 packets, 2177696 bytes; action: transmit
> exceeded 0 packets, 0 bytes; action: drop
> last packet: 8472ms ago, current burst: 0 bytes
> last cleared 00:05:36 ago, conformed 51000 bps, exceeded 0 bps
>
> params: 160000 bps, 8000 limit, 8000 extended limit
> conformed 5701 packets, 2267286 bytes; action: transmit
> exceeded 0 packets, 0 bytes; action: drop
> last packet: 559796632ms ago, current burst: 3812 bytes
> last cleared 00:05:38 ago, conformed 53000 bps, exceeded 0 bps
>
> The first two entries show that the rate limiting statistics are updated
> less frequently that once every 2 seconds (there were certainly several
> ICMP packets during this interval, but the output shows none). The last
> entry is rather interesting in that the number of packets that conformed
> (ie. should be allowed) suddenly increased by more than 400, and the
> time for the last packet suddenly was 560.000 seconds ago :-)
>
> I've done a few experiments which seem to indicate that the ICMP rate
> limiting still *works* - but these statistics don't give me any warm
> fuzzy feelings. On the HSSI interface, the rate limiting statistics
> seem much more consistent (reasonably even increase of packets that
> conform, time for last packet behaving sanely).
>
> The router in question is running 11.1(18.1)CE.0520, using distributed
> CEF switching, and the POSIP interface has
>
> no ip route-cache optimum
> ip route-cache distributed
>
> We also tried "ip route-cache flow" in addition - this made no apparent
> difference to the rate limiting statistics. "ip route-cache distributed"
> *does* make a difference, though - if we remove this, the rate limiting
> statistics are back to normal. We also have higher CPU usage, of course,
> and thus would prefer to use "ip route-cache distributed".
>
> Anybody who can comment on this?
>
> Steinar Haug, Nethelp consulting, sthaug@nethelp.no
>
It seems like the RSP does not sees the stats generated by the VIP card.
With CEF there are no more cache misses so there are not many packets
destined to the RSP itself (there are no cache misses). When you turn off
distributed switching you are "forcing" the RSP to see these packets. Try
looking at the stats from the VIP console.
best,
Amir
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:13 EDT