Jestli-že používáš bonding v režimu active-backup, a to podpořený pomocí ARP monitoringu, tak ten je v ROSu zprasen (včetně ROS6.11rc1). A pokud ho musím dát nad VLANy, tak kraví totálně. Zrovna jsem je za to drbal místo předkrmu.
Pánové totiž testovací ARP dotazy tlačí do všech portů se stejnou zdrojovou MAC adresou, ale přijímají na tu MAC provoz jen na master portu, takže to jakž tak funguje jen v specifické konfiguraci nastavení:
/interface bonding add arp-interval=500ms arp-ip-targets=192.168.88.1,192.168.88.2 down-delay=300ms up-delay=300ms \
link-monitoring=arp mode=active-backup name=bonding1 primary=ether1 slaves=ether2,ether1
Jde o tu sekvenci primary=ether1 slaves=ether2,ether1 - jakákoliv jiná, nebo bez master portu, vede ke značné ztreátovosti. I tato ztrátuje něco málo při intenzivním provozu do routeru. Pomíjím, že u paranoidněji nastavených switchů vede k zablokování portů pro přeskakování MAC z portu na port (a přitom RB stejně poslouchá jen na jednom). Totálně i kašlou na to, jakým portem se jim ty testovací ARP odpovědi vrací...
Edit - takže pokud se dá bond až nad VLANu, něco jako:
/interface vlan
add interface=ether1 l2mtu=1596 name=e1.vlan1 vlan-id=1
add interface=ether2 l2mtu=1596 name=e2.vlan1 vlan-id=1
/interface bonding
add arp-interval=500ms arp-ip-targets=192.168.88.1,192.168.88.2 down-delay=300ms link-monitoring=arp mode=active-backup name=bonding1
primary=e1.vlan1 slaves=e2.vlan1,e1.vlan1 up-delay=300ms
tak ROS dělá to, že neustále přehazuje, která linka v bondu je aktivní. A to tak, že primární je aktivní trojnásobek arp-interval a sekundární po dobu arp-interval. A dělá to bez ohledu na to, zda ty linky pod tím fyzicky ne/fungují. V kombinaci s tím, že neposílá při změně aktivní linky gratuitous ARP na právě vybranou linku, tak to pak v podstatě nefunguje, ať linky ne/jsou funkční. :-)
