Removing Port Channel without losing connectivity

[richard.a.adams]

I am connected to an access switch.  It has 4 Ethernet runs to our 2 Core switches.  2 go to CoreA and are port channeled,  and 2 go to Core B and are also port channeled.

We are preparing to go to VSS with these Cores and it was my intention to kill these port channels,  remove 1 cable each from each core,  and just have 1 trunk to each Core.  Then when VSS is implemented  we will create 1 port channel from these 2 trunks.  

So I got on CoreB and removed the command   "no channel-group 48 mode on"  on the two interfaces on this core.   No problem.  I then went to Core A and did the same thing  "no channel-group 20 mode on" to the first interface,  and just like that my access switch lost connectivity to the cores. 

I realize I went about this wrong,  and have since restored to original config.  Can somebody describe in detailed steps how to properly disengage and remove these port channels without me taking down my access switch?

[Reza Sharifi]

If you are planning to convert your core switches from stand-alone to VSS, you will need to do the changes in a maintenance window as this change will cause downtime. When you convert a switch from stand-alone to VSS, all the existing config will be overwritten.  

Question regarding your existing environment, why are you using 2 different Portchannles (20 and 48) connecting the same access switch to both cores? All 4 links should be in the same Portchannel.

HTH 

[richard.a.adams]

First of all,  I will not be performing the VSS cutover,  I am simply preparing my trunk links in a proper fashion prior to VSS.   Ideally,  that means no port channels,  and 1 trunk physically to each core.   They will port channel them after VSS.

I do not know why this switch is set up this way.   Somebody was playing around I guess back in the day.  

[Leo Laohoo]

---

@richard.a.adams wrote:

and just like that my access switch lost connectivity to the cores.  

---

Spanning-tree loop right there.  

---

@richard.a.adams wrote:

Can somebody describe in detailed steps how to properly disengage and remove these port channels without me taking down my access switch? 

---

Disable one of the two links, remove the config (and remove the allowed VLANs).  Done. 

[richard.a.adams]

ok,  your brief reply only begs about 50 more questions,   I need detailed response please.   Moving on to next reply which appears to have more detail.  Thanks though!

[Francesco Molino]

Hi
As Reza said, moving to vss will have an impact.
Now in terms of config on access, here steps i will do:
- keep PO on core 1
- shut interfaces facing core 2 on access switch.
- put  1 of the 2 shut interfaces on access switch to the same po facing core1, and the other remains in standalone and keep them shut. This step is to be able to access your access switch if something goes wrong on Core1.
- remove config PO on core 2
- no shut the remaining standalone cable on core2 and access. Here STP will block this link or PO on core 1 depending on your config. This step is to be able to access your access switch if something goes wrong on Core1.
- apply vss change
- once vss is up and running, shut down all interfaces facing core 2 on access, put the 2 interfaces on core2 to same po of core1 facing access switch.
- no shut of your 2 interfaces facing core2 on access switch.

[richard.a.adams]

thank you for more detail.   I still have questions as I want to do this right.

Again,  my goal is to simply kill both port channels,  remove 2 physical links and just have 1 trunk to core a and 1 to core b.    I am not sure your answer is pointing me to this goal.

Does PO  mean port channel?

"Shut interfaces on core 2 on access switch"  -   ok, that sounds simple enough

" put  1 of the 2 shut interfaces on access switch to the same po facing core1, and the other remains in standalone and keep them shut. This step is to be able to access your access switch if something goes wrong on Core1."  -  ok,  you have totally lost me here.  how can I place a link to one core on the same port channel that goes to another core?   

"no shut the remaining standalone cable on core2 and access. Here STP will block this link or PO on core 1 depending on your config. This step is to be able to access your access switch if something goes wrong on Core1.   -    and access??   Lost again

I am not yet worried about VSS,  that is being handled by higher level engineer.   Just want to kill the 2 port channels, physically remove the 2 extra links and just have 1 trunk to Core A and 1 trunk to Core B. 

Please advise.   Sorry  I am not understanding all of this.   I really want to.

[Francesco Molino]

Give me few time, I'll do some examples with commands over the WE and get back to you.
PO is port-channel yes.

[Francesco Molino]

let's take the following design lab 

On R3:

 - e0/0 and e0/1 belong to Port-channel 1 facing R1

 - e0/2 and e0/3 belong to Port-channel 2 facing R2

STP ROOT Primary is R1 and Secondary is R2

ACCESS#sh spanning-tree root

Root Hello Max Fwd
Vlan Root ID Cost Time Age Dly Root Port
---------------- -------------------- --------- ----- --- --- ------------
VLAN0010 4106 aabb.cc00.1000 56 2 20 15 Po1
VLAN0020 4116 aabb.cc00.1000 56 2 20 15 Po1
ACCESS#
ACCESS#
ACCESS#sh cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
CORE2 Eth 0/3 161 R S I Linux Uni Eth 0/1
CORE2 Eth 0/2 148 R S I Linux Uni Eth 0/0
CORE1 Eth 0/0 140 R S I Linux Uni Eth 0/0
CORE1 Eth 0/1 131 R S I Linux Uni Eth 0/1

Number of channel-groups in use: 2
Number of aggregators: 2

Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
1 Po1(SU) LACP Et0/0(P) Et0/1(P)
2 Po2(SU) LACP Et0/2(P) Et0/3(P)

Ok now, here the different steps:

- shutdown interfaces in Po2 on access and Po1 in R2. Access switch will be connected only on Core1 using Port-channel 1

- remove all interfaces on Access facing Core2 from Port-channel

ACCESS(config-if)#int range e0/2-3

ACCESS(config-if-range)#no channel-group 2 mode active

- Same on Core2:

CORE2(config-if)#int range e0/0-1
CORE2(config-if-range)#no channel-group 1 mode active

- Our access switch is reachable from R1

ACCESS(config-if-range)#do sh cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
CORE1 Eth 0/0 143 R S I Linux Uni Eth 0/0
CORE1 Eth 0/1 131 R S I Linux Uni Eth 0/1

- no shut only 1 interface from access facing core2. In our example, we will take e0/2 on access and e0/0 on core2

We will see access is connected on both switches (1 PO to core1 and 1 interface to core2)

ACCESS#sh cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
CORE2 Eth 0/2 164 R S I Linux Uni Eth 0/0
CORE1 Eth 0/0 164 R S I Linux Uni Eth 0/0
CORE1 Eth 0/1 155 R S I Linux Uni Eth 0/1

We can also see that core2 interfaces to access are blocked by STP

CORE2#sh spanning-tree blockedports

Name Blocked Interfaces List
-------------------- ------------------------------------
VLAN0010 Et0/0
VLAN0020 Et0/0

- shutdown interfaces in Po1 on access and Po1 in R1. Access switch will be connected only on Core2 using e0/2

- remove all interfaces on Access facing Core1 from Port-channel

ACCESS(config-if)#int range e0/0-1

ACCESS(config-if-range)#no channel-group 1 mode active

- Same on Core1:

CORE2(config-if)#int range e0/0-1
CORE2(config-if-range)#no channel-group 1 mode active

- Now on Core2, no STP blocked ports as access switch is connected only through Core2

CORE2#sh spanning-tree blockedports

Name Blocked Interfaces List
-------------------- ------------------------------------

Number of blocked ports (segments) in the system : 0

ACCESS(config-if-range)#do sh cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
CORE2 Eth 0/2 151 R S I Linux Uni Eth 0/0

- Now we will unshut e0/0 on access and e0/0 on core1 to build up the connection between them

To make sure connection will be active on Core1, here an example of changing port-priority (I don't know how today everything is configured on your side). Better priority on e0/0 facing Core1 than e0/2 facing core2

ACCESS(config-if)#int e0/0

ACCESS(config-if)#spanning-tree port-priority 0
ACCESS(config-if)#int e0/2
ACCESS(config-if)#spanning-tree port-priority 64

And finally connection is UP with Core1 and STP blocked interfaces going to Core2:

ACCESS#sh spann blockedports

Name Blocked Interfaces List
-------------------- ------------------------------------
VLAN0010 Et0/2
VLAN0020 Et0/2

I've changed a little bit the process because you said you wanted to have only 1 interface per switch.

After you've done your VSS, you'll need to bundle all interfaces into 1 Port-Channel.

Hope this clarify everything