[c-nsp] Cat6500 odd arp behavior

[Vinny_Abello at Dell.com]

Hi Andrew,

Rate-limiting arp in hardware on this platform was confusing when I researched it years ago. I remember finding conflicting information on this list that seemed to contradict Cisco. I'll check out that link and revisit that. Thanks.


This is from one of the switches, but they both show identical output:

Switch1#show mls rate-limit usage
                             Rate Limiter Type     Packets/s   Burst
                           ---------------------   ---------   -----
Layer3 Rate Limiters:
             RL# 0: Used
                                     MTU FAILURE         100      10
             RL# 1: Used
                                     TTL FAILURE         100      10
             RL# 2: Used
                                   ICMP REDIRECT         100      10
             RL# 3: Used
                                 UCAST IP OPTION         100      10
             RL# 4: Used
                                 MCAST IP OPTION         100      10
             RL# 5: Used
                                  IP RPF FAILURE         100      10
                           ICMP UNREAC. NO-ROUTE         100      10
                           ICMP UNREAC. ACL-DROP         100      10
                                       IP ERRORS         100      10
             RL# 6: Used
                                    ACL VACL LOG        2000       1
             RL# 7: Used
                                  MCAST DFLT ADJ      100000     100
             RL# 8: Rsvd for capture           -           -       -

Layer2 Rate Limiters:
             RL# 9: Reserved
             RL#10: Reserved
                                MCAST PARTIAL SC      100000     100
             RL#11: Free                       -           -       -
             RL#12: Free                       -           -       -

Switch1#show mls qos protocol
 Modes: P - police, M - marking, * - passthrough
 Module: All - all EARL slots;    Dir: I&O - In & Out;   F - Fail

 Proto Mode Mod Dir AgId Prec         Cir    Burst   AgForward-By   AgPoliced-By
--------------------------------------------------------------------------------


-----Original Message-----
From: David Prall [mailto:dcp at dcptech.com] 
Sent: Thursday, January 24, 2013 3:14 PM
To: 'Andrew Miehs'; Abello, Vinny
Cc: cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Cat6500 odd arp behavior

What does "show mls rate-limit usage" show for GLEAN

What does "show mls qos protocol" show for ARP

"mls qos protocol police arp" is what you want to be using to rate limit ARP
requests at L2.

This white paper goes into the hardware rate-limiters, as well as CoPP on
the 6500:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper
_c11_553261.html 

There could still be a bug, all the above testing was done with the latest
SXH release.

David

--
http://dcp.dcptech.com


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Andrew Miehs
> Sent: Thursday, January 24, 2013 2:43 PM
> To: <Vinny_Abello at Dell.com>
> Cc: <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] Cat6500 odd arp behavior
> 
> There is a problem with some dell machines and 4500s - this may be the
> same issue. Try turning off PoE on the port of use the latest firmware on
the
> dell.
> 
> 
> Sent from a mobile device
> 
> On 25/01/2013, at 5:01, <Vinny_Abello at Dell.com> wrote:
> 
> > Hi all,
> >
> > I've been having a reproducible problem across multiple Catalyst 6509
> switches running the same IOS 12.2(33)SXI4a for a while now that I just
can't
> nail down.
> >
> > In many situations where the switch is configured with an SVI on VLAN to
> function as a gateway, very often I find that I am unable to communicate
> with a newly added device or assigned IP on an existing device on that
> VLAN. No amount of probing it will appear to get it to respond. However,
if I
> am on the device itself where the IP is bound and just do a simple ping
out
> to something which has to traverse the SVI IP as a gateway, as long as the
> origin of the packet is the same IP, the switch then seems to learn the
MAC
> address properly and all is happy and continues to work from that point
> forward.
> >
> > Is there something that would prevent ARP from discovering these newly
> added devices when the switch would be soliciting the network segment
> for the MAC address for a certain IP? I was leaning towards bug... or I
have
> some unintended consequence due to the CoPP policy or rate-limiters on
> these switches which are also the same.
> >
> > I have the following mls rate limiters defined:
> >
> > mls rate-limit multicast ipv4 ip-options 100 10
> > mls rate-limit unicast ip options 100 10
> > mls rate-limit unicast ip icmp redirect 100 10
> > mls rate-limit all ttl-failure 100 10
> > mls rate-limit all mtu-failure 100 10
> >
> > I have policing on arp packets in CoPP (which I think if I remember is
done
> in software anyway), but I recall completely removing this and still
having
> the same issue.
> >
> > For reference, I'm doing in CoPP:
> >
> > class-map match-all CoPP_ARP
> >  match protocol arp
> >
> > policy-map CoPP
> > ...
> >  class CoPP_ARP
> >   police 8000000
> >  ...
> >
> > Thanks for any assistance or advice!
> >
> > -Vinny
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/