$1,400 lunches occur when you read the commands instead of lab them up and debug on both sides...
I hate mention his name cause he's not on this chain, but when Scott Vermillion was doing his R/S in early 2008 he was always labbing stuff up, beyond even what I did, and when something like this came his way, his deep inspection of the command vs. the debugs paid off - he passed on his first attempt! Read the archives using google (site:groupstudy.com + scott vermillion) and you can see what it takes to be successful.
Think about it like this -
Put STP debugs on a switch with first the global and then the interface level of the bpdu-filter command enabled. Also, do it with a layer 2 port-channel in the mix using the interface level version; Do this will all tough stp things to remember (convergence timers, port priority, rstp, mstp). Do it many times until you are SURE you know how the protocol works both in the switch and how it arrives on the wire...
Review your debugs... what do they tell you?
"A CCNA knows the names of the protocols. A CCNP knows how they look in the config. But to be a CCIE, you must know how a router or switch processes the protocols internally AND how they look at raw packets and frames"
I used many debug sessions to remember what the ethertype was for ISL and 802.1q. 3 1/2 years later - I STILL REMEMBER THEM!
LOL
Joe
19366
-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Carlos G Mendioroz
Sent: Thursday, June 02, 2011 5:33 PM
To: Michael Kiefer
Cc: Nathan Falcon; Marko Milivojevic; Jason Boyers; ccielab_at_groupstudy.com
Subject: Re: Now I'm confused...
Cisco documents are good, but not perfect.
And functionality changes along the time.
This two combined makes it very difficult to be 100% sure about anything.
Case in point, your quoted paragraph says:
... This command prevents...sending or receiving BPDUs.
and then:
If a BPDU is received...
How can it receive a BPDU if the command is filtering them ?
I would assume it filters the sending only.
-Carlos
Michael Kiefer @ 02/06/2011 17:18 -0300 dixit:
> Based on Cisco's doc the second option of a global "spanning-tree portfast
> bpdufilter default" and and interface or global level "spanning-tree
> portfast" will make it happen.
>
> From:
>
> http://www.cisco.com/en/US/customer/docs/switches/lan/catalyst3560/software/release/12.2_58_se/configuration/guide/swstpopt.html
>
> At the global level, you can enable BPDU filtering on Port Fast-enabled
> interfaces by using the *spanning-tree portfast bpdufilter default* global
> configuration command. This command prevents interfaces that are in a Port
> Fast-operational state from sending or receiving BPDUs. The interfaces still
> send a few BPDUs at link-up before the switch begins to filter outbound
> BPDUs. You should globally enable BPDU filtering on a switch so that hosts
> connected to these interfaces do not receive BPDUs. If a BPDU is received on
> a Port Fast-enabled interface, the interface loses its Port Fast-operational
> status, and BPDU filtering is disabled.
>
> Like Marko said, the port won't listen and learn. It just loses its portfast
> status.
>
> There is also an error disable option that doesn't kill the link completely.
>
> To prevent the port from shutting down, you can use the errdisable detect
> cause bpduguard shutdown vlan global configuration command to shut down just
> the offending VLAN on the port where the violation occurred.
>
> This just kills the vlan that is sending the bpdu's. It doesn't seem very
> practical to have STP on some vlans and not on others, but it could be done.
>
> This is the kind of thing that makes for $1400 lunches. Nobody focuses on
> silly things like STP. It's all about the cool stuff!
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jun 2, 2011 at 8:53 AM, Michael Kiefer <mjkiefer_at_gmail.com> wrote:
>
>> I'm pretty sure that would just bounce the link over and over again based
>> on the recovery interval. The link will only stay up permanently if the
>> other side stops sending bpdu's.
>>
>>
>> On Thu, Jun 2, 2011 at 8:39 AM, Nathan Falcon <nathan.falcon_at_gmail.com>wrote:
>>
>>> Is it possible that your solution would be the following.
>>>
>>> (All global)
>>> spanning-tree portfast bpduguard default
>>>
>>> errdisable recovery cause bpduguard
>>> errdisable recovery interval <30-86400>
>>>
>>>
>>> On Wed, Jun 1, 2011 at 9:28 PM, Michael Kiefer <mjkiefer_at_gmail.com>wrote:
>>>
>>>> Thanks guys!
>>>>
>>>> On Wed, Jun 1, 2011 at 9:19 PM, Marko Milivojevic <markom_at_ipexpert.com
>>>>> wrote:
>>>>> Thanks Jason :-). The blog post Jason references is available here:
>>>>>
>>>>> http://blog.ipexpert.com/2010/12/06/bpdu-filter-and-bpdu-guard/
>>>>>
>>>>> Please note that I'm aware of some of the inaccuracies in that post
>>>>> (nicely pointed out in the comments) and I will be publishing the
>>>>> follow-up article soon. I don't want to silently correct this one, as
>>>>> that would be unfair.
>>>>>
>>>>> To be more precise - inaccuracies have to do _specifically_ with the
>>>>> difference of global vs. per-port portfast configuration, as well as
>>>>> clarifying the behavior more.
>>>>>
>>>>> --
>>>>> Marko Milivojevic - CCIE #18427
>>>>> Senior Technical Instructor - IPexpert
>>>>>
>>>>> FREE CCIE training: http://bit.ly/vLecture
>>>>>
>>>>> Mailto: markom_at_ipexpert.com
>>>>> Telephone: +1.810.326.1444
>>>>> Web: http://www.ipexpert.com/
>>>>>
>>>>> On Wed, Jun 1, 2011 at 18:14, Jason Boyers <jboyers_at_ipexpert.com>
>>>> wrote:
>>>>>> To add to what Marko said, the two commands you listed
>>>> ("spanning-tree
>>>>>> portfast bpdugaurd default" and "spanning-tree portfast bpdufilter
>>>>>> default") are not needed for what you are trying to accomplish.
>>>> Global
>>>>>> portfast (not interface portfast) will work as Marko described for
>>>> access
>>>>>> ports.
>>>>>>
>>>>>> Those commands you listed are to err-disable an access port if it is
>>>>> using
>>>>>> portfast and receives a BPDU (the first command) or to not send or
>>>>> receive
>>>>>> BPDUs if it is configured for portfast (the second command.) Marko
>>>> has
>>>>> an
>>>>>> excellent blog on the subject, including how these are different from
>>>> the
>>>>>> interface commands that look similar.
>>>>>>
>>>>>> Jason Boyers - CCIE #26024 (Wireless)
>>>>>> Technical Instructor - IPexpert, Inc.
>>>>>> Mailto: jboyers_at_ipexpert.com
>>>>>>
>>>>>> On Wed, Jun 1, 2011 at 8:39 PM, Marko Milivojevic <
>>>> markom_at_ipexpert.com>
>>>>>> wrote:
>>>>>>> The ports will not revert back to listening/learning from just
>>>>>>> receiving the BPDU. However, once a BPDU is received, the port will
>>>>>>> lose portfast status. If for whatever reason it goes into blocking
>>>>>>> mode (for example a better path to root is found), next time the
>>>> port
>>>>>>> goes out of blocking, it will go through listening and learning
>>>>>>> phases.
>>>>>>>
>>>>>>> And yes, portfast is almost as confusing as OSPF ;-)
>>>>>>>
>>>>>>> --
>>>>>>> Marko Milivojevic - CCIE #18427
>>>>>>> Senior Technical Instructor - IPexpert
>>>>>>>
>>>>>>> FREE CCIE training: http://bit.ly/vLecture
>>>>>>>
>>>>>>> Mailto: markom_at_ipexpert.com
>>>>>>> Telephone: +1.810.326.1444
>>>>>>> Web: http://www.ipexpert.com/
>>>>>>>
>>>>>>> On Wed, Jun 1, 2011 at 17:12, Michael Kiefer <mjkiefer_at_gmail.com>
>>>>> wrote:
>>>>>>>> I have two 3560 48 port TS switches running 12.2.55.SE1
>>>> IP-Services.
>>>>>>>> Both
>>>>>>>> switches are connected with port 13.
>>>>>>>>
>>>>>>>> My goal is to have the ports in portfast mode and jump back to
>>>>> standard
>>>>>>>> learning, listening, and forwarding state after detecting a BPDU.
>>>>>>>>
>>>>>>>> One vendor's material states that this can be accomplished by
>>>> doing
>>>>>>>> "spanning-tree portfast bpdugaurd default" globally and then
>>>> enabling
>>>>>>>> portfast on the interface. No dice, it goes straight to
>>>> err-disable.
>>>>>>>> Another vendor's material states to do "spanning-tree portfast
>>>>>>>> bpdufilter
>>>>>>>> default" globally and then do portfast on the interface. This
>>>> seems to
>>>>>>>> work
>>>>>>>> in the sense that it doesn't kill the port with err-disable. The
>>>>> problem
>>>>>>>> is
>>>>>>>> the debugs and show spanning-tree never show the listening and
>>>>> learning
>>>>>>>> states.
>>>>>>>>
>>>>>>>> SW1 and SW2 config:
>>>>>>>>
>>>>>>>> global:
>>>>>>>> spanning-tree mode pvst
>>>>>>>> spanning-tree portfast bpdufilter default
>>>>>>>> spanning-tree extend system-id
>>>>>>>>
>>>>>>>> under each port 13
>>>>>>>>
>>>>>>>> spanning-tree portfast
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Here's the debug output:
>>>>>>>>
>>>>>>>> *Mar B 1 00:29:27.907: Created spanning tree: VLAN0001 (5698310)
>>>>>>>> *Mar B 1 00:29:27.907: Setting spanning tree MAC address: VLAN0001
>>>>>>>> (5698310)
>>>>>>>> to 001e.14cc.1100
>>>>>>>> *Mar B 1 00:29:27.907: setting bridge id (which=3) prio 32769 prio
>>>> cfg
>>>>>>>> 32768
>>>>>>>> sysid 1 (on) id 8001.001e.14cc.1100
>>>>>>>> *Mar B 1 00:29:27.907: STP PVST: Assigned bridge address of
>>>>>>>> 001e.14cc.1100
>>>>>>>> for VLAN0001 [1] @ 5698310.
>>>>>>>> *Mar B 1 00:29:27.907: Enabling spanning tree optimized bpdu tx
>>>> for
>>>>>>>> VLAN0001
>>>>>>>> (5698310)
>>>>>>>> *Mar B 1 00:29:27.907: Starting spanning tree: VLAN0001 (5698310)
>>>>>>>> *Mar B 1 00:29:27.907: set portid: VLAN0001 Fa0/13: new port id
>>>> 800F
>>>>>>>> *Mar B 1 00:29:27.907: Created spanning tree port Fa0/13 (460217C)
>>>> for
>>>>>>>> tree
>>>>>>>> VLAN0001 (5698310)
>>>>>>>> *Mar B 1 00:29:27.907: B STP: PVST vlan 1 port Fa0/13 created, ext
>>>> id
>>>>>>>> 4B65F48
>>>>>>>> *Mar B 1 00:29:27.907: Enabling spanning tree port:
>>>> FastEthernet0/13
>>>>>>>> (460217C)
>>>>>>>> *Mar B 1 00:29:27.907: STP: VLAN0001 Fa0/13 ->jump to forwarding
>>>> from
>>>>>>>> blocking <-----------------------------
>>>>>>>> *Mar B 1 00:29:29.870: STP: VLAN0001 heard root
>>>> 32769-001b.d53e.b700
>>>>> on
>>>>>>>> Fa0/13
>>>>>>>> *Mar B 1 00:29:29.870: B B supersedes 32769-001e.14cc.1100
>>>>>>>> *Mar B 1 00:29:29.870: STP: VLAN0001 new root is 32769,
>>>> 001b.d53e.b700
>>>>>>>> on
>>>>>>>> port Fa0/13, cost 19
>>>>>>>> *Mar B 1 00:29:29.903: %LINK-3-UPDOWN: Interface FastEthernet0/13,
>>>>>>>> changed
>>>>>>>> state to up
>>>>>>>> *Mar B 1 00:29:29.903: Returning spanning tree port stats:
>>>>>>>> FastEthernet0/13
>>>>>>>> (460217C)
>>>>>>>> *Mar B 1 00:29:30.910: Returning spanning tree port stats:
>>>>>>>> FastEthernet0/13
>>>>>>>> (460217C)
>>>>>>>> *Mar B 1 00:29:30.910: %LINEPROTO-5-UPDOWN: Line protocol on
>>>> Interface
>>>>>>>> FastEthernet0/13, changed state to up
>>>>>>>> *Mar B 1 00:29:31.917: Returning spanning tree port stats:
>>>>>>>> FastEthernet0/13
>>>>>>>> (460217C)
>>>>>>>> *Mar B 1 00:29:32.923: Returning spanning tree port stats:
>>>>>>>> FastEthernet0/13
>>>>>>>> (460217C)
>>>>>>>> *Mar B 1 00:29:33.930: Returning spanning tree port stats:
>>>>>>>> FastEthernet0/13
>>>>>>>> (460217C)
>>>>>>>> *Mar B 1 00:29:34.937: Returning spanning tree port stats:
>>>>>>>> FastEthernet0/13
>>>>>>>> (460217C)
>>>>>>>> *Mar B 1 00:29:35.943: Returning spanning tree port stats:
>>>>>>>> FastEthernet0/13
>>>>>>>> (460217C)
>>>>>>>> *Mar B 1 00:29:36.950: Returning spanning tree port stats:
>>>>>>>> FastEthernet0/13
>>>>>>>> (460217C)
>>>>>>>> *Mar B 1 00:29:37.957: Returning spanning tree port stats:
>>>>>>>> FastEthernet0/13
>>>>>>>> (460217C)
>>>>>>>> *Mar B 1 00:30:09.926: STP: VLAN0001 we are the spanning tree root
>>>>>>>> *Mar B 1 00:30:09.926: STP: VLAN0001 heard root
>>>> 32769-001b.d53e.b700
>>>>> on
>>>>>>>> Fa0/13
>>>>>>>> *Mar B 1 00:30:09.926: B B supersedes 32769-001e.14cc.1100
>>>>>>>> *Mar B 1 00:30:09.926: STP: VLAN0001 new root is 32769,
>>>> 001b.d53e.b700
>>>>>>>> on
>>>>>>>> port Fa0/13, cost 19
>>>>>>>> *Mar B 1 00:30:09.926: STP: VLAN0001 sent Topology Change Notice
>>>> on
>>>>>>>> Fa0/13
>>>>>>>> *Mar B 1 00:30:37.960: Returning spanning tree port stats:
>>>>>>>> FastEthernet0/13
>>>>>>>> (460217C)
>>>>>>>> *Mar B 1 00:31:37.964: Returning spanning tree port stats:
>>>>>>>> FastEthernet0/13
>>>>>>>> (460217C)
>>>>>>>>
>>>>>>>> The debug clearly shows moving to forwarding from blocking. Then
>>>> BPDUs
>>>>>>>> are
>>>>>>>> heard and root port election/tcn takes place. At no time did the
>>>> port
>>>>> go
>>>>>>>> into learning and listening state. What am I missing? I can't seem
>>>> to
>>>>>>>> find
>>>>>>>> the right combination to accomplish the goal.
>>>>>>>>
>>>>>>>> TIA,
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>>
>>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>>
>>>>>>>>
>>>>> _______________________________________________________________________
>>>>>>>> Subscription information may be found at:
>>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>
>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>
>>>>>>>
>>>> _______________________________________________________________________
>>>>>>> Subscription information may be found at:
>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>> Blogs and organic groups at http://www.ccie.net
>>>>
>>>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
-- Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina Blogs and organic groups at http://www.ccie.netReceived on Thu Jun 02 2011 - 22:09:29 ART
This archive was generated by hypermail 2.2.0 : Fri Jul 01 2011 - 06:24:27 ART