I know that already. My point was that the way it is coded is sloppy.
There should be some way to differentiate between the features without
using wireshark. Maybe even in the help. Also, there should be a way to
enable the behavior seen with the global command on a per port basis and
vice versa.
From:
Farrukh Haroon <farrukhharoon_at_gmail.com>
To:
Keegan.Holley_at_sungard.com
Cc:
cristian.matei_at_datanets.ro, ALL From_NJ <all.from.nj_at_gmail.com>,
ccielab_at_groupstudy.com
Date:
11/06/2009 09:00 AM
Subject:
Re: bpdu-filter question (OT)
Sent by:
<nobody_at_groupstudy.com>
Actually there is a difference between PortFast and BPDU Filter enabled
globally, read this thread:
The way the BPDU Filter feature gets disabled on a port (when enabled
globally) after 'receiving' any BPDUs is similar to PortFast, but the way
BPDUs are 'sent' is *different*.
If you ever run wire shark on a port fast enabled port, you will find a
lot
of STP frames coming in, try it! Then do the same on a port with bpdu
filter
enabled :)
Regards
Farrukh
On Fri, Nov 6, 2009 at 4:32 PM, <Keegan.Holley_at_sungard.com> wrote:
> <rant>
>
> This is becoming very irritating. There are so many inconsistencies in
> IOS and people seem to take them as engineering challenges or gotcha's
for
> exams instead of what they are, sloppy development. They should
> standardize the feature so that the word bpdufilter does the same thing
in
> all places where it is available. I'm sick of having to come in here to
> debate just because some tiny insignificant feature is coded poorly,
does
> not match it's documentation or does not have any to begin with.
>
> </rant>
>
>
> 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/>
> >
> >
Received on Fri Nov 06 2009 - 14:19:05 ART
This archive was generated by hypermail 2.2.0 : Tue Dec 01 2009 - 06:36:28 ART