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

Question

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.

Answer 1

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