Re: Now I'm confused...

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
Received on Thu Jun 02 2011 - 16:18:31 ART