Re: STP BPDU filter / guard - a little bit inefficient?

Thank you all for taking time to respond to my question.

I will follow your tips and the most simple solution (without implementing port-security) will be to disable BPDU filter and to keep BPDU guard active. In this way, if somebody plug anything and result in a loop (like in my first e-mail) the switch will receive back its own BPDU and the guard will come into play putting port in err-disabled.

Cheers,
Calin

On Aug 31, 2011, at 7:15 PM, GAURAV MADAN wrote:

> You are correct Carlos . That is what even I mentioned .
>
> But believe me .. there are circumstances where we apply those .. Like when you are isolating 2 sites ..
>
> Thnx
> Gaurav Madan
>
> On Wed, Aug 31, 2011 at 9:33 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar> wrote:
> Gents,
> if I'm not mistaken, bpdufilter at port filters outbound and inbound.
> So far so good.
> But as it is filtering inbound, receiving a BPDU is worthless.
> It is just like disabling STP, meaning that you better don't get a loop through this port or else you'll get free tickets to nightmare II :)
> So do not do it :)
> -Carlos
>
> GAURAV MADAN @ 31/8/2011 12:28 -0300 dixit:
>
> I know most has been answered .. Just to add more
>
> BPDUFILTER : filters incoming as well as outgoing BPDUs .. its like no STP
> on that port . As soon as BPDU recieved ; it goes through normal STP cycle
> . Also keep in mind that BPDU-FILTER has no relation with portfast
> (sometimes this confuses )
>
> BPDUGUARD : Almost same as BPDUFILTER ; but with difference that as soon as
> BPDU is received on port ; port goes to err-disable state .(Remains in
> err-disable state as long as BPDU are received ..... after that depends on
> recovery mechanism)
>
> All that I talked of was on port basis .
>
> I hope this works !
>
> Thnx
> Gaurav Madan
> CCIE
>
> On Wed, Aug 31, 2011 at 7:23 PM, Sadiq Yakasai <sadiqtanko_at_gmail.com> wrote:
>
> If you enable BPDU filter globally, then your switch will revert to normal
> spanning-tree operation (ie going through the learning and listening and
> then forwarding states) when BPDU's are received inbound on the interface.
> This does not sound like its what you need in this situation. This would be
> a better solution:
>
> Enable BPDU filter at the interface level. This will cause the switch to
> drop all BPDU's inbound and outbound on the interface, period.
>
> BPDU guard acts only inbound on an interface (by err-disabling the
> interface, as pointed out by Shiran), while BPDU filter works in both
> directions. Now, don't forget the behavior for these features works
> slightly
> differently when enabled globally versus at the interface level.
>
> HTH,
> Sadiq
>
> On Wed, Aug 31, 2011 at 2:28 PM, Calin C. <calin_at_engineer.com> wrote:
>
> Thanks shiran for your reply!
>
> I will test your suggestion in a lab.
>
> Cheers,
> Calin
>
> ----- Original Message -----
> From: shiran guez
> Sent: 08/31/11 03:13 PM
> To: Calin C.
> Subject: Re: STP BPDU filter / guard - a little bit inefficient?
>
> 1. If you have a switch that you are not sure if someone is going to
> connect
> a hub and cause problems, I would suggest using the spanning-tree
> bpduguard
> enable
>
> as with that option the switch is going to keep transmitting spanning
> tree
> bpdu and If you will connect a loop using a hub the switch will get his
> own
> bpdu and will go into err-disable.
>
> Note that if you use the bpdu filter it will prevent also the switch
> from transmitting bpdu out on that port (where it is enabled) and that
> may
> cause loop so I would suggest to avoid using that in an
> un-trusted environment
>
> 2. as for multi users I will suggest you use the port security feature
> to
> allow a max of one MAC or 2 (in some cases)
> *
> *
> *Hope that help*
> *
> *
> *:-)*
> *
> *
>
> On Wed, Aug 31, 2011 at 3:45 PM, Calin C. <calin_at_engineer.com> wrote:
>
> Hello all,
>
> My problem is not directly related to CCIE exam, but rather to CCIE
> topics.
> I have an issue and I don't know what solution to propose, so maybe
> you
> can
> help me a little bit.
>
> 1. Let's assume that we have a L2 switch, with one or two uplinks,
> with
> BPDU guard / filter enable and also portfast. Everything is running
> fine.
> 2. Somebody come and connected to one of the edge ports of L2 a hub.
> L2
> switch will start to send BPDUs, but since at the other end there is
> no
> switch, but a hub, it will get nothing back (in terms of BPDU
> packets)
> and
> assume that an end device (e.g. PC) is connected there. Still,
> everything is
> running fine.
>
> 3. Another (smart) somebody come and plug a loop in the hub (one
> cable;
> both ends in the same hub). Since the port is already UP on the L2
> port, no
> BPDU flow through there, the BDPU guard / filter will not react, but
> the hub
> will loop all other packets and send them to L2 switch. From this
> point
> a
> little bit of disaster in the spanning-tree environment.
>
> I have no idea how to stop this issue from happening, beside adding
> there a
> sign on L2 switch with "you plug something here and you die" or
> enabling
> port-security (which let's say I don't want for certain personal
> reasons).
> Please let me know if I miss something in my problem (from logical
> point of
> view) and if you have any possible solution to my problem.
>
> Thanks for your time!
>
> Cheers,
> Calin
>
>
> Blogs and organic groups at http://www.ccie.net
>
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
>
> --
> Shiran Guez
> MCSE CCNP NCE1 JNCIA-ENT JNCIS-ENT CCIE #20572
> http://cciep3.blogspot.com
> http://www.linkedin.com/in/cciep3
> http://twitter.com/cciep3
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
>
> --
> CCIEx2 (R&S|Sec) #19963
>
>
> 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
>
>
>
>
>
>
>
>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina

Blogs and organic groups at http://www.ccie.net
Received on Wed Aug 31 2011 - 19:55:23 ART