cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7257
Views
0
Helpful
4
Replies

Etherchannel Trunk to AIX Issue

justinhulsman
Level 1
Level 1

I have a strange issue.  We are trying to setup a Trunk over an Etherchannel for a Cisco 4507 to a IBM AIX server.  Under what we believe to be the correct configuration, each physical link goes into a state "Waiting to be aggregated".  The AIX server is configured for 802.3ad with a PVID of 1 and tagging VLAN 141 and 142.

interface GigabitEthernet1/10

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 141,142

switchport mode trunk

no cdp enable

channel-protocol lacp

channel-group 23 mode active

spanning-tree portfast

service-policy output DBL

!

interface GigabitEthernet5/10

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 141,142

switchport mode trunk

no cdp enable

channel-protocol lacp

channel-group 23 mode active

spanning-tree portfast

service-policy output DBL

!

interface Port-channel23

switchport

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 141,142

switchport mode trunk

spanning-tree portfast

To add insult to injury, the physical ports do get aggregated when the switchport mode is set to either access dot1q-tunnel.  Neither of which allow connectivity.

4 Replies 4

Hello
Can you redo the port channel?

1) delete the port channel
2) default the physical interfaces and then JUST apply the channel mode to lacp

3) the port channel interface is then created automatically so from here apply yout trunk config which will inturn auto config the physical interfaces

4) perforn a shut/no shut on the physical interfaces

Res
Paul

Sent from Cisco Technical Support Android App


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Thanks pdriver.  I got the same issue for Po23 after rebuilding the configuration as above.

Flags:  D - down        P - bundled in port-channel

        I - stand-alone s - suspended

        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: 5

Number of aggregators:           5

Group  Port-channel  Protocol    Ports

------+-------------+-----------+-----------------------------------------------

10     Po10(SU)        PAgP      Te3/1(P)    Te3/2(P)

21     Po21(SU)        LACP      Gi6/1(P)    Gi6/2(P)    Gi6/3(P)

                                 Gi6/4(P)

22     Po22(SU)        LACP      Gi6/5(P)    Gi6/6(P)    Gi6/7(P)

                                 Gi6/8(P)

23     Po23(SD)        LACP      Gi1/10(w)   Gi5/10(w)

24     Po24(SU)        LACP      Gi1/11(P)   Gi5/11(P)

I've been doing some debugging:

debug etherchannel

debug lacp packet

debug lacp event

Does anybody know about the 3rd line from the bottom?  "got event 6(outofsync)"

May 30 13:05:18: LACP :lacp_bugpak: Receive LACP-PDU packet via Gi5/10

May 30 13:05:18: LACP : packet size: 124

May 30 13:05:18: LACP: pdu: subtype: 1, version: 1

May 30 13:05:18: LACP: Act: tlv:1, tlv-len:20, key:0xBEEF, p-pri:0x80, p:0x2, p-state:0x9D,

s-pri:0x8000, s-mac:e41f.13fa.4795

May 30 13:05:18: LACP: Part: tlv:2, tlv-len:20, key:0x17, p-pri:0x8000, p:0x72, p-state:0xC1,

s-pri:0x8000, s-mac:8843.e1b9.0900

May 30 13:05:18: LACP: col-tlv:3, col-tlv-len:16, col-max-d:0x8000

May 30 13:05:18: LACP: term-tlv:0 termr-tlv-len:0

May 30 13:05:18:     lacp_rx Gi5/10 - rx: during state CURRENT, got event 5(recv_lacpdu)

May 30 13:05:18: @@@ lacp_rx Gi5/10 - rx: CURRENT -> CURRENT

May 30 13:05:18: LACP: Gi5/10 lacp_action_rx_current entered

May 30 13:05:18: LACP :lacp_bugpak: Send LACP-PDU packet via Gi5/10

May 30 13:05:18: LACP : packet size: 124

May 30 13:05:18: LACP: pdu: subtype: 1, version: 1

May 30 13:05:18: LACP: Act: tlv:1, tlv-len:20, key:0x17, p-pri:0x8000, p:0x72, p-state:0xD,

s-pri:0x8000, s-mac:8843.e1b9.0900

May 30 13:05:18: LACP: Part: tlv:2, tlv-len:20, key:0xBEEF, p-pri:0x80, p:0x2, p-state:0x95,

s-pri:0x8000, s-mac:e41f.13fa.4795

May 30 13:05:18: LACP: col-tlv:3, col-tlv-len:16, col-max-d:0x8000

May 30 13:05:18: LACP: term-tlv:0 termr-tlv-len:0

May 30 13:05:18:     lacp_mux Gi5/10 - mux: during state ATTACHED, got event 6(outof_sync)

May 30 13:05:18: @@@ lacp_mux Gi5/10 - mux: ATTACHED -> ATTACHED

May 30 13:05:18: LACP: Gi5/10 lacp_action_mx_in_attached entered

Hello

Are you sure the ibm server supports lacp? Have you tried settingbthis up without any link control protocol?

Res
Paul


Sent from Cisco Technical Support Android App


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

I figured out what was going on the other day, so I figured I would update the thread just in case someone was having an issue.  After rebooting the AIX server and issuing "debug lacp packet" on the switch, I got the following hit from the AIX server sending a LACP PDU.

May 30 14:49:24: LACP: Act: tlv:1, tlv-len:20, key:0xBEEF, p-pri:0x80, p:0x1, p-state:0xDD,

s-pri:0x8000, s-mac:e41f.13fa.4795

May 30 14:49:24: LACP: Part: tlv:2, tlv-len:20, key:0x0, p-pri:0x0, p:0x0, p-state:0x0,

s-pri:0x0, s-mac:0000.0000.0000

In this debug, the first two lines represent the state that the server sees itself as having.  The most important part of the first two lines is p-state: 0xDD.  Putting the hex into binary and then comparing the binary to the 802.1ax standard's AdminState I know that the server is configured as an Active LACP member with a long timeout interval.  Also, it views itself as not aggregated, sync'd, accepting incoming LACP PDUs, and sending LACP PDUs.

Lines 3 and 4 show the state that the server sees it's LACP neighbor.  Looking at the s-mac value, it's evident that it has not seen any of the LACP PDUs that the switch has been sending.

Here is what I've known about this issue.  Changing the etherchannel's mode to access instead of trunk allows the LACP to negotiate.  Why would this be?  The LACP PDUs would no longer be tagged...  But, with the following configuration, why would the native VLAN be tagged?

interface GigabitEthernet1/10

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,141,142

switchport mode trunk

channel-protocol lacp

channel-group 23 mode active

!

interface GigabitEthernet5/10

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,141,142

switchport mode trunk

channel-protocol lacp

channel-group 23 mode active

!

interface Port-channel23

switchport

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,141,142

switchport mode trunk

Because in the global configuration "vlan dot1q tag native" is in the running config.  Configuring the interfaces with the "no switchport trunk native vlan tag" solved the issue because it would no longer be tagging VLAN 1 (the default native VLAN) thereby allowing the AIX server to see the LACP PDU's.

Review Cisco Networking products for a $25 gift card