[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