cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
528
Views
2
Helpful
9
Replies

Trying to add existing live port in to a port channel

sasanka1912
Level 1
Level 1

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

 

 

 

 

 

1 Accepted Solution

Accepted Solutions


@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".

View solution in original post

9 Replies 9

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

Regards, LG
*** Please Rate All Helpful Responses ***

sasanka1912
Level 1
Level 1

@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?

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.

Regards, LG
*** Please Rate All Helpful Responses ***


@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.

Joseph W. Doherty
Hall of Fame
Hall of Fame

". . . 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.

sasanka1912
Level 1
Level 1

@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 ..


@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".

@Joseph W. Doherty Thanks and appreciate your help on this..