[c-nsp] Cat6500 odd arp behavior
Vinny_Abello at Dell.com
Vinny_Abello at Dell.com
Fri Jan 25 17:18:16 EST 2013
mls qos is enabled. As others have eluded to, this seems to be related to CoPP caviats on this platform.
Thanks for the suggestions.
-Vinny
-----Original Message-----
From: David Prall [mailto:dcp at dcptech.com]
Sent: Thursday, January 24, 2013 3:45 PM
To: Abello, Vinny; andrew at 2sheds.de
Cc: cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Cat6500 odd arp behavior
I'd say you don't have "mls qos" configured, which is required for CoPP.
But, don't go turning it on without researching your entire config. Because
all of sudden Trust will be disabled and everything will be remarked to DSCP
0 by default. At least that is how it used to be, think that is still true.
Nothing should be rate limiting ARP's, unless of course CoPP is being done
in SW and the CPU just can't get it done. Which it is being done in SW
without mls qos configured. I will assume that "sh proc cpu sort" shows
nothing. What about "remote command switch show proc cpu sort"
David
--
http://dcp.dcptech.com
> -----Original Message-----
> From: Vinny_Abello at dell.com [mailto:Vinny_Abello at dell.com]
> Sent: Thursday, January 24, 2013 3:31 PM
> To: dcp at dcptech.com; andrew at 2sheds.de
> Cc: cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] Cat6500 odd arp behavior
>
> 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/whit
> e_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/
More information about the cisco-nsp
mailing list