03-07-2025 12:44 PM - edited 03-07-2025 12:49 PM
Hi ,
I have two switches (SWITCH 5 & SWITCH 6,both 9300) connecting to Switch 4 via a single fiber connection. For better resiliency, it is suggested that I create a port channel and bundle two fibre ports together.
My question is the below order of operation will be able to achieve my task without any disruption to the production traffic.
1.configure a new port .
int xxxx
channel-group 1 mode active
2.Configure the port channel and that will inherit the configuration to the physical ports
int po1
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan xxxxx
3.remove the configuration from the existing live port .
default int xxxx
4.configure the existing port with port channel configuration
int xxx (existing live port)
channel-group 1 mode active
5.do post checks to see port channel is operational and no issues
show etherchannel summary | in 1
please advise
Solved! Go to Solution.
03-07-2025 03:29 PM - edited 03-07-2025 03:45 PM
@sasanka1912 wrote:
So the way we have set up is SW5(not stack) and SW7(not stacked) connecting to SW4 (stack 9300) using a single link and they are all configured as L2 to pass transit traffic.
Okay, so again, for SW4, ideally you'll want the new link on a different switch member.
For the non-stacked switches, I would need to review the hardware architecture for the specific models, but often different ASICs control different banks of ports. Although rather rare, I've seen a set of ports all die, while the switch continues to operate the remaining ports just fine. So, when possible, place the new link on a port as "far" from the existing link's port. (As you mention fiber, if limited to just the "uplink" ports, you might not be able to obtain this dispersion.)
@sasanka1912 wrote:
I was thinking about the STP as all the switches configured with RSTP and was wondering if port channel will be blocked by STP as we have a live port passing transit traffic and same vlans.
With STP, the new port, coming on-line, should initially be blocked. Whether it stays blocked, or takes the place of the existing link, depends on STP rules, such as the STP cost of each port (which I assume will not change, at least with just one member port).
@sasanka1912 wrote:
As you have mentioned possibly below order of operation will minimise the downtime
1.Configure and get the port channel up .
2.shutdown the existing live port
3.reconfigure the existing shutdown port.
4.Finally bundled the existing port to the new port channel.
please advise ..
Yup, that's the high level summary.
Whenever STP moves the traffic (in 1 or 2, above) from the original link to the new link, is when you're exposed to a network interruption. RSTP should minimize the time for the interruption.
What I'm uncertain about, is the expected interruption time. With RSTP, I believe it may be subsecond, to up 6 seconds (if using default, 2 second, hello times).
I'm also uncertain if there anything that might be done to minimize the transfer time, or the actual physical impact, such as before shutting down the existing link, first costing it worse that what's it has been, hoping for a fast "soft" transfer.
Depending how "critically" important the impact of any interruption might be, if you can, you might lab it, or just do it during non business hours, assuming you cannot obtain, or want to wait for, a "scheduled maintenance".
03-07-2025 01:25 PM
Hello @sasanka1912 ,
I would create the port channel interface first, step 2, and than configure the new port in the channel group.
Take care that the new port must be configured with the same L2 characteristics as the port channel, e.g.:
int xxxx
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan xxxxx
channel-group 1 mode active
The same goes for the existing port - step 4.
HTH
03-07-2025 01:46 PM
@liviu.gheorghe virtual port channel configuration will inherit the configurations to physical ports, instead of having to configure physical ports identical to the Virtual port channel. Isn't it?
03-07-2025 02:11 PM
In theory yes, the port channel interface will inherit the configurations of physical ports, but I also seen some exceptions to this rule.
This is the reason I always configure the port channel and the member interfaces with the same L2 characteristics. It can save you valuable troubleshooting time.
03-07-2025 02:33 PM
@liviu.gheorghe Thanks
03-07-2025 02:47 PM
@liviu.gheorghe wrote:
In theory yes, the port channel interface will inherit the configurations of physical ports, but I also seen some exceptions to this rule.
This is the reason I always configure the port channel and the member interfaces with the same L2 characteristics. It can save you valuable troubleshooting time.
NB: BTW, theory has become closer and closer to real-world results, as newer IOS versions have improved handling the relationship between the port-channel interface and its member ports, but what @liviu.gheorghe suggests is especially good advice during the initial setup. After Etherchannel correctly starts working, often you only need to make changes to just the port-channel interface.
03-07-2025 02:39 PM - edited 03-07-2025 02:41 PM
". . . will be able to achieve my task without any disruption to the production traffic."
Without ANY disruption? That can be difficult to achieve, especially if the links are L2. Are they? And if so, running a STP variant? If so, which?
At best, likely at some point you may have a minimal (sub second) disruption, ideally, so minimal, it goes, more-or-less, unnoticed. Chances for that are much better if using L3. For L2, you could get into a couple of seconds interruption situation up to nearly a minute; again much depends on the STP variant, how its configured, and actual topology.
What kind of access to you have to all 3 switches? I.e. if in-band, would any be downstream of the inter-switch(es) connection?
BTW, the second link, for the Etherchannel, would be using a different 9300 within a stack?
Also BTW, you would be looking to obtain benefit of the additional Etherchannel aggregate bandwidth? (The other "advantage" of Etherchannel.) If so, you've considered what hashing combination to use?
Anyway, high level:
You configure the new link as an Etherchannel, and bring it on-line. When you do so, depending how the Etherchannel port-channel interface is defined relative to the active link, traffic may just continue to use the prior link, traffic may now use both links or traffic may migrate to just the new link. The latter, is what usually causes the longest interruption.
After confirmation Etherchannel is good, you shut the prior link. Again, if this causes a full migration to the new link, it's usually the most impactful.
Once everything is stable on the Etherchannel link, you can reconfigure the prior port to become another member link, and bring it on-line. This tends to be hitless. You can also then confirm whether both Etherchannel links are passing traffic, which they should if traffic mix and chosen hash distributes that traffic across both links.
Going forward, an Etherchannel link drop is usually unnoticed by transit traffic.
Another BTW, if you working with 9300 stacks, you may want to consider the lost of the "active" switch member, and how to minimize its impact.
03-07-2025 02:56 PM
@Joseph W. Doherty Thanks for your detailed reply.
So the way we have set up is SW5(not stack) and SW7(not stacked) connecting to SW4 (stack 9300) using a single link and they are all configured as L2 to pass transit traffic.
I was thinking about the STP as all the switches configured with RSTP and was wondering if port channel will be blocked by STP as we have a live port passing transit traffic and same vlans.
As you have mentioned possibly below order of operation will minimise the downtime
1.Configure and get the port channel up .
2.shutdown the existing live port
3.reconfigure the existing shutdown port.
4.Finally bundled the existing port to the new port channel.
please advise ..
03-07-2025 03:29 PM - edited 03-07-2025 03:45 PM
@sasanka1912 wrote:
So the way we have set up is SW5(not stack) and SW7(not stacked) connecting to SW4 (stack 9300) using a single link and they are all configured as L2 to pass transit traffic.
Okay, so again, for SW4, ideally you'll want the new link on a different switch member.
For the non-stacked switches, I would need to review the hardware architecture for the specific models, but often different ASICs control different banks of ports. Although rather rare, I've seen a set of ports all die, while the switch continues to operate the remaining ports just fine. So, when possible, place the new link on a port as "far" from the existing link's port. (As you mention fiber, if limited to just the "uplink" ports, you might not be able to obtain this dispersion.)
@sasanka1912 wrote:
I was thinking about the STP as all the switches configured with RSTP and was wondering if port channel will be blocked by STP as we have a live port passing transit traffic and same vlans.
With STP, the new port, coming on-line, should initially be blocked. Whether it stays blocked, or takes the place of the existing link, depends on STP rules, such as the STP cost of each port (which I assume will not change, at least with just one member port).
@sasanka1912 wrote:
As you have mentioned possibly below order of operation will minimise the downtime
1.Configure and get the port channel up .
2.shutdown the existing live port
3.reconfigure the existing shutdown port.
4.Finally bundled the existing port to the new port channel.
please advise ..
Yup, that's the high level summary.
Whenever STP moves the traffic (in 1 or 2, above) from the original link to the new link, is when you're exposed to a network interruption. RSTP should minimize the time for the interruption.
What I'm uncertain about, is the expected interruption time. With RSTP, I believe it may be subsecond, to up 6 seconds (if using default, 2 second, hello times).
I'm also uncertain if there anything that might be done to minimize the transfer time, or the actual physical impact, such as before shutting down the existing link, first costing it worse that what's it has been, hoping for a fast "soft" transfer.
Depending how "critically" important the impact of any interruption might be, if you can, you might lab it, or just do it during non business hours, assuming you cannot obtain, or want to wait for, a "scheduled maintenance".
03-07-2025 03:34 PM
@Joseph W. Doherty Thanks and appreciate your help on this..
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide