Re: bpdu-filter question

Hey,

I hope all is well with you. I have labbed this up tonight, and here is
what I see on my 3560s. Do please let me know if this is different from
what you see.

1) I have configured portfast and set bpdufilter as default for when
portfast is used. When the port is a trunk link, these commands have no
affect since portfast has no effect on a trunk link. I think this is
expected.

Command: "spanning-tree portfast bpdufilter default"

2) I have then configured portfast and set bpduguard as default for when
portfast is used. When the port is a trunk link, a bpdu is detected and the
port is shutdown due to bpduguard. This is expected, and this is a great
config option. Nice!!!

3) When configuring a access port or trunk link with bpdufilter, this causes
the switch to NOT send or receive bpdus (effectively disabling STP without
using the command 'no spanning-tree'). This is expected behavior ...
interesting thing is, that when the switch does not receive bpdus ... it
thinks it is the root!

True to life ... when we do not communicate with others (trunk links) we
somehow think we are the root! Those of us who are married or have kids,
know what it is like to receive a far superior bpdu and be humbled at
times. lol ...

In your first example, the switch thinks it is the root, but does not send
or receive bpdus due to bdpufilter being configured ... my guess is that you
configured this at the interface via the 'spanning bpdufilter enable'
command.

In your second example, the switch knows it is not the root due to sending
and receiving bpdus.

Not sure I fully understand how you labbed this, however ... do you see
something similar in your tests? Also, you are using a Cat4K in the lab?
What is in production?

Have a great night,

Andrew Lee Lissitz

On Thu, Nov 5, 2009 at 10:35 AM, <Keegan.Holley_at_sungard.com> wrote:

>
> Yea, the problem is the docs from the product I'm working on are incorrect
> and the docs for the 4000 series (yuk) are correct. At least on the switch
> I have here bpdufilter pretty much disables spanning tree communication per
> port regardless of whether the upstream switch is sending bpdu's. So it's
> not good for user ports. As soon as someone tries to "double" their
> bandwidth by plugging into a second wall jack their VLAN will melt down.
> Part of the problem is I think I already know the answer. I just wanted
to
> see if it was just for the platform I'm on (despite it's docs) or does it
> differ across platforms. The switch in question is kind of in a lab setup
> and I need internet from the production network but I don't want to affect
> spanning tree there so I have had bpdu filter enabled for almost a year.
It
> believes it is the root bridge and the bpdu counters are frozen (good
> command btw I always forget that one) both of which change when I disable
> bpdufilter. I also tried with portfast and bpdufilter on by default and
the
> port was the same. Not sure if it matters but the switch is running rpvst.
>
>
> production#sh spanning-tree interface g0/3 detail
> Port 3 (GigabitEthernet0/3) of VLAN0001 is designated forwarding
> Port path cost 19, Port priority 128, Port Identifier 128.3.
> Designated root has priority 32769, address 000a.412c.e400
> Designated bridge has priority 32769, address 000a.412c.e400
> 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
> BPDU: sent 4, received 17
> production#
>
>
> No bpdufilter:
>
> production(config-if)#do sh spann int g0/3 detail
> Port 3 (GigabitEthernet0/3) of VLAN0001 is root forwarding
> Port path cost 19, Port priority 128, Port Identifier 128.3.
> Designated root has priority 8192, address 0011.8842.392a
> Designated bridge has priority 8192, address 0011.8842.392a
> Designated port id is 128.325, designated path cost 0
> Timers: message age 16, forward delay 0, hold 0
> Number of transitions to forwarding state: 1
> Link type is point-to-point by default
> BPDU: sent 8, received 21
> production(config-if)#
>
>
> Keegan Holley b* Network Engineer I b* SunGard Availability Services b*
401
> North Broad St. Philadelphia, PA 19108 b* (215) 446-1242 b* *
> keegan.holley_at_sungard.com* <keegan.holley_at_sungard.com> Keeping People and
> Information ConnectedB. b*
*http://www.availability.sungard.com/*<http://availability.sungard.com/>
>
> P *Think before you print*
>
>
> CONFIDENTIALITY: This e-mail (including any attachments) may contain
> confidential, proprietary and privileged information, and unauthorized
> disclosure or use is prohibited. If you received this e-mail in error,
> please notify the sender and delete this e-mail from your system.
>
>
> From: ALL From_NJ <all.from.nj_at_gmail.com> To: Keegan.Holley_at_sungard.com
> Cc: ccielab_at_groupstudy.com Date: 11/04/2009 11:05 PM Subject: Re:
> bpdu-filter question
> ------------------------------
>
>
>
> For documentation, I would suggest to stay with the docs related to the
> product you are working on. There are some differences.
>
> i hope you do not mind this response, but ...
>
> I would suggest to do the lab test another time; it would be a pity for me
> to spit out the answer before asking you to check this test again. A good
> command (just found tonight when labbing this with you) is this command:
>
> "show spanning-tree interface g0/20 detail"
>
> Look under this command for BPDUs sent and received. I actually found this
> question to be interesting because it challenged me in my understanding of
> STP as well.
>
> Which switch sends and which switch will respond to BPDUs? Keep this in
> mind when you do this test again and you are watching the bpdu counters.
>
> Also, try the bpdufilter command with and without bdpuguard. I believe
> this will also show some interesting behavior.
>
> In my lab, I have one switch configured with trunking and the other side
> configured for dynamic desirable. If you feel so inclined, try this again
> and of course ask questions! We all learn from you ... also, there are
some
> pretty smart folks on this list (not me ... I am a bear of little brain)
>
> Take care and HTH,
>
> Andrew
>
>
>
> On Wed, Nov 4, 2009 at 10:23 PM,
<*Keegan.Holley_at_sungard.com*<Keegan.Holley_at_sungard.com>>
> wrote:
> GS,
>
> I recently watched a recorded bootcamp that stated that bpdu filter will
> revert back to the default spanning tree behavior if it sees a bpdu. They
> also say should be enabled on port fast ports to avoid loops. I seem to
> have found conflicting documentation on *cisco.com* <http://cisco.com/>one
page states that the
> bpdu's are blocked constantly and the other pretty much agrees with the
> vendor. I tried this on a 3550 running 12.2(40) see2 and bpdu's were
> blocked no matter what. Did this change across code releases/platforms or
> are they just wrong?
>
>
> Heads:*
> **
>
http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12
.2_44_se/configuration/guide/swstpopt.html#wp1033638
>
*<http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/
12.2_44_se/configuration/guide/swstpopt.html#wp1033638>
>
> tails:*
> **
>
http://www.cisco.com/en/US/docs/switches/lan/catalyst4000/7.4/configuration/g
uide/stp_enha.html
>
*<http://www.cisco.com/en/US/docs/switches/lan/catalyst4000/7.4/configuration
/guide/stp_enha.html>
>
>
> Blogs and organic groups at *http://www.ccie.net* <http://www.ccie.net/>
>
> _______________________________________________________________________
> Subscription information may be found at:*
>
**http://www.groupstudy.com/list/CCIELab.html*<http://www.groupstudy.com/list
/CCIELab.html>
>
>
>
>
>
>
>
>
>
>
> --
> Andrew Lee Lissitz *
> **all.from.nj_at_gmail.com* <all.from.nj_at_gmail.com>
>
>

--
Andrew Lee Lissitz
all.from.nj_at_gmail.com
Blogs and organic groups at http://www.ccie.net