Switch goes down with cable between 2 ports

Deltah_

At work, a dude tell me that if he plugs a unintentional patch cable between 2 ports on the same switch in the save vlan, the switch goes down. I don't know all of the topology of this network but I captured run and interface config.



I will suggest to disable the unused port, set the switchport mode access and disable the bpdufilter feature because it takes precedence over bpduguard. I think that the bpduguard doesn't do his job in this type of config and it's why a loop was created and the switch goes completly down, am I wrong ?

This is the config of port who doesn't have a PC or a trunk plug in.

interface FastEthernet0/22
description RTIS_SSN
switchport access vlan 172
storm-control broadcast level 80.00
storm-control multicast level 80.00
storm-control unicast level 80.00
storm-control action shutdown
storm-control action trap
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable

Name: Fa0/22
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: down
Administrative Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 172 (VLAN0172)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled

bighornsheep

I'm going to assume everything else is okay, then I think you're right.

spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable

The choice of features doesn't make much sense.....for access ports where PCs would plug into, spanning-tree portfast will suffice, bpdufilter should be disabled to allow the algorithm to still process BPDU from that port if a switch (or itself) gets connected there.

dtlokee

Yeah, remove BPDU filter off the interface.

kpjungle

In a standard config where a PC is connected to an interface, in portfast status, would it actually hurt to have bpdufilter enabled along with bpduguard?

The reason for my question is, afaik bpdufilter on the interface, will stop the switch from sending bpdu's out of that interface as well.

If it receives any bpdu's, bpduguard should kick in and errdisable, no?

kryolla

config BPDU are only sent out designated ports and received on root ports and no TC BPDU are generated because of portfast. Why would you have filter and guard together one drops BPDUs and the other shuts down the port. Take your pick on which one you like put don't use both of them together unless you don't know what you are doing. To be honest I don't know if this is causing the switch to crash. Check your CPU level prior to the crash or memory. Then find out what's causing the spike. You have storm control to rate limit broadcast, multicast, and unicast so that shouldn't be causing it or try to reduce it even more.

kpjungle

kryolla wrote:

config BPDU are only sent out designated ports and received on root ports and no TC BPDU are generated because of portfast. Why would you have filter and guard together one drops BPDUs and the other shuts down the port. Take your pick on which one you like put don't use both of them together unless you don't know what you are doing. To be honest I don't know if this is causing the switch to crash. Check your CPU level prior to the crash or memory. Then find out what's causing the spike

True, but a portfast port is also designated.
I just labbed this:

f0/1 with portfast connected to a pc:

DLS1#sh spanning-tree interface f0/1 detail
Port 3 (FastEthernet0/1) of VLAN0001 is forwarding
Port path cost 19, Port priority 128, Port Identifier 128.3.
Designated root has priority 20481, address 0016.9d94.4900
Designated bridge has priority 20481, address 0016.9d94.4900
Designated port id is 128.3, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
The port is in the portfast mode
Link type is point-to-point by default
Bpdu filter is enabled internally
BPDU: sent 10, received 0

as show, it still sends bpdu's when in portfast mode.

Now after bpdufilter applied to the interface:
DLS1#sh spanning-tree interface f0/1 detail
Port 3 (FastEthernet0/1) of VLAN0001 is forwarding
Port path cost 19, Port priority 128, Port Identifier 128.3.
Designated root has priority 20481, address 0016.9d94.4900
Designated bridge has priority 20481, address 0016.9d94.4900
Designated port id is 128.3, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
The port is in the portfast mode
Link type is point-to-point by default
Bpdu filter is enabled internally
BPDU: sent 0, received 0

It wont send out bpdu's. Not that this is a cause of anything, but if you really DONT want to send anything, I guess you could use both.
I tried to put both bpduguard and bpdufilter on the f0/1 interface, and connect it to the same switch's f0/17. Bpdufilter takes precedence over bpduguard, and bpduguard never kicks in, even though f0/17 sends bpdu's, they are not being received by f0/1 and therefor not evaluated by bpduguard.

Seems its kind of dangerous to use bpdufilter since you can easily create a loop.

But i checked the cpu level, and it didnt raise it:
CPU utilization for five seconds: 5%/0%; one minute: 4%; five minutes: 4%

This on a 3560.

Hope that helps.

bighornsheep

Maybe a CCDP or R&S CCIE can give their thought, but as far as I know and have experienced, there's really only two reasons why you would want to use BPDU filter:

1) you're connecting a really stupid (or smart) device
2) you're connecting to a really stupid admin person/department.

In case 1, the device be it a server, another switch or what have you is so old (or sensitive) that it is not understanding the BPDU and isn't dropping it like a normal device would.

In case 2, you're uplinking to another department and their admin person is so stupid/stubborn to turn off BPDU guard on their switchport that you have no choice by apply BPDU filter on your side so the block doesn't get shut down.

Other than that, you should let BPDU transmit out all switchports so that your spanning tree will have a chance to apply features such as BPDU guard, root guard, loop guard etc. You can have the ideal spanning tree topology designed with all the good features, but if no switches are sending out BPDUs, spanning tree will not operate and loops could and likely will form.

Deltah_

Thank you for all the good comments/suggestions.

I think the person who configured the switch doesn't know what he was doing with STP concepts. I wish that the suggestions will be take in consideration to help this bad configuration and any problems that could happen in the future. I can't make this changes by myself so I really need to be convincing.

dtlokee

When we connect to metro Ethernet I will use BPDU filter on the interface to ensure that any BPDUs from the provider will be discarded. In this case you can't have a spanning tree loop due to a single connection. Other than that I don't use it on an internal switch due to the potenetial for the interface to be looped back to another interface in the switching domain.

bighornsheep

dtlokee wrote:

When we connect to metro Ethernet I will use BPDU filter on the interface to ensure that any BPDUs from the provider will be discarded.

You mean BPDU filter when enabled is a bidirectional filter? I thought it only filtered outgoing BPDU from the switch itself....learn something new every day....

EdTheLad

Yes its a bidirectional filter, but once a port with bpdu-filter comes up it will send afew bdpus before the filter kicks in.
Another reason to use the filter would be if you had a trunk port with 1000+ vlans configured, a bpdu must be generated for each vlan, each platform has a limitation on the number of bpdus it can send.You will most probably see the switch fallover due to a loop as the switch wont be able to generate bpdus fast enough.
In this case you would disable pvst+ with the bpdu-filter command or migrate to mst.