we've following situation
- switch A is third party unmanaged switch
- switch B is Catalyst 2950 or 2960
- switch C is Catalyst 2950 acting as "Service Provider Egde"
Switch A is connected to access port of switch B (configured with portfast), switches B and C are connected using 802.1q trunk
Someone created loop betweeen two interfaces of switch A. Switch B didn't have any suspicious message in the log, switch C shows "%SW_MATM-4-MACFLAP_NOTIF: Host XXXX.XXXX.XXXX in vlan YYY is flapping between port Gi0/3 and port Gi0/24".
Is there any feature, which can help us detect and mitigate such problem on switch B?
Thanks. Jan Klicka, SITMP
Looks like your switch C is not a 2950 as that model does not have gigabit ports 0/3 or 0/24. Is it perhaps a 2970?
Anyway, you could perhaps look at using bpduguard or some other STP feature. I hope the links below will be helpfull in the process:
NO NOT EVER CONNECT A SWITCH ONTO AN INTERFACE CONFIGURED AS PORTFAST, IT CAN CAUSE LOOPS. Sorry about the shouting, but that is an ever so important little point that may be relevant. If you have a switch in your network that you do not control, you need to be VERY careful.
I would allow ONLY ONE connection from that switch to my network, and seriously consider BPDU filter on the port so that their network can be as unstable as they want, but not affect mine. I wuld also confirm the the root bridge is in the right place - if I had to allow BPDUs in, I would frce my root to be root, whatver they did - look at things like rot guard. Any ports on my network that did not have a switch I knew about would have BPDU guard enabled - the third party don't like only one link, or think you are restricting them in some way so they plug int a different port. The moment their switch sends a BPDU, the interface on your switch is disabled.
What you need to do is tell us the topology. It could be that you have spanning tree issues that are causing instability in the network. What is the host, and where do G0/3 and G0/24 go?
I understand your statement and I'd shout as well, but I must cope with this problem and I cannot replace all unmanaged L2 switches, because the this situaction is spreaded over the whole network I manage in more than 30 times.
We use to have "spanning-tree portfast bpdufilter default" in the configuraction of B switch. During the failure state I replaced this line with "spanning-tree portfast bpduguard default". I expected, that the switch will hear its own BPDUs on the line and shut it, but it didn't happen (maybe I should just "restart" spanning tree or reload whole box).
I'm now trying to get your experience or "best practicies", before I'll make another set of experiments.
Thanks for your patience
Jan Klicka, SITMP
It would only see its own if it was directly linked back to itself. The unmanaged switch *should* have seen its own BPDUs and blocked itself, if the link was within itself.
BPDU Filter can be very dangerous - it effectively breakd spanning tree at that point - ignore BPDUs, do not send BPDUs. With BPDU Guard, if the switch sees any BPDU, it shuld put the port to err-disable. If you had BPDU guard and it stayed up, either filter was on at the same time (filter acts first) or there were no BPDUs coming in. No BPDUs means either the device attached is a hub, or it does not do spanning tree.
If yu have portfast where you habe any form of hub or switch, diable it - you are asking for spanning tree problems by having hubs or switches on portfast ports.
I still think you need to dentify and locate the device mentioned that was flapping, and track what is connected on the ports it was flapping between.