packets are being switched to ports they should not.

[david.bradley]

I have a core switch, linked to various access layer switches. One access layer switch has 4 ports that are being sent a large number of packets that's overloading the port and bringing the port down every few minutes.

The four ports have workstations connected to them and are actually not used very often, so it's not a large problem, but Ciscoworks constantly tells me about this issue and I'm curious about the cause.

I have captured the traffic on the ports and I've found the all the traffic is incoming from the switchport, you'd expect that, the machines are standing idle. The incoming traffic is addressed to other machines in the same VLAN, but not even on this switch.

I've examined the CAM table on the switch and the MAC address is pointing to the core switch, the core switch has a CAM record pointing towards another access layer switch trunk.

So, the CAM records seem to be as you expect, but the frames are still reaching the ports, the frames are TCP replies, not ARPs UDP or broadcasts multicasts, etc..

The core switch is a 6500 CatOS 7.6(7)

All the access layer switces are 2924s on IOS 12.0(5)WCB3

any ideas!

Dave

[Prashanth Krishnappa]

When you see the unicast flooding happening issue the following commands to see if the CAM aging time gets reset to 15 seconds for the VLAN in question

sh cam aging <<--If it is a CAT OS switch

sh mac-address-table aging <<--For IOS switches

If it does, you are seeing Spanning tree TCNs. Make sure you have portfast configured on ports which have users. The following page should help

http://www.cisco.com/warp/public/473/143.html

[david.bradley]

hi,

thanks the link was very usefull, but my problem is not totally solved.

I changed the CAM cache to 14400 seconds and all was well, then it reappeared later. I checked the ARP cache setting and they have changed, as you said, to 15 seconds!!

I guess I have to track down the switches responsible for triggering the TCNs?

Dave

[Prashanth Krishnappa]

Changing CAM aging to match that of ARP timeout helps only with asymetric routing issues and not with CAM table being flushed because of TCNs. Even with CAM aging set to 14400, a TCN will reset it to 15 seconds. Track down where it is coming from and see if there are any links flapping. In IOS switches, we do not log link up/down messages by default. So have "logging event link-status" configured under the interfaces.

If you have not enabled portfast on user ports enable it as it avoids TCN generation.

[david.bradley]

Problem cured.

The problem was a combination of both the unidrectional routing and the TCNs. A few switches were sending out the TCNs and around 30-40 were hitting the switch per minute. Making sure portfast was enabled on all ports, cured the reset to 15 seconds.

This unicast floor continued and when I set the CAM aging time to 14400 and cleared the MSFC ARP caches the unicasts dropped to zero.

Thanks for pointing me in the right direction.

Dave