Cisco Port-channel lacp/etherchannel to PaGP

[localbuilt]

Need some help. I have been tasked to change the switch port-channel. The requirements are to change settings from LACP/Etherchannel mode to PaGP mode. The problem is that this is production and I don't have a lab to test. I'm not sure how it would behave if I start reconfiguring one by one and I'm afraid there would be a recalculation of routing if the channel is broken. Question 1. How do I smoothly change the settings so that no production impact. 2. what will happen when one link is a different mode?
3. Are any configs I need to do for this change other than "channel-group 2 mode desirable"

below are the config details on my scenerio.
SWA# sh int po2
Port-channel2 is up, line protocol is up (connected)
Hardware is EtherChannel, address is 000f.2462.a34b (bia 000f.2462.a348)
Description: SWB
MTU 1500 bytes, BW 8000000 Kbit, DLY 10 usec,
reliability 255/255, txload 8/255, rxload 39/255
Encapsulation ARPA, loopback not set
Full-duplex, 1000Mb/s
input flow-control is off, output flow-control is unsupported
Members in this channel: Gi2/45 Gi2/46 Gi2/47 Gi2/48 Gi3/45 Gi3/46 Gi3/47 Gi3/48

SWA#sh run int g2/45
Building configuration...

Current configuration : 251 bytes
!
interface GigabitEthernet2/45
description swB
no ip address
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 120,122,124,126,324,401,402,501-504,700
switchport mode trunk
channel-group 2 mode on
end



SWB#sh int po2
Port-channel2 is up, line protocol is up (connected)
Hardware is EtherChannel, address is 000f.f77e.2dac (bia 000f.f77e.2dac)
Description: SWA
MTU 1500 bytes, BW 8000000 Kbit, DLY 10 usec,
reliability 255/255, txload 23/255, rxload 8/255
Encapsulation ARPA, loopback not set
Full-duplex, 1000Mb/s
input flow-control is off, output flow-control is unsupported
Members in this channel: Gi2/45 Gi2/46 Gi2/47 Gi2/48 Gi3/45 Gi3/46 Gi3/47 Gi3/48
ARP type: ARPA, ARP Timeout 04:00:00

SWB#sh run int g2/45
Building configuration...

Current configuration : 251 bytes
!
interface GigabitEthernet2/45
description SWA
no ip address
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 120,122,124,126,324,401,402,501-504,700
switchport mode trunk
channel-group 2 mode on

 

[uzumaki]

Your etherchannel is working fine. It doesnt have any protocols to use because it is already on the "On" mode. PagP and LACP are just protocol used by the etherchannel techology to communicate with each other. Its like hardcoding a 100Mbps connection on both ends of the switch. Since your config is hardcoded, it is already working fine. Are u sure u want to go on PagP protocol?

 

[localbuilt]

Yes, we would like to use PaGP unconditionally because we noticed that when using LACP (current set up) and one interface is down, it still thinks its a channel althouhg only one link it up and other interface are down.

 

[localbuilt]

I understand its working fine right now however we would like to change to PaGP.

 

[vipergg]

You are not currently running LACP , the channel is forced on with no etherchannel protocols being used , if it was lacp the interfaces would have this syntax "channel-group X mode active" on each interface , the way it is now is forced on . If you want to use pagp then use the following if its between 2 cisco devices " channel-group X mode desirable non-silent" , this is recommended setting between cisco devices. We use it all the time . I always use dynamic channel protocols , this keeps you from misconfgiuring the channels and causing problems or spanning tree loops.

 

[vipergg]

PS , you are right and that is one of the main reasons I do not force on the ehterchannels or trunks just do to that fact , the dynamic negotiation protocols will eliminate this , its either up or down because they do talk to each other on each end of the links . I also do not force the trunks on ,use the desirable mode for trunks also .

 

[localbuilt]

We have etherchannels or LACP set up but as an example I provided etherchannel "ON". So would you recommend that if I config one int at a time on SWA and SWB and set it to active, this will not cause any downtime or recalculations? what would be the most effective process to change this in production?

 

[vipergg]

No I think at the very least you will take a link bounce converting this . I would do it off hours when people aren't using it so much . Actually to implement this they normally reccomend shutting the links down , configure them and then bring them all up at the same time by doing a no shut on the port channel interface , this brings up all the channels gracefully . Bring up one side then the other as close together as possible .

 

[uzumaki]

Yup I agree more on the etherchannel part. But as a side note, try to hardcode ur trunk links, most of the CCIE's I recommends hardcoding on trunk links either 100Mbps, 1Gbps, or 10Gbps.

 

[localbuilt]

Thanks Guys. I appreciate your help. I will let you know how it turns out.

 

[Jsteve]

I would also recommed doing the change off hours. You never know what types of bugs you will hit with a change like this. I would suggest the following steps

1. shut down all of the links in the bundle except one from the switch from the side that you will be able to access if all of the links go down.

2. Configure those ports on the local and remote switch, on the ports that are down to " channel-group X mode desirable non-silent"

3. configure the remote end of the only link that is still up to " channel-group X mode desirable non-silent", than do the local switch.

3. Bring up one link and verify that the link has joined the bundle with the "show etherchannel port-channel" command.

4. repeat step 3 for the rest of the links.

I would also recommend nailing the trunks to "on" and setting the port channel to "desirable". With both trying to negociate from a down state, it takes a lot longer for the link to come up. I have a TAC case with cisco once inwhich having them both set to negociate during a upgrade caused a problem. I forgot the details, it was about 2years ago, but we ended up using trunk on for portchanneled links through out the network and haven't had any problems since.

CCIE#17401