STP EtherChannel – All modes DEEP DIVE, cross-stack EtherChannel / channel-protocol reviewed, and verification cmds demonstrated!

I’ve removed the 2 x 1Gig links and replaced them with 3 FastEthernet links for this lab, as I wanted to do some adjusting of speed and duplex throughout the lab, but with multi-mode fiber it is not having any of those sort of changes:

SW2(config)#int gi1/0/1
SW2(config-if)#speed ?
nonegotiate Do not negotiate speed

SW2(config-if)#duplex ?
% Unrecognized command
SW2(config-if)#

Not useful for this lab segment, but helpful to know of these behaviors, and this is one of the reasons I advocate the use of physical hardware where relatively cheap for a home lab or loaner equipment from work!

 

LACP vs PAgP vs On EtherChannel fundamentals

 

First a quick review of these direct from the CLI to get a glance at how IOS defines them:

SW1(config-if-range)#channel-group 12 mode ?
active Enable LACP unconditionally
auto Enable PAgP only if a PAgP device is detected
desirable Enable PAgP unconditionally
on Enable Etherchannel only
passive Enable LACP only if a LACP device is detected

Highlighted in red is LACP, highlighted in blue is PAgP, and highlighted in green is “On” mode.

It is important to know which modes belong to which protocols, and just as importantly which modes will initiate an EtherChannel vs which mode will listen for negotiation.

With EtherChannel “On” mode is much different from DTP negotiation, where it WILL NOT form an EtherChannel with either of the two negotiation protocols, the other side must also be set to On mode or the EtherChannel will not form.

Below is an illustration of matching protocols and how they form EtherChannels:

 On Mode – Forming:

On|———–|On

On Mode – Not forming:

On|———–|(PAgP / LACP / Off)

PAgP Mode – Forming:

 Desirable|———-|Desirable
Desirable|———-|Auto

PAgP Mode – Not forming:

Auto|———-|Auto

LACP Mode – Forming:

Active|———|Active
Active|———|Passive

LACP Mode – Not forming:

Passive|———|Passive

So as can be seen, if the protocol matches, it will only not form if both sides are in a listening / detecting negotiation mode.

Here are modes / examples of protocol mismatches, both sides being in a listening mode, or the EtherChannel being able to form because everything is configured correct:

Auto|————–|Passive = Not forming
Desirable|—————|Auto = Forming
On|—————|Desirable = Not forming
Active|————–|Passive = Forming
On|————-|On = Forming
Auto|————|Auto = Not forming

I remember these by the fact that PAgP is the Cisco Proprietary negotiation EtherChannel protocol, which is also a Cisco proprietary protocol, while LACP is more like EIGRP which while still technically under Cisco proprietary it is becoming vendor neutral (sort of).

I try to remember Cisco proprietary vs Open Standard to memorize these modes quickly.

On mode is just simply… On. Just need to differentiate it will NOT form EtherChannels with Dynamic / Negotiated remote sides like it static “On” mode does with trunking.

 

Review of LACP / PAgP / On modes with lab output to demonstrate concepts

 

For ALL EtherChannel modes, both sides must have matching values for (but not limited to) the following parameters:

1. Port Speed
2. Duplex Mode
3. Trunk Mode
4. Trunk Status
5. Native VLAN
6. VLAN Range

On mode vs Negotiation handles the mismatch of these a bit differently, discussed below.

Also to note up front as this behavior is shared between all EtherChannel types, is that upon formation of the EtherChannel, the first physical interface to join the channel will provide the MAC Address for the logical interface to use.

If the physical interface providing the MAC Address going down, the EtherChannel will select another interface to use for a hardware MAC Address for the logical interface.

On:

• Hard codes the interface to be in EtherChannel “On” mode, will go into err-disable state if remote end of logical link is not detected to be in On mode
• Vendor neutral, useful for devices that do not use LACP or PAgP
• Can perform Cross-Stack EtherChannel (Illustrated toward bottom of post)
• Will NOT form EtherChannel while remote end is in any sort of negotiation mode

Not a recommended mode because of the forceful nature of the configuration to the interfaces, saying essentially “You’re either in or you’re out of this EtherChannel,” so it is really an all or nothing configuration which is just not best practice.

Example of the all or nothing nature of On mode:

SW1(config)#int ra fa1/0/1 – 2
SW1(config-if-range)#channel-group 1 mode on
Creating a port-channel interface Port-channel 1

SW1(config-if-range)#
*Mar 1 01:47:42.130: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to up
*Mar 1 01:47:42.273: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/2, changed state to up
*Mar 1 01:47:43.137: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up
SW1(config-if-range)#
*Mar 1 01:47:44.143: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to up

All seems well for about 30 seconds, before the err-disable comes flooding in:

SW1(config-if-range)#
*Mar 1 01:48:07.405: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Fa1/0/1, putting Fa1/0/1 in err-disable state
*Mar 1 01:48:07.422: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Fa1/0/2, putting Fa1/0/2 in err-disable state
SW1(config-if-range)#
*Mar 1 01:48:07.497: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Po1, putting Fa1/0/1 in err-disable state
*Mar 1 01:48:07.497: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on
Po1, putting Fa1/0/2 in err-disable state
*Mar 1 01:48:07.497: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Po1, putting Po1 in err-disable state
SW1(config-if-range)#

To visually separate that mess, first the physical interface detects the error highlighted in red, and puts the interface into an Err-Disabled state, then comes crashing down the Port-Channel with them highlighted in blue.

You then need to go through the shut / no shut process, reconfigure the other side to be channel-group mode “on” to prevent the err-disable state again, etc.

Due to the forceful nature of this configuration, an interface with “On” mode configured will be forced into the EtherChannel, or will be suspended – It does not have the option to operate independently of the EtherChannel.

***I have found in extensive labbing that if you are seeing an Err-Disable state with EtherChannel, it is a 99.9% chance you are looking at static / On EtherChannel***

LACP and PAgP shared details:

• Both use CDP and DTP over Physical and Trunk links to negotiate matching parameter values from the list above
• Both send LACP or PAgP PDU’s (Protocol Data Units) for this negotiation
• Both send PDU’s on Trunk interfaces over the lowest number VLAN on the Trunk
• Both dynamically configured bundled links when changes are configured in the “Port-Channel” interface
• Both use negotiation to bring interfaces into the EtherChannel with matching values from the above parameters, any non-matching interfaces will not join the EtherChannel, and will instead operate independently of the EtherChannel

That last one is a big one to remember when thinking “On” Vs “Negotiation” modes!

Note these mechanisms and behaviors are very similar to STP, because EtherChannel is the answer to STP Blocking individual links to prevent switching loops, so STP mechanisms also negotiate EtherChannel parameters also to prevent switching loops!

LACP:

• LACP is IEEE 802.3ad / 802.3ax Link Aggregation Control Protocol
• LACP bundled interfaces must run at full duplex only
• LACP can be configured for up to 16 ports, 8 “bundled” and 8 on standby for link failure in the bundle
• LACP can do Cross-Stack EtherChannel (plugged into separate switches in a stack)
• LACP interfaces have default Port Priority of 32768, can be manually changed
• LACP uses Active / Passive for its negotiation modes (EIGRP mode names!)

Quick note on 802.3ax:

LACP is taught / discussed as both 802.3ad and 802.1ax as its new IEEE designation, both seem to refer to Link Aggregation, so it would be good to know both for exam day.

LACP not only being vendor neutral, but also allowing for an additional 8 interfaces to be configured for hot standby to step in for no loss of bandwidth, really to me makes it the optimal choice (but probably not to Cisco on its exam).

It also has an odd but necessary to know quirk, that it does not support Half-Duplex connections at all, which will cause the Port-Channel to go down in several instances:

From configuring a channel-group on interfaces running at Half-Duplex statically:

SW1(config-if-range)#duplex half
SW1(config-if-range)#
SW1(config-if-range)#
SW1(config-if-range)#channel-group 13 mode active
Creating a port-channel interface Port-channel 13

SW1(config-if-range)#
*Mar 1 00:42:36.730: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to down
*Mar 1 00:42:36.788: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/2, changed state to down
*Mar 1 00:42:36.822: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/3, changed state to down
*Mar 1 00:42:36.889: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/4, changed state to down
*Mar 1 00:42:36.929: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel13, changed state to down
SW1(config-if-range)#

Note that this is just the Line-Protocol going down, putting the interfaces / Port-Channel into a logically down state, all that is needed to bring the ports back up is to find the Half-Duplex setting and correct it if possible.

Interfaces set to “auto” duplex are suddenly changed from the other side to Half-Duplex:

SW1(config-if-range)#duplex auto
SW1(config-if-range)#
ASR#3
[Resuming connection 3 to sw3 … ]

SW3(config-if-range)#duplex half
SW3(config-if-range)#
ASR#1
[Resuming connection 1 to sw1 … ]

*Mar 1 00:55:16.410: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to down
*Mar 1 00:55:16.461: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/2, changed state to down
*Mar 1 00:55:16.511: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/3, changed state to down
*Mar 1 00:55:16.561: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/4, changed state to down
*Mar 1 00:55:16.570: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel13, changed state to down
SW1(config-if-range)#

So that is something to watch for both on SWITCH and TSHOOT exam days, note that it does NOT go into Err-Disable like “On” mode, but rather just a logical “Down” state.

Now some very important notes for exam day regarding the nuts and bolts of LACP

Upon link failure of an interface in the EtherChannel bundle, the link brought into the group depends on two factors:

• Which switch has the lowest Bridge ID, this bridge becomes the “Master”
• Which port on the “Master” switch for the Port-Channel has the lowest Port Priority

Exactly like STP Root Bridge Election / Root Path selection (tie breakers), and will go in order of Bridge Priority then MAC Address of the bridge.

When the channel is formed one of the switches will be elected as the “Master” switch for the Channel, which essentially performs dynamically bring in / taking out hot standby links upon link failure from an interface within the bundle, and it chooses based on the Port Priority of its local interfaces – The Master could not care less about the remote switches Port Priority values when bringing in a standby link!

On the “Master” bridge, the port selected will be done so based on the Port Priority value, which for LACP is the same as the default Bridge ID value of 32768 for every link bundled in the LACP EtherChannel – Meaning all links have port priority 32768.

To configure a different Port Priority for an interface, if you are tasked to use a certain physical interface as the primary hot standby for an LACP bundle for example, you would configure it on the physical interface(s) required with the following command:

SW1(config-if)#lacp ?
port-priority LACP priority on this interface

SW1(config-if)#lacp port-pri ?
<0-65535> Priority value

SW1(config-if)#lacp port-pri 0 ?
<cr>

SW1(config-if)#lacp port-pri 0
SW1(config-if)#

Note this command will bounce the interface(s) it is issued on (quick down/up).

To verify

SW1(config-if)#do sh lacp internal
Flags: S – Device is requesting Slow LACPDUs
F – Device is requesting Fast LACPDUs
A – Device is in Active mode P – Device is in Passive mode

Channel group 13
LACP port Admin Oper Port Port
Port Flags State Priority Key Key Number State
Fa1/0/1 SA bndl      32768 0xD 0xD 0x104 0x3D
Fa1/0/2 SA bndl               0 0xD 0xD 0x105 0x3D
Fa1/0/3 SA bndl       32768 0xD 0xD 0x106 0x3D
Fa1/0/4 SA bndl       32768 0xD 0xD 0x107 0x3D
SW1(config-if)#

This also applies to interfaces being selected to bundle into a channel.

For example if the entire interface range of Fa1/0/1-24 are configured with the “channel-group …” command, the “lacp port-pri …” command could be used on a range of 8 interfaces prior to the channel-group config to influence which ports are selected!

As it was with Spanning-Tree, lower Priority is preferred for EtherChannel as well!

Only the Master switch will consider these values at all, so be sure to check the local Bridge Priority / MAC Address to determine the “Master” switch if trying to determine eligible standby links for an LACP Port-Channel.

Keep in mind this ONLY applies to LACP as PAgP does not have standby ports!

Speaking of PAgP and what it DOES have…

PAgP:

• PAgP is Cisco proprietary Port Aggregation Protocol
• PAgP can be configured for up to 8 ports (no standby ports)
• PAgP bundled interfaces can run at either half or full duplex
• PAgP CANNOT do Cross-Stack EtherChannel (must be single switch)
• PAgP interfaces have default Port Priority of 128, can be manually changed
• PAgP includes a “non-silent” mode for connecting to non-PAgP devices
• PAgP uses Desirable / Auto for its negotiation modes (DTP mode names!)

PAgP negotiation protocol for EtherChannel is probably considered best practice for exam day purposes, because of its ability to run either Half or Full Duplex on bundled interfaces, and of course being the Cisco Proprietary choice gives it a leg up.

PAgP seems to be a more special use EtherChannel protocol as it doesn’t allow for hot standby interfaces, it does not do Cross-Stack EtherChannel, and it can run in Half-Duplex mode if needed – It also has a “silent” mode configurable on PAgP interfaces.

So it doesn’t have a whole lot going on for it, however there is one sneaky sub-command in the “channel-group” configuration to know for exam day:

SW1(config-if-range)#channel-group 12 mode desirable ?
non-silent Start negotiation only after data packets received
<cr>

SW1(config-if-range)#channel-group 12 mode desirable non-silent ?
<cr>

“Non-Silent” mode is used as a verification of bi-directional communication before forming an EtherChannel, which has the same function of UDLD, in that it is a mechanism to prevent Uni-Directional communication via Multi-Mode Fiber were one cable in a Tx / Rx pair might go down while the other side stays operating – So the interfaces appears fully operational but is actually only Sending / Receiving.

Silent is the default sub-mode for PAgP, which will form an EtherChannel normally with a Desirable interface sending PAgP negotiation traffic to an Auto or Desirable interface, and non-silent mode is used for cases where PAgP negotiation may not be possible.

This does not effect normal EtherChannel formation, one side does still need to be in Desirable mode for an EtherChannel to form, it is only really used when connecting to a non-PAgP running neighbor.

So remember for exam mode, if you see “Silent-Mode”, we are talking PAgP!

Last but not least, the Port Priority for every PAgP interface is 128, which matches the STP interface Port Priority default value of 128, however it is not related to the value from interfaces in “sh span” output.

To reconfigure PAgP Port Priority:

SW1(config)#int fa1/0/1
SW1(config-if)#pagp ?
learn-method The ability to determine the input interface of incoming
packets
port-priority PAgP priority on this interface
rate Rate at which the PAgP packets are sent to peer
timer Specify the earliest time at which Rx’ed PAgP informational
packets are timed out (in sec)

SW1(config-if)#pagp port-priority ?
<0-255> Priority number

SW1(config-if)#pagp port-priority 0 ?
<cr>

There are a few more options here for PAgP on the interface than LACP, but I am only here for Port Priority, of which can be set at a value of anywhere from 0-255.

This priority is not really used or mentioned much in discussions / training / documentation, because it is fairly trivial being that it has no “hot standby” interfaces to potentially replace a down link in the bundle, but for the sake of being thorough this is where / how to reconfigure PAgP Port Priority.

For verification the command is “sh pagp internal” in user exec mode, demonstrated at the bottom of this post in the verification commands segment where I compare outputs.

 

What in the world is Cross-Stack EtherChannel as mentioned earlier?

I have not covered Switch Stacking or Stack-Wise configuration yet, however I wanted to mention this here, as this is probably the extent you will need to know for exam day.

With either LACP or “On” mode you can configure different “Stack Members” of a switch stack to be have interfaces in the same Port-Channel leading back to another switch:

I configured this on the SW1 stack of members SW1 and SW2 with an LACP EtherChannel back to SW3, and to demonstrate this working I just verified the interfaces in my active Port-Channel on the switch stack:

SW1(config-if-range)#do sh int po13
Port-channel13 is up, line protocol is up (connected)
Hardware is EtherChannel, address is 1ce6.c7c1.c803 (bia 1ce6.c7c1.c803)
MTU 1500 bytes, BW 400000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, link type is auto, media type is unknown
input flow-control is off, output flow-control is unsupported
Members in this channel: Fa1/0/1 Fa1/0/2 Fa2/0/1 Fa2/0/2

This applies with “On” EtherChannel as well though I will spare the output, this demonstrates these two modes provide EtherChannel redundancy when using Stackwise technology, whereas with Cisco proprietary PAgP it’s a much different story.

 

I can’t show the Port-Channel interface for this demonstration because the physical interfaces never join the EtherChannel bundle, giving the following error upon configuration on the switch stack:

SW1(config)#int ra fa1/0/1 – 2
SW1(config-if-range)#channel-group 13 mode desirable
Creating a port-channel interface Port-channel 13

SW1(config-if-range)#
(Lots of output from physical interfaces bouncing Down / Up)
SW1(config-if-range)#
SW1(config-if-range)#
SW1(config-if-range)#int ra fa2/0/1 – 2
SW1(config-if-range)#channel-group 13 mode desirable
%With PAgP enabled, all ports in the Channel should belong to the same switch
Command rejected (Port-channel13, Fa2/0/1): Invalid etherchnl mode

% Range command terminated because it failed on FastEthernet2/0/1
SW1(config-if-range)#

Even in the same logical switch unit / switch stack, the interfaces must be on the same physical switch with PAgP, or they will not join the bundle!

For more information on Stackwise, you can view my post on it here.

 

Reviewing “channel-protocol” command for EtherChannel physical interfaces

 

Here is  a quick review of the “channel-protocol” command on an interface range:

SW1(config-if-range)#channel-protocol ?
lacp Prepare interface for LACP protocol
pagp Prepare interface for PAgP protocol

SW1(config-if-range)#channel-protocol lacp ?
<cr>

SW1(config-if-range)#channel-protocol pagp ?
<cr>

Both are limited to only configuring a negotiation protocol, no sub-commands and nothing for “On” mode, so this is a negotiation-only command.

I tried this on an unused interface to confirm what it does first, which is configures the interface(s) for the protocol they are allowed to use:

SW1(config-if)#channel-protocol pagp
SW1(config-if)#do sh run int fa1/0/7
Building configuration…

Current configuration : 58 bytes
!
interface FastEthernet1/0/7
channel-protocol pagp
end

SW1(config-if)#

That is about as straight forward as it gets, just tells the interface which negotiation protocol can be used to join an EtherChannel, and that is absolutely its only use.

The “channel-protocol” command does not help build the EtherChannel in any way!

I tried to set the channel-protocol first to LACP, then configure a PAgP negotiation mode to see what would happen, which was about what was expected:

SW1(config-if-range)#channel-protocol lacp
SW1(config-if-range)#channel-group 12 mode desirable
Command rejected (Channel protocol mismatch for interface Fa1/0/13 in group 12): the interface can not be added to the channel group

% Range command terminated because it failed on FastEthernet1/0/13
SW1(config-if-range)#

So if this error of “Channel protocol mismatch” is seen while configuring an EtherChannel, it may be due to “channel-protocol” already being configured.

Alternatively if you try to issue it on an already existing interface type, here is an example of what will happen, configuring on a PAgP EtherChannel interface range:

SW1(config-if-range)#channel-protocol lacp
Command rejected ( Fa1/0/13 ): is already part of a channel with a different type of protocol enabled

% Range command terminated because it failed on FastEthernet1/0/13
SW1(config-if-range)#

That sums up the channel-protocol command, it just tells the interface what protocol to use, but be weary of this in both the SWITCH and TSHOOT exams as it seems like something a Cisco exam would put in a question to trip up a candidate.

 

Reviewing some verification commands and their output

 

I won’t go into details regarding the output as it is pretty self explanatory, but wanted to show the different options available to verify information, and what commands produce what information.

For “sh ether detail” I will only post the output from 1 physical interface, and 1 Port-Channel interface, because it is a monster output that isn’t necessary to post in full.

(Please excuse the terrible formatting, I am too mentally spent to make the output look as it does on the CLI)

“sh ether summ”

SW1#sh ether summ
Flags: D – down P – bundled in port-channel
I – stand-alone s – suspended
H – Hot-standby (LACP only)
R – Layer3 S – Layer2
U – in use f – failed to allocate aggregator

M – not in use, minimum links not met
u – unsuitable for bundling
w – waiting to be aggregated
d – default port

 

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

Group Port-channel Protocol Ports
——+————-+———–+———————————————–
12 Po12(SU) PAgP Fa1/0/13(P) Fa1/0/14(P) Fa1/0/15(P)
13 Po13(SU) LACP Fa1/0/1(P) Fa1/0/2(P) Fa1/0/3(P)
Fa1/0/4(P)

SW1#

“sh ether detail”

Physical Interface output

SW1#sh ether det
Channel-group listing:
———————-

Group: 12
———-
Group state = L2
Ports: 3 Maxports = 8
Port-channels: 1 Max Port-channels = 1
Protocol: PAgP
Minimum Links: 0
Ports in the group:
——————-
Port: Fa1/0/13
————

Port state = Up Mstr In-Bndl
Channel group = 12 Mode = Desirable-NonSl Gcchange = 0
Port-channel = Po12 GC = 0x000C0001 Pseudo port-channel = Po12
Port index = 0 Load = 0x00 Protocol = PAgP

Flags: S – Device is sending Slow hello. C – Device is in Consistent state.
A – Device is in Auto mode. P – Device learns on physical port.
d – PAgP is down.
Timers: H – Hello timer is running. Q – Quit timer is running.
S – Switching timer is running. I – Interface timer is running.

Local information:
Hello Partner PAgP Learning Group
Port Flags State Timers Interval Count Priority Method Ifindex
Fa1/0/13 SC U6/S7 H 30s 1 128 Any 5012

Partner’s information:

Partner Partner Partner Partner Group
Port Name Device ID Port Age Flags Cap.
Fa1/0/13 SW2 5897.1eab.c800 Fa1/0/13 3s SAC 150001

Age of the port in the current state: 0d:00h:55m:01s

Logical Interface output

SW1#sh ether det
(…)
Port-channels in the group:
—————————

Port-channel: Po13 (Primary Aggregator)

————

Age of the Port-channel = 0d:00h:01m:39s
Logical slot/port = 10/13 Number of ports = 4
HotStandBy port = null
Port state = Port-channel Ag-Inuse
Protocol = LACP
Port security = Disabled

Ports in the Port-channel:

Index Load Port EC state No of bits
——+——+——+——————+———–
0 00 Fa1/0/1 Active 0
0 00 Fa1/0/2 Active 0
0 00 Fa1/0/3 Active 0
0 00 Fa1/0/4 Active 0

Time since last port bundled: 0d:00h:01m:00s Fa1/0/4

Options for PAgP verification commands

SW1#sh pagp ?
<1-48> Channel group number
counters Traffic information
dual-active Dual-active information
internal Internal information
neighbor Neighbor information

By selecting the highlighted port-channel #, you will then have to enter one of the verification commands below it, it just specifies an individual Port-Channel to focus on.

“sh pagp internal”

SW1(config-if)#do sh pagp internal
Flags: S – Device is sending Slow hello. C – Device is in Consistent state.
A – Device is in Auto mode. d – PAgP is down
Timers: H – Hello timer is running. Q – Quit timer is running.
S – Switching timer is running. I – Interface timer is running.

Channel group 12
Hello Partner PAgP Learning Group
Port Flags State Timers Interval Count Priority Method Ifindex
Fa1/0/13 SC U6/S7 H 30s 1 128 Any 5012
Fa1/0/14 SC U6/S7 H 30s 1 128 Any 5012
Fa1/0/15 SC U6/S7 H 30s 1 128 Any 5012
SW1(config-if)#

Not too sure what a lot of this output means without further research, but as highlighted in red demonstrates, this command can be issued to find local Port Priority.

I’m not exactly sure what PAgP Port Priority is used for, but this is where it is verified, and lower is always better with STP Priority of any kind – EtherChannel included.

“sh pagp neighbor”

SW1#sh pagp nei
Flags: S – Device is sending Slow hello. C – Device is in Consistent state.
A – Device is in Auto mode. P – Device learns on physical port.

Channel group 12 neighbors
Partner Partner Partner Partner Group
Port Name Device ID Port Age Flags Cap.
Fa1/0/13 SW2 5897.1eab.c800 Fa1/0/13 16s SAC 150001
Fa1/0/14 SW2 5897.1eab.c800 Fa1/0/14 13s SAC 150001
Fa1/0/15 SW2 5897.1eab.c800 Fa1/0/15 6s SAC 150001
SW1#

Provides remote host name / MAC Address, local to remote physical interface mappings, but DOES NOT contain remote Port Priority in this “neighbor” verification command.

Options for LACP verification

SW1#sh lacp ?
<1-48> Channel group number
counters Traffic information
internal Internal information
neighbor Neighbor information
sys-id LACP System ID

Same deal with the channel-group number, just narrows down details to that specific channel-group if more than one is configured.

“sh lacp internal” – To verify local active settings for LACP Etherchannel

SW1#sh lacp internal
Flags: S – Device is requesting Slow LACPDUs
F – Device is requesting Fast LACPDUs
A – Device is in Active mode P – Device is in Passive mode

Channel group 13

Partner’s information:

LACP port Admin Oper Port Port
Port Flags Priority Dev ID Age key Key Number State
Fa1/0/1 SP 32768 5897.1eab.ce00 23s 0x0 0x1F 0x104 0x3C
Fa1/0/2 SP          0 5897.1eab.ce00 15s 0x0 0x1F 0x105 0x3C
Fa1/0/3 SP 32768 5897.1eab.ce00 13s 0x0 0x1F 0x106 0x3C
Fa1/0/4 SP 32768 5897.1eab.ce00 17s 0x0 0x1F 0x107 0x3C
SW1#

Good command to view Port Priority for LACP to see which interfaces will be used in the event of a link failure, MAC Address being used, and whatever the other stuff is!

“sh lacp neighbors” – To verify remote active settings for EtherChannel

SW1(config-if)#do sh lacp nei
Flags: S – Device is requesting Slow LACPDUs
F – Device is requesting Fast LACPDUs
A – Device is in Active mode P – Device is in Passive mode

Channel group 13 neighbors

Partner’s information:

LACP port Admin Oper Port Port
Port Flags Priority Dev ID Age key Key Number State
Fa1/0/1 SP 32768 5897.1eab.ce00 6s 0x0 0x1F 0x104 0x3C
Fa1/0/2 SP 32768 5897.1eab.ce00 0s 0x0 0x1F 0x105 0x3C
Fa1/0/3 SP 32768 5897.1eab.ce00 25s 0x0 0x1F 0x106 0x3C
Fa1/0/4 SP 32768 5897.1eab.ce00 2s 0x0 0x1F 0x107 0x3C
SW1(config-if)#

Shows of course the same information, only with LACP neighbor verification we get the remote switches Port Priority as well, whereas PAgP does NOT show that information

 

And that is it for this post!!!

 

Took me a long week of cross referencing / labbing / correcting my own information to get this post completed (and edit my previous post), glad to be moving forward onto Layer 3 EtherChannel / Load-Balancing / Testing Load-Balancing!