Re: bpdu-filter question

I tried this a few times. I guess I just wanted to know if this was the
way it was implemented across the board or if it varies between
platforms/models. I also noticed that even though it doesn't list
bpdufilter in the output of the spantree detail command you can see that
the sent bpdu counters do not increment. So I guess there is a difference
in behavior with the default command. Just a little annoyed with how it
is implemented. I think I'm going to start and IOS annoyances site when I
retire.

From:
ALL From_NJ <all.from.nj_at_gmail.com>
To:
Keegan.Holley_at_sungard.com
Cc:
cristian.matei_at_datanets.ro, ccielab_at_groupstudy.com
Date:
11/06/2009 09:54 AM
Subject:
Re: bpdu-filter question
Sent by:
<nobody_at_groupstudy.com>

Yep agreed, although I do not see where the disagreement is with any of
our
emails. Hummm ... I think we are saying the same thing here ... my
initial
intent was to provide some thoughts on lab testing and not simple answers.
No worries either way, I think we are all in step here.

(My attempt to write a bpdufilter question)

 "port g0/13 will not have any switches connected to it. Port g0/13
should
not send or receive any bpdus regardless of whether or not another switch
is
plugged into it. You cannot use the command 'no spanning-tree' and
spanning
tree must see the port as in forwarding mode"

Here is the doc reference in case anyone wants to review (watch the ugly
word wrap). It is good reading IMO ...

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_44_se/configuration/guide/swstpopt.html#wp1046220

Keegan, I agree that this command does not appear to do that much ...
however, with portfast only enabled (no bpdufilter), the port will still
send bpdus in portfast mode... so, the way to also stop this behavior is
to
use the command 'bpdufilter'.

A simple lab test is w/ two switches and with two links between them.

On one switch, SW1, configure the first port as 'no switchport', and make
the second link a trunk and whatever protocol you wish.

On the other switch, SW2, keep both interfaces as default and see if the
one
of these becomes a trunk link. On this SW2, you can practice any variety
of
configs w/ spanning tree. Fun stuff, and also easy to see these two
switches negotiate protocols etc ....

HTH,

Andrew

On Fri, Nov 6, 2009 at 8:22 AM, <Keegan.Holley_at_sungard.com> wrote:

>
> 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
<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/>
> >
> >
Received on Fri Nov 06 2009 - 14:28:10 ART