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

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<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://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<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<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 <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 - 22:45:02 ART