LACP Cisco-Foundry

Discussion in 'Cisco' started by helmers, Jun 7, 2009.

  1. helmers

    helmers Guest

    Hi,
    we have a Problem with LACP between a Cisco Catalyst 6509 an a Foundry
    FastIron Super-X.

    The LACP is build of 2 Links.
    If wee unplug the first (primary) port of the LACP-Channel we will not
    see any traffic disruption. Also if we replug the port, no traffic
    disruption will happen. That's like expected.

    If we unplug the second port, the traffic will not be disrupted in the
    first moment. But after roundabout 90 seconds the traffic will stop an
    will come back again after other 35 seconds. If we replug the link, the
    traffic will stop again for 35 seconds.
    Any Idea?

    We can see that the LACP-Channel is build on both sides. So this is not
    a native Spanning Tree event, as it ca be expected by the 35 seconds
    downtime. Furthermore we are using Rapid Spanning Tree.


    !!!!!!!Config Cisco:
    !
    interface Port-channel57
    switchport
    switchport trunk encapsulation dot1q
    switchport mode trunk
    switchport nonegotiate
    !
    interface TenGigabitEthernet6/1
    switchport
    switchport trunk encapsulation dot1q
    switchport mode trunk
    switchport nonegotiate
    channel-group 57 mode active
    !
    interface TenGigabitEthernet6/1
    switchport
    switchport trunk encapsulation dot1q
    switchport mode trunk
    switchport nonegotiate
    channel-group 57 mode active



    !!!!!!!Config Foundry:
    !
    interface ethernet 6/1
    link-aggregate configure key 10057
    link-aggregate active
    !
    interface ethernet 6/2
    link-aggregate configure key 10057
    link-aggregate active
    !
     
    helmers, Jun 7, 2009
    #1
    1. Advertising

  2. helmers wrote:
    > Hi,
    > we have a Problem with LACP between a Cisco Catalyst 6509 an a Foundry
    > FastIron Super-X.
    >
    > The LACP is build of 2 Links.
    > If wee unplug the first (primary) port of the LACP-Channel we will not
    > see any traffic disruption. Also if we replug the port, no traffic
    > disruption will happen. That's like expected.
    >
    > If we unplug the second port, the traffic will not be disrupted in the
    > first moment. But after roundabout 90 seconds the traffic will stop an
    > will come back again after other 35 seconds. If we replug the link, the
    > traffic will stop again for 35 seconds.
    > Any Idea?
    >
    > We can see that the LACP-Channel is build on both sides. So this is not
    > a native Spanning Tree event, as it ca be expected by the 35 seconds
    > downtime. Furthermore we are using Rapid Spanning Tree.


    Interesting. 90 seconds is 3 times Slow Hello timer (30sec). It looks
    like switches don't react on port going down and rely on LACP hello to
    detect the failure. IIRC as minimum on Cisco side STP event is quite
    expected - when you have only one port left in aggregate it will revert
    to regular port and go through normal STP transition.

    debug lacp, debug spanning-tree and equivalents on Foundry side should
    help to figure out what is going on.

    Regards,
    Andrey.
     
    Andrey Tarasov, Jun 7, 2009
    #2
    1. Advertising

  3. helmers

    cutetplt

    Joined:
    Jan 30, 2009
    Messages:
    11
    Location:
    Bangkon, Thailand
    Hi mate!

    I got the problem like this but different model (ServerIron 4G-PREM). I did the LAB testing for fast convergent “fast uplink-span”. It’s totally different from Cisco STP. When the forwarding port is down, blocking port will be turned on in 4 seconds. But it’ll go down for 20 seconds again when the down port go up.

    In my opinion, Foundry has the problem with Spanning tree function. If you guys have any idea please let us know. Thanks.

    Cheer,
    Tony
     
    cutetplt, Jun 8, 2009
    #3
  4. helmers

    bod43 Guest

    On 7 June, 17:33, Andrey Tarasov <> wrote:
    > helmers wrote:
    > > Hi,
    > > we have a Problem with LACP between a Cisco Catalyst 6509 an a Foundry
    > > FastIron Super-X.

    >
    > > The LACP is build of 2 Links.
    > > If wee unplug the first (primary) port of the LACP-Channel we will not
    > > see any traffic disruption. Also if we replug the port, no traffic
    > > disruption will happen. That's like expected.


    > when you have only one port left in aggregate it will revert
    > to regular port and go through normal STP transition.


    This was mentioned here a while back. I don't believe it!

    If true would make the use of dual channel etherchannel for
    redundant link less than useful. I have used such links and
    never observed this behaviour. It would be astonishing to me
    if it had been present and in all of the cases I had worked on
    had never been observed. There seems no need for this
    behaviour and has obvious disadvantages, why would cisco
    put it in?

    Unfortunately I cannot do test at present. Maybe behaviour is
    platfrom dependent which would explain the differing observations.

    Ah!, maybe LACP is different from PAgP? I have not used
    LACP much.
     
    bod43, Jun 11, 2009
    #4
  5. bod43 wrote:

    >>> we have a Problem with LACP between a Cisco Catalyst 6509 an a Foundry
    >>> FastIron Super-X.
    >>> The LACP is build of 2 Links.
    >>> If wee unplug the first (primary) port of the LACP-Channel we will not
    >>> see any traffic disruption. Also if we replug the port, no traffic
    >>> disruption will happen. That's like expected.

    >
    >> when you have only one port left in aggregate it will revert
    >> to regular port and go through normal STP transition.

    >
    > This was mentioned here a while back. I don't believe it!


    You don't have to believe. It's quite possible to touch and see it.

    > If true would make the use of dual channel etherchannel for
    > redundant link less than useful. I have used such links and
    > never observed this behaviour. It would be astonishing to me
    > if it had been present and in all of the cases I had worked on
    > had never been observed. There seems no need for this
    > behaviour and has obvious disadvantages, why would cisco
    > put it in?
    >
    > Unfortunately I cannot do test at present. Maybe behaviour is
    > platfrom dependent which would explain the differing observations.
    >
    > Ah!, maybe LACP is different from PAgP? I have not used
    > LACP much.


    More important question is was PAgP or LACP used on those links? "mode
    on" doesn't use either one.

    Regards,
    Andrey.
     
    Andrey Tarasov, Jun 11, 2009
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roberto Taccon

    etherchannel (pagp or lacp) + trunk

    Roberto Taccon, Feb 17, 2004, in forum: Cisco
    Replies:
    2
    Views:
    9,251
    zillah
    Nov 9, 2006
  2. eodjack

    LACP on Cisco IEGSM's

    eodjack, Feb 13, 2008, in forum: Cisco
    Replies:
    0
    Views:
    2,443
    eodjack
    Feb 13, 2008
  3. Usenet
    Replies:
    1
    Views:
    12,563
    Martin Bilgrav
    Apr 7, 2008
  4. jtlau45
    Replies:
    0
    Views:
    3,222
    jtlau45
    May 13, 2010
  5. Jimmy Gardner

    LACP Aggregate Issues - Sun -> Cisco

    Jimmy Gardner, Jul 6, 2011, in forum: Cisco
    Replies:
    0
    Views:
    1,478
    Jimmy Gardner
    Jul 6, 2011
Loading...

Share This Page