I'm using a Cisco 3750 switch and have two physical ports configured in a port channel that connects to a router. Should I configure spanning-tree portfast on the physical interfaces or on the port-channel virtual interface, or both?
Cisco – Should portfast be configured on the physical interfaces or on the logical port-channel, or both
ciscocisco-3750cisco-catalystport-channelspanning tree
Related Solutions
This post is older in age so I'm not sure if you are still experiencing this problem. I would like to see the documentation you are referring too regarding the portfast trunk command. The portfast trunk configuration should be applied to hosts that you are trunking with, for example an ESX host or a Load Balancer. For switch to switch, this configuration should not be there.
There is a lot of information I would need to see to better understand the topology and what spanning-tree mode you are running in (PVST+, RPVST+ or MST). I suspect from what I've read you are running PVST+. I would like to first start with the output of show spanning-tree vlan x detail and a snippet of this TCN you are seeing. I would also like to see show run | i spanning.
I suspect you may have a port(s) that is flapping and the TCN message should lead us directly to the culprit.
So you have a VoIP phone plugged into a switchport that is configured switchport access vlan and computers/hosts plugged into other switchports with switchport access vlan ? Yeah you know you can set it up for switchport voice vlan. However being setup without the switchport voice vlan, I do not see this being an issue with TCN's.
TCN's are generated when a port transitions from one state to another assuming you are not changing the priority values.
Port fast bypasses the usual STP phases and goes straight into forwarding. This is useful for ports connected to end-devices which use DHCP. It does not stop BPDUs, and there are those who advocate using it on all ports, although Cisco has a different take on it:
Caution: Never use the PortFast feature on switch ports that connect to other switches, hubs, or routers. These connections can cause physical loops, and spanning tree must go through the full initialization procedure in these situations. A spanning tree loop can bring your network down. If you turn on PortFast for a port that is part of a physical loop, there can be a window of time when packets are continuously forwarded (and can even multiply) in such a way that the network cannot recover.
BPDU guard will disable (errdisable) a port which receives BPDUs. The helps to prevent rogue switches and STP loops. Cisco has a document which explains BPDU guard:
Feature Description
STP configures meshed topology into a loop-free, tree-like topology. When the link on a bridge port goes up, STP calculation occurs on that port. The result of the calculation is the transition of the port into forwarding or blocking state. The result depends on the position of the port in the network and the STP parameters. This calculation and transition period usually takes about 30 to 50 seconds. At that time, no user data pass via the port. Some user applications can time out during the period.
In order to allow immediate transition of the port into forwarding state, enable the STP PortFast feature. PortFast immediately transitions the port into STP forwarding mode upon linkup. The port still participates in STP. So if the port is to be a part of the loop, the port eventually transitions into STP blocking mode.
As long as the port participates in STP, some device can assume the root bridge function and affect active STP topology. To assume the root bridge function, the device would be attached to the port and would run STP with a lower bridge priority than that of the current root bridge. If another device assumes the root bridge function in this way, it renders the network suboptimal. This is a simple form of a denial of service (DoS) attack on the network. The temporary introduction and subsequent removal of STP devices with low (0) bridge priority cause a permanent STP recalculation.
The STP PortFast BPDU guard enhancement allows network designers to enforce the STP domain borders and keep the active topology predictable. The devices behind the ports that have STP PortFast enabled are not able to influence the STP topology. At the reception of BPDUs, the BPDU guard operation disables the port that has PortFast configured. The BPDU guard transitions the port into errdisable state, and a message appears on the console.
Best Answer
Port-channeling is a way to bypass the topology limitation of spanning-tree allowed to only having a single path. In spanning tree, the logical topology of the data-plane will arrange itself into a logical tree where you can only have 1 active link between the same two devices.
By implementing a LAG (link aggregation group: aka Port Channel) you fool spanning tree into thinking it is one single port instead of a multiple ports. So from this perspective spanning tree does NOT see the underlying ports, only the LAG itself.
To answer your question you can put it on both without issue, but it will only take effect on the port channel as spanning tree does not see the member ports.
A better practice would be to actually enable spanning-tree portfast default globally. This would allow any port that does NOT receive bpdu packets to behave as an edge port and accelerate the spanning tree process. More importantly if you bounce a portfast "edge" port it will NOT trigger a spanning tree TCN (topology change notification).
This is all assuming you're using the LAG port as an access port. If you're trunking vlans across the port, you need to specifically enable portfast for trunks.
I hope this helps to clear things up.