cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
30655
Views
40
Helpful
15
Replies

Enable BPDUGuard on Spanning-tree Portfast Trunk Port: Yes or No?

ansonleekh
Level 1
Level 1

Hello to all the Cisco Experts,

 

I have been searching around to get a confirmed answer as per my subject, but yet unable to come into any conclusion that could help me.

This is all started when I configured the switchport configuration for my ESXi Server which is a dot1q trunk port. The reference will be as below URL:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006628

 

The configuration of the switchport will be as below:

interface GigabitEthernet1/0/1
 description ESXi
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 11,15
 switchport mode trunk
 spanning-tree portfast trunk
end

 

The catch is, I had the bpduguard enabled on the global level in my switch = spanning-tree portfast bpduguard default.

This will enable the bpduguard on the trunk port above due to the switchport is in portfast (the command: spanning-tree portfast trunk).

 

Some of the guys in this forum mentioned that it is not recommended to have bpduguard on trunk port and some mentioned it is okay to have this.

So, what do you all think on this? Any real life experience dealing with this kind of situtation that can be shared to us over here?

 

Thank you in advance.

 

15 Replies 15

Leo Laohoo
Hall of Fame
Hall of Fame

Only a mentally deranged lunatic would configure STP on a Trunk link.  And you'd be equally nuts to enable BPDU Guard on a Trunk link.  

 

If you want to ask WHY, then you need to understand the concept and function of BPDU Guard as well as STP on a Trunk port(s).

Hi Leo,

Well, I guess I'm about to become labeled as a mentally deranged lunatic :) But hey, I am a uni teacher so I have an excuse for that :)

Anyway, you probably meant to say that it would be nuts to configure STP PortFast on a trunk, right? I do not suppose you doubt the reason of running STP itself on trunks in general.

Well, there have been situations when I felt perfectly fine enabling it, such as trunks to router-on-stick or to a server running several virtual machines. I knew the devices on the other end of the trunk would never perform bridging/switching and would never run STP. In effect, these devices were end devices just like ordinary PCs on access ports. We always do a certain leap of faith when we configure access ports as PortFast ports because under circumstances, a switch or a physical cable loop can be connected there and cause problems. Yet we use the concept of edge ports, and in RSTP/MSTP, we would suffer hard without it. The reluctance of activating PortFast on trunk ports is understandable and I feel a certain kind of hesitation myself but that is caused by the plain fact that trunk links usually go to other switches, and we are aware of the risks. However, if the trunks are provably connected to non-switching devices then they are just as good and eligible for PortFast as access ports.

Activating a BPDU Guard on a trunk would be nuts but not destructively so. It would be nuts on inter-switch trunk link because obviously, it would be putting the link down all the time. At the same time, it would never introduce a switching loop. On trunks that are configured with PortFast, however, I see no reason not to run it. It was a pretty bold move to configure a trunk port as a PortFast port so why not protect it against inadvertent or malicious conditions by the BPDU Guard?

What would be your thoughts on this?

Best regards,
Peter

Activating a BPDU Guard on a trunk would be nuts but not destructively so. It would be nuts on inter-switch trunk link because obviously, it would be putting the link down all the time. At the same time, it would never introduce a switching loop. 

I agree with you, hence my initial response.  BPDU Guard on an inter-switch link will forever put the link down.  (Let's not dwell on my pet peeve about auto-recovery due to BDPU Guard.)  I see no benefit but mischief when you enable BPDU Guard on an inter-switch link.   

On trunks that are configured with PortFast, however, I see no reason not to run it. It was a pretty bold move to configure a trunk port as a PortFast port so why not protect it against inadvertent or malicious conditions by the BPDU Guard?

Bold move indeed.  So what is the reaction of the port if you do happen to enable portfast and BPDU guard on an inter-switch link?  Wouldn't the two be a "Jekyll & Hyde", wouldn't it?  

Hi Leo,

First of all, I would never, ever, consider any comment of yours as being offensive so don't worry, none taken. :)

Enabling portfast on a trunk is so "yesterday", in my opinion.  If a trunk port(s) or an etherchannel is configured correctly, there's a significant chance portfast is irrelevant.  The speed to get the ports to go from down to passing traffic is really boils down to one or two seconds.

Perhaps this is at the core of our different views. To my best knowledge, without the PortFast, a trunk - be it a single port or an EtherChannel - will become forwarding 30 seconds after entering the up/up state, not less. This is valid for STP, RSTP, and MSTP. In addition, if a new VLAN is created or added to the list of enabled VLANs on the trunk, it may take additional 30 seconds for that VLAN to become operational (forwarding) on that trunk. There is nothing besides PortFast and Proposal/Agreement that can cut down this time: the STP must go over the Listening-Learning-Forwarding sequence, and RSTP/MSTP must go through the Discarding-Learning-Forwarding sequence. The "one or two seconds" you have mentioned is perhaps the combined delay incurred by autonegotiation, LACP/PAgP, and DTP, but STP will take its own time and will not be deterred by any of these mechanisms.

I see no benefit but mischief when you enable BPDU Guard on an inter-switch link.   

Absolutely agree. That is why it doesn't make any sense to put a BPDU Guard on an inter-switch link, and I have never suggested doing that. The original post, however, deals with enabling PortFast on a trunk link that does not go to another switch but rather connects to an ESXi server on which, obviously, different virtual machines are bridged onto different VLANs.

So what is the reaction of the port if you do happen to enable portfast and BPDU guard on an inter-switch link?  Wouldn't the two be a "Jekyll & Hyde", wouldn't it?

It would be just the same as enabling PortFast and BPDU Guard on an access port that happens to be connected to another switch. Upon link-up, the port would become forwarding immediately, and after receiving a BPDU, it would be shot down to err-disabled. The fact the port is an access port or a trunk port makes no difference here. Just as before, I stress that this kind of configuration simply isn't meant to be used on inter-switch links. However, on trunks connected directly to routers, servers, autonomous APs supporting several SSIDs mapped to different VLANs, even to IP phones (remember the mini-trunk config used on old switches on which the switchport voice vlan command only instructed CDP to advertise the voice VLAN but did not cause the port to accept tagged frames in the voice VLAN so it had to be configured as a trunk?) - in all these situations, the PortFast can be beneficial. The BPDU Guard is a natural protective companion to the PortFast - wherever PortFast is eligible to be configured, the BPDU Guard is a natural additional protection to be activated as well.

But given the complexity of interconnection of different switches to various stuff going around, we're happy with leaving portfast on a trunk port disabled.

No argument here - but again, this is about trunks between switches on which I would never suggest using the PortFast or the BPDU Guard. The original post is talking about trunks to end hosts (i.e. edge trunk ports if we extend the terminology a little).

Best regards,
Peter

The original post is talking about trunks to end hosts (i.e. edge trunk ports if we extend the terminology a little).

LOL.  But I didn't read the post properly, hence, I've gone off tangent (or off to the woods and got lost).

Well, I guess I'm about to become labeled as a mentally deranged lunatic :) But hey, I am a uni teacher so I have an excuse for that :)

No offense to you or the academics, Peter.  But you're one of a few who enable this because you want to show your students. laugh

Anyway, you probably meant to say that it would be nuts to configure STP PortFast on a trunk, right?

You're exactly right.  Enabling portfast on a trunk is so "yesterday", in my opinion.  If a trunk port(s) or an etherchannel is configured correctly, there's a significant chance portfast is irrelevant.  The speed to get the ports to go from down to passing traffic is really boils down to one or two seconds.  Unfortunately, I didn't have the time to "lab" this so I don't have the facts and figures to back my claim up.  Happy to see you shoot it down (again, no offense to your or academics).  

Well, there have been situations when I felt perfectly fine enabling it, such as trunks to router-on-stick or to a server running several virtual machines. I knew the devices on the other end of the trunk would never perform bridging/switching and would never run STP. In effect, these devices were end devices just like ordinary PCs on access ports. We always do a certain leap of faith when we configure access ports as PortFast ports because under circumstances, a switch or a physical cable loop can be connected there and cause problems. Yet we use the concept of edge ports, and in RSTP/MSTP, we would suffer hard without it. The reluctance of activating PortFast on trunk ports is understandable and I feel a certain kind of hesitation myself but that is caused by the plain fact that trunk links usually go to other switches, and we are aware of the risks. However, if the trunks are provably connected to non-switching devices then they are just as good and eligible for PortFast as access ports.

What you've mentioned above, I can't argue.  Unfortunately for me, you've raised a serious question about my philosophy about portfast on a trunk port which I've seen before.   Here's the funny thing, though.  We've got ESX/VMware stuff.  But we've never heard them ask for this feature before.   But you know something?  I wrote my response in haste.  I should've stated "STP Portfast and/or BPDU Guard on an inter-switch link(s) is a bad idea".  

 

I mean it's OK to lab it.  But given the complexity of interconnection of different switches to various stuff going around, we're happy with leaving portfast on a trunk port disabled.  

 

PS:  Thanks for your post, Peter.  Pretty strong (and interesting) points you've raised.  

 

Hi All,

Thank you to you all for all the interesting discussion here. Of course, I am still mentally stable for not to configure the "spanning-tree portfast trunk" on the trunk port of the inter-switch. I guess it will be a good practice to read the whole post in detail before starts to press the "Reply", just my 2 cents.

 

There are many ESXi in my environment for customers usage that have trunk port configured still without "spanning-tree portfast trunk", which means that there are many virtual servers behind every ESXi. There will be a incoming task (which is unavoidable) which I will need to change the current spanning-tree root bridge to another switch. This of course will trigger the whole spanning-tree election process and I do not intend to wait 30 seconds for the ESXi trunk port to become forwarding state. This will create "down time" for the VMs behind all the ESXi and customers will not willing to wait this 30 seconds.

 

In order to reduce this time, I am thinking to configure "spanning-tree portfast trunk" on the trunk port that connected to ESXi. As for the BPDUguard that comes into the picture, was due to the global configuration that I had, which it will be enabled by default if the port is in portfast.

 

I am still hesitating to get the "spanning-tree portfast trunk" configuration set on the trunk port that connected to ESXi.

 

Regards,

Anson

I know that this post is pretty old but I just wanted to mention that nowadays, I see a lot of my customers using portfast on trunks to their firewalls and ESXi servers.. It's not (anymore) a lab thing. I totally agree with Peter, in such cases BPDU Guard should be enabled.

Raphael Lienard | CCIE #63267

I know this is old but it is still good practice to enable gaurd, filter, portfast, etc. To server ports that have virtual switches and all that jazz correct?

ESXi virtual switches don't need STP internally and rely on MAC Pinning or LACP for external multi-homed connections.

This basically means that Portfast Trunk can safely be used. I would always recommend to combine it with BPDU Guard (as a protection).

BPDU Filter should never be configured directly on an interface unless you really know what you are doing. It will suppress incoming BPDUs before BPDU Guard kicks in.

Raphael Lienard | CCIE #63267

Thanks. Can you give an example of when to not use BPDU filer for a server that is not doing any type of routing function?

acampbell
VIP Alumni
VIP Alumni

Hi,

Have a read at this link:-
http://blogs.vmware.com/vsphere/2011/11/vds-best-practices-virtual-and-physical-switch-parameters.html

Look at the STP section.


My view is that you may not know what apps will be run
in VMs behind the ESXi.

I would protect the switch network by ensuring NO portfast
and also guarding against a VM/App on the ESXi becoming or
claiming to become the root bridge.

http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10588-74.html#ios

!
interface GigabitEthernet1/0/1
 description ESXi
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 11,15
 switchport mode trunk
 no spanning-tree portfast trunk
spanning-tree guard root
!( or spanning-tree rootguard - depending on switch hardware)
end
!

 

Hope this helps
Regards
Alex

Regards, Alex. Please rate useful posts.

Hi acampbell,

Interesting point there and the link is good to read too, I will take into consideration on that:

spanning-tree rootguard

Thank you for your time

 

Regards,

Anson

Hi Alex/Anson

This thread is a bit old but interesting.

I will talk based on a cloud hosting or MSP environment where 100's of VMs can be running on same hypervisor or HA cluster. All of them wont belong to same entity with resource segregation using vCloud layer and sometimes it is hard to monitor individuals spinning up VMs (can be virtual switches, routers or some linux based tools etc).

Configuring rootguard/bpdugard will disrupt the connectivity of 24/7 live production machines. Since you would not expect STP related traffic on Virtual platform uplinks in normal cases, I would feel safer to configure BPDUFILTER along with carefully considered STORM-CONTROL thresholds backed by syslog flags to get alerts of breach.

Correct me if I am wrong.

 

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco