[c-nsp] Cat6500 odd arp behavior

[Vinny_Abello at Dell.com]

Thanks Andrew... I should have elaborated further. The hosts aren't directly connected to the 6500. The 6500 aggregates several TOR switches just doing pure layer 2, no trunking or tagging or anything. The 6500 provides an SVI for each VLAN though to act as a gateway.

To further complicate things and I should have mentioned this, the two 6500's are also running GLBP between them which might be contributing to the problem. I just observed this where a device wasn't reachable through the switch(es). I could ping it directly from switch 1 sourced from the SVI on that VLAN. When I did the same on switch 2, it initially timed out and looked like it dynamically learned the MAC address via the normal arp process. Then I could access the device normally. I'm not sure why I needed to manually intervene on the second switch, but I suspect it has something to do with GLBP not working as intended.

-Vinny

-----Original Message-----
From: Andrew Miehs [mailto:andrew at 2sheds.de] 
Sent: Thursday, January 24, 2013 2:43 PM
To: Abello, Vinny
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/