RE: bpdu-filter question

Yes, this is what I have seen as well but it makes no sense. bpdufilter
is supposed to filter bpdu's no matter what. That's the point of the
feature. The behavior with portfast bpdufilter enabled globally is
exactly the same as having only portfast enabled alone. Also, none of the
ports even those connected to hosts actually list bpdufilter in the show
spann detail command. Based on this I think that the bpdufilter portion
has no effect when enabled globally.

From:
Cristian Matei <cristian.matei_at_datanets.ro>
To:
"'ALL From_NJ'" <all.from.nj_at_gmail.com>, <Keegan.Holley_at_sungard.com>
Cc:
<ccielab_at_groupstudy.com>
Date:
11/06/2009 02:29 AM
Subject:
RE: bpdu-filter question

Hi Andrew,

                 It's almost like that.... So ( I did not test it but this
is the way
it should WORK):

                                 1) When you configure "bpdufilter" at the
GLOBAL level, it
will get applied to all portfast enabled ports(be it trunk or access; you
can also make a trunk portfast with "spanning-tree portfast trunk" at the
interface level); being globally applied, the switch will still send a
certain amount of BPDUs and if doesn't receive any it filters sending
BPDUs
out; as soon as it receives a BPDU at that port it loses the BPDUFILTER
state and starts negotiating the STP state.
                                 2) When you configure "bpdufilter" at the
INTERFACE level,
it's obviously where it's applied :) (to that port, no matter being it
manually access,trunk or negotiating); at the interface level it filters
BPDUs in both ways (in and out) and it NEVER starts negotiating the STP
state if it sees BPDUs.
                                 3) When you configure "bpduguard" at the
GLOBAL level, it
will get applied to all portfast enabled ports(be it trunk or access; you
can also make a trunk portfast with "spanning-tree portfast trunk" at the
interface level); if BPDUs are received the port gets into err-disabled
                                 4) When you configure "bpduguard" at the
INTERFACE level, it
gets applied to that port (no matter the state of the port....); if BPDUs
are received the port gets into err-disabled

So to summarize things "bpduguard" has the SAME behavior (if enabled
globally or at the interface level); "bpdufilter" has a DIFFERENT behavior
(if enabled globally or at the interface level).

Another GOOD to know: NEVER configure BPDUGUARD and BPDUFILTER at the
interface level; BPDUFILTER will filter incoming BPDUs so the BPDUGUARD
will
not trigger; you can see it as a order of operation thing; different story
if you implement BPDUFILTER globally and BPDUGUARD at the interface level
(here GUARD will kick in and put the port into err-disabled-------because
of
the way FILTER works here, see bullet 1).

Also, I disagree with the saying: If BPDUFILTER is enabled at the
interface
level STP is disabled........Cisco uses it as well; the port STILL has an
STP port state, it just doesn't run BPDUs; different thing to actually
disabling the STP at the VLAN level.

Regards,
Cristian MATEI.

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
ALL
From_NJ
Sent: Friday, November 06, 2009 5:18 AM
To: Keegan.Holley_at_sungard.com
Cc: ccielab_at_groupstudy.com
Subject: 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/1

2
.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/configuratio
n
/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/lis
t
/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