is that necessary to apply BPDU Guard to Server Farm Switch ? or compulsory must implement BPDU Guard to Server Farm Switch ?
your reply will be highly appreciated.
Your server farm switch is generally going to be isolated from your user environment; the only people who could connect a switch to the server farm switch are going to have access to your computer room anyway.
BPDU Guard just prevents rogue switches from being connected to user ports; it's a method for keeping your LAN safe from users who might accidentally cause spanning-tree recalculations or damage to your VLAN configurations by connecting a mis-configured switch to the network. The difference between your server farm switches and your user access switches is that the users have direct access to the switchports on the user access switches.
So long as your server support guys know not to connect any switches to the server farm switches, then BPDU Guard shouldn't be necessary.
Hope this helps!
I would. It's not going to cost you anything and after all, no one should be plugging switches into your server access ports right? While an admin is inheritantly more trustworthy then a user they can make mistakes. You don't want a tired admin accidentally looping up your network. I would take a look at the cisco-desktop SmartPort macro and modify it to suit your env.
I would disagree - BPDU Guard is, after all, another process to run on your switches. Disabling the process frees up resources on your switch, as it removes the need to check each packet to see if it is a BPDU.
Fair enough, it is possible for admins to make mistakes too (I do, frequently - my piece de resistance being accidentally tripping out a UPS that was powering one of our two core 6509s, resulting in a massive spanning tree recalc on all our campus VLANs, temporary loss of connectivity for all our users, and an interruption of service for our IP phones - over 1000 of them) - but I think it's better to minimize your use of resources.
BPDU Guard should definitely be on your user access level switches, but if you can get away without it on your server switches, then you probably should.
I've not seen any documentation stating that there's a performance penalty for implementing BPDU Guard. Do you have evidence to the contrary? The switch, rather spanning tree, is going to send, receive and subsequently process BPDUs regardless of whether the feature is enabled. All BPDU guard does is tell the switch what to do in the event spanning tree hears a bpdu on an interface that it shouldn't.
Plan for the worst, hope for the best.
Yep, BPDU guard is just a test executed on the receive path of the BPDU. Whether you enable the feature or not, you're going to do this test, so there is no performance benefit in not enabling BPDU guard.
Sorry, I stand corrected - I had assumed BPDU Guard was an extra process for the switch to run.
Thanks for the info!
so, which means in the server farm switch not necessary to implement BPDU Guard ? is that what u mean ?
I'm saying you should consider it if you want to avoid an accidental loop on one of your server access ports. What both Francois and I are saying is that it's not going to cost you anything to do so.
I see BPDU guard as a feature enforcing a security policy rather than a loop prevention measure.
You enable BPDU guard on a edge port, where you don't expect a bridge to be connected. If you receive BPDUs on this port, there is an inconsistency in your network. You have several options:
-1- you are not too concerned about this and let STP run on this port. Just do nothing: STP prevents loops. Peering with an unknown switch can be risky however, as it may impact the topology of your network.
-2- you want to privilege connectivity and are ready to let STP run on this port as long as it's not messing up with the topology of your core: enabled root guard.
-3- you are rather conservative and you prefer to bring this port down: enable bpdu guard.
Note that it's not because you have enable bpdu guard that you are protected against loop. STP does that. If the device that is connected to this port is hostile, it can introduce a loop without sending bpdus anyway.
However, in term of security, bpduguard is currently the only feature that protects your switch against a denial of service attack. Bpdus are sent to the processor, and a port receiving a high rate of bpdus will have an impact on the CPU. Bpdu guard protects against that by bringing this particular link down.
So I would really recommend enabling bpdu guard (and probably some form of port security) on an edge port accessible to end users. In a confined and secured data center environment (where you expect errors and not attacks), it's probably not that critical and depends on your security strategy...