[c-nsp] WS-C4506 dropped links which had LACP enabled under heavy load

[Martin T]

Hi,

I made a port channel between two switches:
http://s23.postimg.org/yx3a6h1i3/port_channel_between_switches.png

As you can see, one of those is a "WS-C4506". It has a SUP V-10GE. I
looped 10GigE ports on SUP which caused heavy CPU load:

    999999999999999999
    999999999999999999
100 ##################
 90 ##################
 80 ##################
 70 ##################
 60 ##################
 50 ##################
 40 ##################
 30 ##################
 20 ##################
 10 ##################
   0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
             0    5    0    5    0    5    0    5    0    5    0    5    0
                   CPU% per hour (last 72 hours)
                  * = maximum CPU%   # = average CPU%


Either heavy CPU load or Po3(Gi2/4 and Gi4/4) link utilization because
of broadcast storm caused ports on WS-C2960S-24TS-L switch to flap.
For example:

Jun 18 00:11:52.492 UTC: %LINEPROTO-5-UPDOWN: Line protocol on
Interface GigabitEthernet1/0/25, changed state to down
Jun 18 00:11:53.881 UTC: %LINEPROTO-5-UPDOWN: Line protocol on
Interface GigabitEthernet1/0/25, changed state to up
Jun 18 00:11:54.096 UTC: %LINEPROTO-5-UPDOWN: Line protocol on
Interface GigabitEthernet1/0/27, changed state to down
Jun 18 00:11:56.492 UTC: %LINEPROTO-5-UPDOWN: Line protocol on
Interface GigabitEthernet1/0/27, changed state to up


At the same time "WS-C4506" logged nothing. Or another occasion where
port on WS-C2960S-24TS-L flapped:

Jun 18 11:56:01.191 UTC: %LINEPROTO-5-UPDOWN: Line protocol on
Interface GigabitEthernet1/0/27, changed state to down
Jun 18 11:56:11.766 UTC: %LINEPROTO-5-UPDOWN: Line protocol on
Interface GigabitEthernet1/0/27, changed state to up

..and at the same time "WS-C4506" logged:

.Jun 18 11:56:01.206 UTC: %EC-5-UNBUNDLE: Interface Gi4/4 left the
port-channel Po3
.Jun 18 11:56:06.315 UTC: %EC-5-L3DONTBNDL2: Gi4/4 suspended: LACP
currently not enabled on the remote port.
.Jun 18 11:56:11.787 UTC: %EC-5-BUNDLE: Interface Gi4/4 joined port-channel Po3


I tested with 12.2(37)SG1 and 15.0(2)SG3 IOS images. Is there a reason
to bring the line-protocol down if LACPDUs time-out/loss?


regards,
Martin


2013/6/11, Chuck Church <chuckchurch at gmail.com>:
> Hmmm.  Perhaps Cisco's implementation of LACP and etherchannel
> intentionally
> has the line-protocol drop when LACP neighbors time out, maybe that's how
> they get un-bundled?
>
> Chuck
>
> -----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> Martin T
> Sent: Tuesday, June 11, 2013 12:14 PM
> To: Aaron
> Cc: cisco-nsp
> Subject: Re: [c-nsp] WS-C4506 dropped links which had LACP enabled under
> heavy load
>
> Aaron,
>
> as far as I know, keepalive frames(EtherType 0x9000) have nothing to do
> with
> Ethernet interface "line protocol". You can connect two ports with
> keepalive
> frames disabled, but you'll still see the "line protocol" up. Cisco "line
> protocol" should be "link integrity check"
> signals sent by Ethernet transceiver circuits(PHY).
>
>
> regards,
> Martin
>
>
> 2013/6/11, Aaron <dudepron at gmail.com>:
>> Keep alives need to be generated
>>
>>
>> On Tue, Jun 11, 2013 at 8:35 AM, Martin T <m4rtntns at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> has anyone seen a behavior where Cisco WS-C4506 drops "line-protocol"
>>> on GigE ports(WS-X4306-GB module) which have LACP enabled when
>>> SUP(Sup
>>> V-10GE) CPU load is ~100%? I guess that LACP frames are processed in
>>> SUP CPU and it's normal to see LACPDUs time-out, but how can this
>>> affect interface line-protocol?
>>>
>>>
>>> regards,
>>> Martin
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>