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?
1
-
Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.– Ron Maupin ♦Commented Jan 5, 2021 at 19:38
Add a comment
|
2 Answers
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.
Port channels or aggregated links are used between switches - those links should not use portfast as that can cause a temporary bridge loop when a redundant link comes up.
Portfast skips the learning phase on an upcoming spanning tree interface and is for edge links only where it is not normal to have redundant links. Portfast decreases the delay between link up and actual forwarding/connectivity that may irritate some network clients.
As it modifies STP behavior, portfast needs to be applied to the logical port-channel interface in any case. Applying it to the physical interfaces will either have no effect or won't be possible at all.
-
Thanks. What do you think about portfast on an aggregated link to an end-host (like a router in this case)? Commented Jul 3, 2019 at 6:30
-
I wouldn't use it against a router that likely has no problem with a slightly longer delay between linkage and forwarding.– Zac67 ♦Commented Jul 3, 2019 at 7:20
-
1@Zac67 port-channel is not only used between switches. If you team NICs on a host you may or may not also need to define a port-channel on the switch (es) they uplink to, depending on how you configured the team on the host side. Hence the terms "switch dependent" and "switch independent".– Jesse P.Commented Jul 3, 2019 at 14:50
-
@JesseP. LAG is more common between switches and the OP asked about a switch-router link. With a host, I'd use portfast but only if there was no or little chance that any forwarding was configured - essentially only on a physical server but not on a virtual host (which has its own virtual switch anyway).– Zac67 ♦Commented Jul 4, 2019 at 7:41
-
1@Zac67 I know. I was just adding to what you said about port-channel being used between switches, so everyone knows that is not the ONLY place you can use them.– Jesse P.Commented Jul 4, 2019 at 12:14