nevermind...
From:
Ramanpreet Singh <sikandar.raman_at_gmail.com>
To:
Keegan.Holley_at_sungard.com
Cc:
ALL From_NJ <all.from.nj_at_gmail.com>, ccielab_at_groupstudy.com,
cristian.matei_at_datanets.ro, Farrukh Haroon <farrukhharoon_at_gmail.com>,
nobody_at_groupstudy.com
Date:
11/08/2009 04:53 PM
Subject:
Re: bpdu-filter question (OT)
Sent by:
<nobody_at_groupstudy.com>
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/>
> >> >
> >> >
> >
Received on Sun Nov 08 2009 - 19:14:02 ART
This archive was generated by hypermail 2.2.0 : Tue Dec 01 2009 - 06:36:28 ART