bond из LACP'ов, захотелось странного

Подумай, что у тебя будет происходить с MAC-адресами, и как балансировать трафик на вышестоящем(их) устройствах. Возможно лучшим решением будет закупка отдельного балансировщика.

расскажи лучше как LACP поднимал

Если LACP работает нормально, то и так будет и резервирование и балансировка, и соединение не порвется, пока не отвалится последняя сетевуха из бондинга, так что нет никагого смысла в active-backup. На практике у меня оно нормально работало только на двух линуксах, соединенных напрямую без свитча, и между свитчами одного вендора (пробовал на HP, 3Com и AT).

Я советую агрегировать все доступные сетевухи в один LACP, либо делать тоже самое с balance-alb, если начнутся проблемы с LACP.

При объединении в бонд, виртуальному интерфейсу назначается MAC одного из слейвов, так-что тут проблем быть не должно. Трафик по-идее должен в нормальном режиме ходить через LACP на оптических сетевухах, а в случае поломки обоих волокон или оптических сетевух, переложиться в LACP на гигабитных медных сетевухах, образовав деградацию скорости, вместо обрыва коннекта. То-есть, логических проблем не вижу. Ключевой вопрос, могут-ли слейвами выступать другие LACP'ы?

targitaj, вот мой /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual
        mtu 8996

auto eth1
iface eth1 inet manual
        mtu 8996

auto bond0
allow-vmbr1 bond0
iface bond0 inet manual
        ovs_bonds eth0 eth1
        ovs_type OVSBond
        ovs_bridge vmbr1
        ovs_options lacp=active bond_mode=balance-slb
        mtu 8996
        up ifconfig vmbr1 up

auto vmbr1
iface vmbr1 inet manual
        ovs_type OVSBridge
        ovs_ports bond0 vmbr1_5 vmbr1_23
        mtu 8996

auto vmbr1_23
allow-vmbr1 vmbr1_23
iface vmbr1_23 inet static
        address  10.100.23.2
        netmask  255.255.255.0
        ovs_type OVSIntPort
        ovs_bridge vmbr1
        ovs_options tag=23
        hwaddress 72:2b:01:5e:05:b9
        mtu 8996

somestuff, я не хочу в один LACP мешать десятки и гигабитки, потому-что при этом часть коннектов пойдёт по гигабитным линкам, а мне этого не нужно, мне нужно получить деградацию скорости, вместо потери связности только при поломке волокон на десятках (так технологически сложилось, что волокна идут все рядом от серверов до коммутаторов, поэтому есть шанс, что если их сломают неосторожным действием, то сломают все сразу, например уронят что-то тяжёлое).

со стороны свитча что-то делал?

Можно попробовать teaming, который красная шапка продвигает вместо bonding. Там можно указывать приоритет портов. Ну или собрать тестовый стенд и на практике выяснить, что будет, если сделать active-backup из LACP.

targitaj, да, собрал на циске транк с LACP'ом

interface Port-channel4
 description TrunkLacp
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 23,25
 switchport mode trunk
!
interface FastEthernet0/21
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 23,25
 switchport mode trunk
 channel-group 4 mode active
!
interface FastEthernet0/22
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 23,25
 switchport mode trunk
 channel-group 4 mode active

somestuff, вот тестовую лабу собрать, к сожалению пока особо не на чем, потому и спрашиваю здесь, собственно, а за наводку на teaming спасибо, погуглю на эту тему.

Ты хочешь странного, я думаю. Незачем усложнять схему - у тебя и так есть отказоустойчивость, нахрена такого уродца городить? Keep it simple, stupid.

somestuff, я не хочу в один LACP мешать десятки и гигабитки,

Так речь-то не о том. Зачем тебе LACP на гигабитках, если плюс одна десятка всё это перекроет ? Гигабитки просто вытащи и используй где-нибудь ещё.

Гигабитки там встроенные, их не вытащить (без паяльника, во всяком случае), так почему бы их не использовать в благих целях?

Гигабитки там встроенные, их не вытащить

Понятно. Тогда не знаю. Но, думается, что головной боли это больше создаст, чем уменьшит.