I currently have an interface on each switch configured as a trunk between the two switches. I want to now add another interface on each switch to increase the bandwidth between the two. I am thinking about using a port channel, and assigning these ports to the port channel. Will I lose connectivity (temporarily) between the two switches when I do this?
Cisco – Converting trunk interface to be in an ether-channel mode between cisco 3650 and 4500X
ciscoswitching
Related Solutions
Improperly configured EtherChannel (port-channel) interfaces would be disabled automatically, to prevent problems such as loops. First of all, having the same configuration on each side would be the safest.
Here's a checklist:
Both switches must see the ports as an EtherChannel bundle. If one switch would consider ports as separate connections, it's inconsistent and would fail.
All ports in the bundle needs to have the same EtherChannel protocol, i.e. don't mix PAgP and LACP. Also manual configuration mixed with one protocol is not recommended.
All channel ports must use at the same speed and the same duplex mode. And LACP doesn't support half-duplex.
No one of the ports can be SPAN (switched port analyzer) destination port.
If the channel is layer 3, give the address to the port-channel interface, not to single ports.
For layer 2 channels:
- All ports have to be either trunks or in the same VLAN.
- If trunking is used, the mode has to be the same on all ports.
- If you use a trunk with an allowed VLAN range, that range must be the same on all ports.
- If you would have different STP costs in a channel, at least ports have to be compatible to each other. STP considers an EtherChannel as a single port.
- Protocol filtering has to be the same on all ports.
- Also here, (static MAC) addresses must be on the port-channel interface, not on single ports.
Further reading:
First, like the others have mentioned you have no bridging loop here due to running a Portchannel. That said, running STP is still fine. Let me clear some confusions on how these commands work on Cisco switches.
spanning-tree portfast trunk
This command is supposed to be run on trunk ports towards non bridging devices, such as a server with multiple VLANs or a router. This command should not be run on trunks towards switches because the port will bypass the listening and learning phase which could potentially create a bridging loop.
If you have an interface configured like this:
interface x/x
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
BPDU guard will never kick in because BPDU filter is filtering both the outgoing and incoming BPDUs. This also means that the port can never lose its Portfast status which it would normally do if BPDUs were received inbound. If you remove the filter then BPDU guard will kick in and shutdown the port if a BPDU is received. This is done before the port can lose its Portfast operatational state so basically the port will always operate in Porfast operational mode.
If you apply the commands globally instead:
spanning-tree portfast default
spanning-tree portfast bpdufilter default
spanning-tree portfast bpduguard default
The first command enables Portfast on all access ports.
When BPDU filter is applied globally, the difference is that it sends out 11 BPDUs before going silent. Because normally one BPDU is sent out every 2 seconds and the default MaxAge is 20 seconds that means that if there is a device at the other end that can process BPDUs, at least one BPDU would be received when the old BPDU (if there was one) has expired.
If a BPDU is received inbound when BPDU filter is applied globally then the port stops filtering and it will lose its Portfast status.
The BPDU guard default command will only apply to ports that are in a Portfast operational state.
If you combine these three commands together then what will happen is that when a BPDU is received the port loses its BPDU filter, BPDU guard can then kick in. The port will never lose its Portfast operational state because the port is shutdown before.
So you see when applied to the interface BPDU guard can never kick in but if you apply it globally it can.
If you run just Portfast globally and BPDU filter globally then if a BPDU comes in, the port loses the filter and loses the Portfast operational state and will operate as a normal port.
Best Answer
Best way (no headache) is to default and shut the member interfaces , create the port-channel , add the member interfaces to the port-channel , no shut and only after that add the trunk configuration on the port-channel (the vlans). There are numberous issues and tricks even when working between switches from the same vendor , like surprises after a reboot when you get different configurations between the port-channel and the member interfaces , leaving you with error-disabled interfaces or unbundled from the Po.