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

From: Marko Milivojevic <markom_at_ipexpert.com>
Date: Wed, 31 Aug 2011 10:25:19 -0700

When enabled globally, bpdufilter does not filter inbound. Enabled on
the port - it does. You are, of course, correct that having both
filter and the guard on the port defeats the purpose of the guard -
filter will be processed before BPDU hits the guard.

--
Marko Milivojevic - CCIE #18427
Senior Technical Instructor - IPexpert
FREE CCIE training: http://bit.ly/vLecture
Mailto: markom_at_ipexpert.com
Telephone: +1.810.326.1444
Web: http://www.ipexpert.com/
On Wed, Aug 31, 2011 at 09:03, 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
>> . B 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
>> B 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 B <tron_at_huapi.ba.ar> B LW7 EQI B Argentina
>
>
> 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 Wed Aug 31 2011 - 10:25:19 ART

This archive was generated by hypermail 2.2.0 : Thu Sep 01 2011 - 06:05:56 ART