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/>
> >
> > _______________________________________________________________________
> > 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
>
> _______________________________________________________________________
> 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 Fri Nov 06 2009 - 16:56:38 ART
This archive was generated by hypermail 2.2.0 : Tue Dec 01 2009 - 06:36:28 ART