Re: bpdu-filter question (OT)

For customer its a transparent L2 pipe, customer doesn't care if you are
using VPLS or a plain vanilla Spanning tree topology. The idea is even if
your customer start with a point to point circuit first, your core should be
scalable enough, if later the requirement changes to multipoint.

HTH
-Raman

On Sun, Nov 8, 2009 at 11:17 AM, <Keegan.Holley_at_sungard.com> wrote:

>
> Gosh, I know we're all network guys here but think a little bit from the
> programmers perspective. The "IOS" we all know and love is really just a
> user interface for something infinitely more complicated. Since the whole
> thing is text based they could have implemented the user interface portion
> is such a way that the configuration is a little less cumbersome, with out
> changing any of the features. I'm not saying that bpdufilter that does or
> does not turn itself off is a good/bad thing. I just want it to make sense
> on the CLI after I learn about the feature and I want the documentation to
> actually match what I see in the switch and in the lab. It's really not
> that complicated.
>
>
>
> 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<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<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 - 15:50:18 ART