[nsp] Observation using Modular QOS to mitigate Nachi
Brian Apley
nanog at apley.net
Tue Oct 14 22:36:30 EDT 2003
We've implemented Modular QOS at our edges per Cisco's specification (blocking ICMP with a min/max byte value of 92). We get periodic helpdesk yelps that ICMP isn't working- I'm inclined to tell them they're lucky ICMP is on at all, but I do notice this-
Here is the output from "show policy-map interface bvi10"
Service-policy input: drop-nachi
Class-map: nachi (match-all)
120880 packets, 14505600 bytes
5 minute offered rate 262000 bps, drop rate 498000 bps
Match: access-group 199
Match: packet length min 92 max 92
drop
Class-map: class-default (match-any)
391158 packets, 209299853 bytes
5 minute offered rate 3291000 bps, drop rate 0 bps
Match: any
Take the number of bytes, divide by the number of packets, and you should get 92, correct? no- it's actually 120.
Here's the funny part- no matter how many times the counters are cleared, or how many packets increment, it's always 120. Since the 92 includes the header, who wants to take a stab at where the other 28 bytes are coming from?
Also, any thoughts from people that have used Modular QOS on a large-scale level would be appreciated- we're mainly concerned with bugs (running 12.3.1(a)), and scale/process-switched issues.
Brian Apley
CCIE #7599, CCDP, CCSP, INFOSEC Professional
More information about the cisco-nsp
mailing list