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.netReceived 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