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.
Parents
  • 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
Reply
  • 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
Children
No Data