WTT 10M link down. Checked due to FW sw f0/6 err-disabled and the interface is configured with bpdu guard. This triggers me the interests on what is the the actual difference between bpdu guard and bpdu filter on a switch interface.
bpdu guard
the port cannot receive any bpdu, if received, the port will be err-disable.
bpdu filter
the filter means more like from switch inside point of view, the bpdu is "filtered" (by the switch itself) from sending out of the switch port so it doesn't expect to receive any also. But it allow to receive, though not expect.
Reference
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/12-2_55_se/configuration/guide/3560_scg/swstpopt.html#wp1033638
===================================================================
https://supportforums.cisco.com/document/45136/importance-bpdu-guard-and-bpdu-filter
Blog from Ganesh Hariharan in supportforums.cisco.com
Introduction
In Networking World we know that to avoid any loops or any problem related to switching arcihtecure the stability of the Root Bridge is of paramount importance in the operation and continual uninterrupted service of spanning-tree. A change in the position of the Root Bridge will cause service disruption on the network with data and voice session timing out.
It is important to consider what events could cause a change in the position of the Root Bridge, events such as links failing between the existing Root Bridge and the rest of the network would cause a change, or possibly a duplex mismatch between the Root Bridge and downstream switches causing the spanning-tree messages from the Root Bridge from reaching the other parts of the network. These events are easily fixed and resolved none of which would require the use of the BPDU Guard feature.
Always a better practice to enforce the Spanning-tree domain borders and keep our active topology and the position of our Root Bridge predictable.
Best Practices to enable BPDU Guard only on access ports (access ports lead to end user devices) so that any end user devices on these ports that have BPDU Guard enabled are not able to influence the Spanning-tree topology.
Configuring BPDU Guard
Following are the modes in which we can configure BPDU Guard in switches
Interface mode
spanning-tree bpduguard enable (Puts port in errdisable upon receiving any bpdu).
Global mode
spanning-tree portfast bpduguard default (It enables bpduguard on ports that have port-fast configuration, puts port in errdisable upon receiving a bpdu).
Once BPDU Guard is enabled it will keep an eye open for any BPDU's entering the access ports. The only devices which can reliably create and transmit BPDU's are switches.Our main aim to have a predictable topology and not allow other switches outside our control onto our network. If a rogue switch is introduced into our topology it will in most cases transmit a BPDU, if the rogue switch has "better" values than the existing Root Bridge it will cause a topology change in the switched network. Any topology change is bad news for the users.
By configuring the "BPDU Guard" feature on the access-ports enables the spanning-tree protocol to shut the port down in the event that is receives a BPDU. As a rule of thumb, BPDU's are really only expected across trunk links.If a rogue switch is plugged into a port configured for BPDU Guard, the port will disable as soon as the first BPDU is received, by shutting the port down we prevent the rogue switch from affecting our spanning-tree topology.
To re-enable a port disabled by BDPU Guard you will need to remove the offending device and then bounce the port by issuing the shut/no shut command
BPDUfilter on the other hand just filters BPDUs in both directions, which effectively disables STP on the port.Bpdu filter will prevent inbound and outbound bpdu but will remove portfast state on a port if a bpdu is received.Enabling BPDU filtering on an interface is the same as disabling spanning tree on it and can result in spanning-tree loops.
Configuring BPDU Filter
Following are the method to configure BPDU Filter in switches
Interface mode
spanning-tree bpdufilter enable (Results port to not participate in STP, loops may occur).
Global mode
spanning-tree portfast bpdufilter default (It enables bpdufiltering on ports that have port-fast configuration, so it sends a few bpdu while enabling port then it filters bdpu unless receives a bpdu, after that it changes from port-fast mode and disables filtering for port to operate like a normal port because it has received bpdu).
You always should allow STP to run on a switch to prevent loops. However, in special cases when you need to prevent BPDUs from being sent or processed on one or more switch ports, you can use BPDU filtering to effectively disable STP on those ports.you would use bpdufilter when you want a switch plugged into your network but you don't want it participating in spanning tree.
An example: In an office environment where someone needs another network drop under their desk but you don't have time/budget to run a new line for now. you are been given a small switch but don't want it to break spanning tree.The switch you have lying around for this task is a simple unmanaged switch and will only have one uplink into your network. so you put bpdufilter on your switch port.
Ganesh.H
This thread in GroupStudy about using Auto-MDIX to enable the use of straight-through cables between switches reminded me of a real world issue involving the same technology. At my previous job, there was a “senior” engineer who supported a large site. She was having an issue with hard-setting the speed and duplex of an uplink port (I think it was a “stack” of 2950s) on a Cisco switch. While most of our uplinks were fiber, this one was copper (it was a small office that just needed to connect to the MDF on the floor directly above it). Our standard was to use a cross-over cable for any switch-to-switch connections and to hard-set the speed and duplex on both sides of the connection. She was having a problem with setting the speed and duplex. If she hard-set these settings on both sides of the link, then the link would go down. If she let one side of the link auto-negotiate, the link would come up, but the connection would not meet our standards. I eventually got dragged into this issue.
Looking at the switch settings, I noticed something odd: auto-MDIX was enabled (globally) on both switches. Our standard was to disable this on every switch. This gave us a little protection from users making unauthorized switch-to-switch connections (accidentally or on purpose) as cross-over cables were not generally available to end users (most wouldn’t know what a cross-over cable was). I asked the engineer if she was using a cross-over cable on the uplink.
Her response: “That’s not the problem. You can use a straight-through cable.”
“Sure you CAN, but our standard is to use crossover cables because….blah, blah, blah.”
Long story shorter: she refused to adhere to our standards and use a cross-over cable and I refused to waste my time on the issue. I wasn’t sure that the cabling was the issue, but if disabling auto-MDIX and using the proper cabling did not fix the issue then we could at least take those elements out of the equation.
She muddled on for a couple more days (she couldn’t be bothered to open a TAC case) and the problem remained. Finally our top-level LAN guy looked into the issue. He found the answer after a few minutes on Cisco’s web site (this is specific to the 3560):
Configuring Auto-MDIX on an Interface
When automatic medium-dependent interface crossover (auto-MDIX) is enabled on an interface, the interface automatically detects the required cable connection type (straight through or crossover) and configures the connection appropriately. When connecting switches without the auto-MDIX feature, you must use straight-through cables to connect to devices such as servers, workstations, or routers and crossover cables to connect to other switches or repeaters. With auto-MDIX enabled, you can use either type of cable to connect to other devices, and the interface automatically corrects for any incorrect cabling. For more information about cabling requirements, see the hardware installation guide.Auto-MDIX is enabled by default. When you enable auto-MDIX, you must also set the interface speed and duplex to auto so that the feature operates correctly. Auto-MDIX is supported on all 10/100 and 10/100/1000-Mbps interfaces and on 10/100/1000BASE-TX small form-factor pluggable (SFP)-module interfaces. It is not supported on 1000BASE-SX or -LX SFP module interfaces.
So you can use a straight through cable to connect two switches, but you then cannotexplicitly set the speed and duplex. The engineer was told that the solution to her problem was to disable auto-MDIX and use a cross-over cable. Where had I heard that before?
To be fair, I wasn’t aware of the auto-MDIX needing auto-negotiation issue, BUT whenever you are troubleshooting a problem you want to minimize any deviations from known working configurations to eliminate unnecessary variables. I think that I remember reading that auto-MDIX uses the same protocol as auto-negotiation and that’s why both need to be enabled. I’m not positive about that though.
This table is pretty interesting. I assume that “correct cabling” means a cross-over cable and “incorrect cabling” means a straight-through cable.
Local Side Auto-MDIX | Remote Side Auto-MDIX | With Correct Cabling | With Incorrect Cabling |
On | On | Link up | Link up |
On | Off | Link up | Link up |
Off | On | Link up | Link up |
Off | Off | Link up | Link down |
You can refer to the table below, but it’s pretty easy to determine if a link will be up or not: at least one side needs to have auto-MDIX enabled along with auto-negotiation of speed and duplex, otherwise the link will be down.
sw1
|
sw2
| |||
MDIX | Speed/Duplex | MDIX | Speed/Duplex | Link Status |
on | auto | on | auto | up |
on | auto | on | hard-set | up |
on | auto | off | auto | up |
on | auto | off | hard-set | up |
on | hard-set | on | auto | up |
on | hard-set | on | hard-set | down |
on | hard-set | off | auto | down |
on | hard-set | off | hard-set | down |
off | auto | on | auto | up |
off | auto | on | hard-set | down |
off | auto | off | auto | down |
off | auto | off | hard-set | down |
off | hard-set | on | auto | up |
off | hard-set | on | hard-set | down |
off | hard-set | off | auto | up |
off | hard-set | off | hard-set | down |
This makes sense because you need at least one side to be able to logically switch the pinouts of a straight-through cable to emulate a cross-over cable. Hard-setting the speed or duplex disables the auto-negotiation protocol (which auto-MDIX must utilize as well) which effectively disables auto-MDIX:
Note: The only command that I know of that will show the auto-MDIX state of an interface (other than looking at the running-configuration of the interface) is the rather verbose “show controllers ethernet-controller fax/x phy | include MDIX” command.
Note: The default setting for switch ports is to have auto-MDIX enabled. This is a pretty recent change though. IOS versions prior to 12.2(20)SE will use the default of “no mdix auto”.
“mdix auto” is the default, so it does not show in the running-configuration:
sw2(config)#do sh run int fa0/32
Building configuration…
Current configuration : 34 bytes
!
interface FastEthernet0/32
endWe can verify that auto-MDIX is on for this interface:sw2(config)#do sh controll eth fa0/32 phy | i MD Auto-MDIX : On [AdminState=1 Flags=0x00052248]Let’s hard-set the speed and see what happens to auto-MDIX:sw2(config)#int fa0/32
sw2(config-if)#speed 100sw2(config-if)#do sh control eth fa0/32 phy | i MD
Auto-MDIX : Off [AdminState=1 Flags=0x00010A48]Notice that our configuration does not state that auto-MDIX has been disabled:sw2(config-if)#do sh run int fa0/32
Building configuration…Current configuration : 45 bytes
!
interface FastEthernet0/32
speed 100
end
This verifies that hard-setting the speed and/or duplex turns off auto-MDIX for the interface.
Note: I did test to see if DTP was effected by auto-MDIX. It was not. As long as the link was up, DTP could work it’s trunking magic.
So the long and the short of it is: you can use straight-through cables to connect two Cisco switches as long as you are willing to sacrifice the ability to hard-set the speed and/or duplex on both sides of the link.
Cisco Documentation: