[c-nsp] Cisco 6500/Sup720 ARP CoPP

[Rob Shakir]

On 9 Feb 2010, at 22:18, Nick Hilliard wrote:

> On 09/02/2010 21:30, Saku Ytti wrote:
>> Oh cool, I wonder if it then was software issue always or if this is
>> new feature in PFC3C.
> 
> I think this was before the pfc3c's time; the original text is here:
> 
> http://aharp.ittns.northwestern.edu/papers/copp.html

Hi Nick,

After some testing this morning, I'm a bit confused around this feature. There appears to be plenty of documentation that implies that CoPP is not supported for ARP on PFC3 (EARL7.5) type boxes. For example [0] - which is again from 2005, with the relevant quote being:

"ARP policies are not supported by CoPP. To protect the system by ARP broadcast a useful tool is “mls qos protocol arp police <bps>”. "

[1] also appears to say this too. So, my current understanding was that "match proto arp" is not something that one can do on 6500 (within CoPP).

On our existing PFC3BXL boxes, I can check the hardware QoS entries for ARP, with a configured class-default (so, this would imply that arp should perhaps fall within this), and I get the following:

7600#remote command switch show tcam interface vlan 1013 qos type2 arp | i ^([ ]+)[MAUFT]
    T     arp any any

When I check this on a 6500 with PFC3C, I do get an entry that implies policing would occur:

6500#remote command switch show tcam interface vlan 1013 qos type2 arp | i ^([ ]+)[MAUFT]
    MAU   arp any any
    AT    arp any any
    T     arp any any

However, I'm not sure whether this is a function of having "match protocol arp" or whether this is being caught by class-default. With a CoPP policy that is very basic for example purposes:

policy-map POLICY-COPP-INPUT
  class COPP-ARP
   police cir 80000000 bc 2500000 be 2500000    conform-action transmit     exceed-action drop     violate-action drop 
  class class-default
   police cir 100000000 bc 312500 be 312500    conform-action transmit     exceed-action drop     violate-action drop 

This results in the MAU arp entry above. With a small amount of ARP traffic, I can see something in the software counters:

    Class-map: COPP-ARP (match-all)
      61 packets, 3660 bytes

However, sh mls qos arp shows that the COPP-ARP class map hasn't forwarded any traffic:

6500#sh mls qos arp  | i CPP
           CPP  5  In   COPP-ARP    0    3   dscp  0              0              0
           CPP  5  In class-defa    0    1   dscp  0         665667              0
           CPP  6  In   COPP-ARP    0    3   dscp  0              0              0
           CPP  6  In class-defa    0    1   dscp  0              0              0

In addition, the MAU entry in the hardware is actually related to the class-default as far as I can see, not my class COPP-ARP. Applying a policy-map that has no COPP-ARP in it (identical the one above, otherwise) produces a similar hardware entry.

6500#remote command switch show tcam interface vlan 1013 qos type2 arp | i ^([ ]+)[MAUFT]
    MAU   arp any any
    AT    arp any any
    T     arp any any

This behaviour doesn't seem unchanged whether I not I configure "mls qos protocol ARP police..." on the box in question.

So, it appears to me like there's some confusion here - I'm not sure I can explain why the class-default in a policy-map on PFC3C appears to operate differently to PFC3BXL in terms of creating the hardware entry that the SP shows. In addition, I'm not entirely sure that this is being matched by the 'match proto arp' part of the policy-map.

It'd be nice to get some clarification of what this is actually doing! On your 6K5/7K6s do you see the same thing as this, or is any ARP class-map showing forwarding and/or policing?

Kind regards,
Rob

[0]: http://www.cisco.com/web/strategy/docs/gov/DATM_CoPP_ERSPAN_NetFlow.pdf
[1]: http://www.ciscosystems.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd802ca5d6.html

-- 
Rob Shakir                      <rjs at eng.gxn.net>
Network Development Engineer    GX Networks/Vialtus Solutions
ddi: +44208 587 6077            mob: +44797 155 4098
pgp: 0xc07e6deb                 nic-hdl: RJS-RIPE

This email is subject to: http://www.vialtus.com/disclaimer.html