One other issue you may want to consider. If you have an ACL for incoming traffic from the vlan interface with HSRP/GLBP/VRRP on the 6500 it can cause odd behavior. Specifically pings from the secondary/standby will get dropped because they have to go into the vlan, then to the supervisor, then back out to the vlan. When they are coming into the supervisor they are blocked by the ACL. This applies to any glean traffic that enters the standby (not just icmp). Traffic that doesn't require glean is handled normally as it doesn't have to go to the CPU. The ACL can be fixed by allowing the incoming acl to cover all IPs on the vlan as the destination.
LR Mack McBride Network Architect -----Original Message----- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of vinny_abe...@dell.com Sent: Thursday, January 24, 2013 2:03 PM To: jeff-k...@utc.edu Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cat6500 odd arp behavior Interesting, Jeff... Sounds very similar. The one I was just troubleshooting was in a vrf as well, but I've seen the same behavior in the default vrf also, so I don't know that it applies so much to my situation. -Vinny -----Original Message----- From: Jeff Kell [mailto:jeff-k...@utc.edu] Sent: Thursday, January 24, 2013 3:51 PM To: Abello, Vinny Cc: and...@2sheds.de; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cat6500 odd arp behavior On 1/24/2013 3:24 PM, vinny_abe...@dell.com wrote: > 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. I had a somewhat similar issue a few months ago, I can dig up the TAC case if it helps, but there was no real resolution. We have a VRF that runs building controls and power monitoring. There is a backbone vlan on our core 6509 that carries the VRF for those buildings with a routed local vlan for this purpose, and another vlan (same VRF) that was routed out of the core for legacy devices not yet converted over to routing within the building. At any rate, the legacy vlan has an SVI in the core and was trunked out to the remaining legacy buildings, typically to a 3550/3560 EMI. After a campus-wide power outage that outlasted our building UPS's, a number of the power meters were "unreachable" from the core. No ARP entries, but the mac-address table was populated on the proper vlan. In the buildings themselves, the ports were on the proper vlans, and the mac-address tables populated. After numerous combinations of clear mac-address and clear arp and other efforts on both the core 6509 and building switches, nothing changed. In desperation, I created an SVI with a secondary address in the building switches. It *could* reach the meters and populated the local ARP table. The 6509 could not reach the power meters (same symptoms) but could reach the new SVIs. The new building SVI could also reach the other "unreachable" meters. Since the meters "seemed" to be OK and the only things at fault, we wrote it off to something peculiar with the meters. We even changed the IP of the meter and the core 6509 *could* reach it, until we changed it back. Since we were going to redo them to be routed at the building, we went ahead and did that and just wrote it off as a Siemens problem :) But it was the strangest thing I've ever seen on a 6509 for what should have been a CCNA-intro lab exercise (just a flat vlan, nothing fancy except it was in a VRF). _______________________________________________ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
