This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

active/backup link-aggregation on ASG

Hi everyone

I got two ASG 220 units yesterday to perform some tests and decide, whether they suit our needs or not.

As part of our HA setup, we'd like to connect each ASG to one of our core switches. Using a multi-chassis environment with seperate administrative domains, we will not be able to use 802.3ad and therefore, I tried to use bonding mode 1 (active/backup).

Network design:

  SWITCH 1  ====  SWITCH 2
e0/1    e0/2           e0/1    e0/2
   |           |                  |           |
ASG1    ASG2           ASG1    ASG2
eth0     eth1             eth1     eth0
(pri)      (bkp)            (bkp)    (pri)


How to change LAG mode and setting primary interface using CLI:
cc
OBJS
itfparams
link_aggregation_group
REF_LagOne[...]
mode=1
primary=REF_ItfHwDefaultInternal
w


Here is the output after having issued the changes above:
127.0.0.1 OBJS itfparams link_aggregation_group > REF_LagOne[REF_LagOne,itfparams,link_aggregation_group] 
Logged into object 'REF_LagOne'. Use 'w' to write eventual changes.
{
 'use_carrier' => 1,
 'mode' => 1,
 'status' => 1,
 'primary' => 'REF_ItfHwDefaultInternal',
 'updelay' => 0,
 'arp_interval' => 0,
 'id' => 0,
 'miimon' => 0,
 'enforce_mac' => 0,
 'xmit_hash_policy' => 'layer2',
 'name' => 'REF_LagOne',
 'itfhw' => [
              'REF_SwQSJNTgDn',
              'REF_ItfHwDefaultInternal'
            ],
 'comment' => '',
 'ad_select' => 0,
 'arp_ip_target' => '0.0.0.0',
 'downdelay' => 0,
 'lacp_rate' => 1
}


Long story short:
The failover simply doesn't work. Tried deactivating use_carrier and going back to MIImon (100ms) with no luck. Funny thing is, that it even ignores the primary interface (set to eth0) and instead uses eth1 as primary.
Does anyone of you guys have a running LAG in active/backup configuration?

Cheers,
gartoffel


This thread was automatically locked due to age.
  • I just got a message from Astaro support:
    This is actually a bug in the middleware (CLI) and will be fixed immediately. As this is no official feature (yet), future support is limited.

    I therefore ask you to vote for all LAG modes to become an official part of the Web GUI using this link.

    Cheers and thanks,
    Manuel
  • Hi, gartoffel, and welcome to the User BB!

    Thanks for posting the result!

    Cheers - Bob
  • Hi Bob

    I assume that this will be a production environment, and that you will have Astaro Maintenance Support. Have you spoken with Astaro to be sure your setup would be eligible for support if it can be made to work?  Have you asked Astaro for guidance?

    As a matter of fact, the Presales Engineer encouraged me to open a feature request, because features that are not present in the Web GUI are not eligible for support.
    I'm a Cisco CLI guy, so this kind of freaks me out ;-)

    Isn't your problem with the failover the same one you have with using Astaro's standard LAG mode?

    No. 802.3ad is the only LAG mode that requires the switch on the other end to be aware of the LAG. All other modes are less demanding and widely used with high-availability setups in multi-chassis environments.
    Actually, all our servers are set up to use mode 1 (active/passive) and we've been happy for years now. So there goes our best practise...

    Cheers,
    Manuel
  • Hi gartoffel,

    please try the following Middleware RPM for 8.103, which should fix the issue:
    ep-mdw-8.10-13.gea3ce5a.i686.rpm
    Install with "rpm -U --force ep-mdw-8.10-13.gea3ce5a.i686.rpm" and restart you system.

    Cheers
     Ulrich
  • Hi Ulrich

    Install with "rpm -U --force ep-mdw-8.10-13.gea3ce5a.i686.rpm" and restart you system.


    Damn, your fast... Thanks a lot!
    I'll try that later today and report back immediately.

    Cheers,
    Manuel
  • Hi Ulrich

    please try the following Middleware RPM for 8.103, which should fix the issue

    Sorry, that it took me so long to get back to you. I had to perform several tests first and came across some rather strange behavior. That's why I'm still sitting in the lab after hours to make sure you can reproduce the bug...

    Test environment
          Switch
    
    port 1    port 2
       |             |
       |             |
    eth0       eth1
         ASG 220


    Primary lag0 interface is set to eth0. No further changes through cc.

    Test procedure
    1. Plug in both cables
    2. Plug out the cable of eth1 (no ping loss)
    3. Plug it back in (no ping loss)
    [You can repeat steps 2 and 3 as long as you want without further consequences. This is due having declared eth0 as primary interface] 
    4. Plug out the cable of eth0 (lost 500ms of ping)
    5. Now plug the cable of eth0 back IN (lost 40-75 seconds(!!) of ping)
    [This can be reproduces many times in a row. The timeouts vary, but I didn't find out on what it depends. Average is about 60 seconds.]

    I tested several things, but I'm pretty sure that the only way to solve this issue is to sniff using Wireshark and see whether the gratuitous ARP are being sent or not. For me, that's the only thing that makes sense.

    What do you think?

    Cheers and good night,
    Manuel
  • Hi Manuel,

    there should be no need for gratuitous ARP, because all LAG interfaces
    should have the same MAC address set.

    I'm out of office till thursday, then I can try to reproduce this...

    Cheers
     Ulrich
  • Hi Ulrich

    there should be no need for gratuitous ARP, because all LAG interfaces should have the same MAC address set.

    I disagree. Quoting the linux foundation bonding website:
    In bonding version 2.6.2 or later, when a failover occurs in active-backup mode, bonding will issue one or more gratuitous ARPs on the newly active slave. One gratutious ARP is issued for the bonding master interface and each VLAN interfaces configured above it, provided that the interface has at least one IP address configured.

    So this seems to have some kind of importance (at least in this mode) or they wouldn't mention it, right?

    I'm out of office till thursday, then I can try to reproduce this...

    I can't keep the devices until thursday, because we got them just for internal evaluation. Furthermore, I'll be on vacation until july 14th and hopefully as offline as possible ;-). But I'm looking forward to hearing from you when I'm back.

    Thanks for your efforts so far!

    Cheers,
    Manuel
  • One final though: maybe this loss of 40-75 seconds is STP related.
    Try to enable rapid STP on your switch or set updelay lag parameter via cc.

    Cheers
     Ulrich
  • One final though: maybe this loss of 40-75 seconds is STP related.

    I thought of that as well, but (R)STP is already disabled. I even enabled all debugging messages on the switch earlier today, but got nothing out of the ordinary. It has to be ASG related - we use the same technique (mode 1 LAG) on our server NICs and there it works like a charm.
    Try to enable rapid STP on your switch or set updelay lag parameter via cc.

    First, setting the updelay lag to 100ms didn't work either. But then I realized that it had to be a multiple of the miimon value so I set it to 500ms and rebooted the unit. Et voilà! No more trouble when plugging the cable back in.

    Great work Ulrich, thanks! Now this hotfix has to make it into 8.200... ;-)

    Cheers and good night,
    Manuel