Re: bpdu-filter question (OT)

Two things. Point-to-point vpls kind of defeats the purpose, no? And
whoever said I'm not in a service provider network?

From:
Ramanpreet Singh <sikandar.raman_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, Farrukh Haroon <farrukhharoon_at_gmail.com>,
nobody_at_groupstudy.com
Date:
11/07/2009 12:15 PM
Subject:
Re: bpdu-filter question (OT)

Keegan,

Just another prespective

In service provider environment where we provide pure Layer-2 Ethernet
pipe for a point to point VPLS circuit, we normally like to disable
BPDU's sending/receiving from the customer on customer-facing ports.
For us interface-level BPDU filter really works.We don't require
global settings for this feature.

Its debatable whether IOS is sloppy or this was a feature request. One
thing to note is that whet you require on Enterprise environment might
not be desired in SP environment. To have standards same on IOS across
the board, I feel that Cisco introduced two different features.

You can always talk with TAC and request for feature request through
your cisco SE and discuss on what you need/require, they might be able
to answer you in better fashion.

Thanks,
-Raman

On Sat, Nov 7, 2009 at 5:55 AM, <Keegan.Holley_at_sungard.com> wrote:
> Yea but I think most people fail to realize is that the stuff we discuss
> here is just the user interface for IOS. They can change that pretty
> easily. I mean it's not like I want them to redesign spanning tree.
 Just
> to make the configuration a little bit more intuitive. I mean they
could
> have written it in latin if they want. It's just an interface.
>
>
>
> From:
> Cristian Matei <cristian.matei_at_datanets.ro>
> To:
> <Keegan.Holley_at_sungard.com>, "'Farrukh Haroon'"
<farrukhharoon_at_gmail.com>
> Cc:
> "'ALL From_NJ'" <all.from.nj_at_gmail.com>, <ccielab_at_groupstudy.com>,
> <nobody_at_groupstudy.com>
> Date:
> 11/06/2009 03:35 PM
> Subject:
> RE: bpdu-filter question (OT)
>
>
>
> Hi,
>
> Well I will not call it sloppy; just 2 ways of doing a thing and having
2
> different results :)
> Basically the way I see it is:
> -if you REALLY want to filter out BPDUs
> (in and out) and
> don't care about the risk of creating some loops enabled it at the port
> level
> -if you actually don't want to send
BPDUs
> to hosts, but
> protect yourself from possible loops, if someone plugs in a switch to
that
> port, configure it at the global level.
>
>
> Regards,
> Cristian.
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> Keegan.Holley_at_sungard.com
> Sent: Friday, November 06, 2009 9:19 PM
> To: Farrukh Haroon
> Cc: ALL From_NJ; ccielab_at_groupstudy.com; cristian.matei_at_datanets.ro;
> nobody_at_groupstudy.com
> Subject: Re: bpdu-filter question (OT)
>
> 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:
>
>
http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20

>
>
Infrastructure&topic=LAN%2C%20Switching%20and%20Routing&topicID=.ee71a04&fro
> mOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cd42a37
>
>
> 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
>
> _______________________________________________________________________
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sun Nov 08 2009 - 12:20:41 ART