Какой протокол динамической маршрутизации окажется оптимальным?

Question

[Дмитрий]

Если немного упрощенно изложить задачу, то она следующая. Есть несколько физических серверов с Linux, имеющих по два сетевых адаптера, и два коммутатора, в каждый из которых подключен один из эзернет-портов серверов. Свичи осуществляют коммутацию подсетей 172.16.1.0/24 и 172.16.2.0/24, в каждой из которых у серверов есть ip-адреса. Также на каждом из серверов назначен локальный ip-адрес, не привязанный к конкретному сетевому адаптеру, из диапазона 172.16.0.0/24, с маской /32 (посредством создания бриджа, в который не добавлялись физические интерфейсы).

Нужно выбрать протокол динамической маршрутизации, который позволит обеспечить доступность всех локальных ip в 172.16.0.X с каждого из серверов, с минимальным временем перестроения (желательно не более 10 секунд) в случае частичной потери связности, и присутствующий "из коробки" в пакетах FRR или Bird.
К сожалению, использовать Bonding/LACP в конкретном случае не получится, поэтому приходится искать, как обеспечивать возможность failover уровнем выше.

Comments

[Армянское Радио]

Ну настройте OSPF (Quagga) да посмотрите. LACP вам за неуплату выключили?

[Дмитрий]

Армянское Радио, смотрю, но узнать мнение других не будет лишним. Чтобы собрать LACP, нет правильного сетевого оборудования.

Answer 1

[Станислав Бодро́в]

Свичи осуществляют коммутацию подсетей 172.16.1.0/24 и 172.16.2.0/24, в каждой из которых у серверов есть ip-адреса.

У тебя коммутаторы L2/L3 и на них настроена маршрутизация на L3? Если так, то надо смотреть на коммутаторах настройки, потому что они являются шарнирами между разными сетями. Если они у тебя работают по L2, тогда доступ у тебя полный.

Comments

[Дмитрий]

Коммутаторы L2, и прямого линка между ними нет. Нужно обеспечить маршрутизацию между 172.16.0.1, 172.16.0.2, 172.16.0.3 с резервированием на случай падения одного из коммутаторов.

[Станислав Бодро́в]

Дмитрий, по схеме могу только гадать где стоят и как подключены коммутаторы. Резервирование возможно путём наращивания числа узлов, которые могут отказать. Что-то мне подсказывать, что у тебя топология Шина на уровне L3 и заморочки с простыми, скорее всего неуправляемыми коммутаторами не нужны.

[Дмитрий]

Прочитайте вопрос внимательнее. Мне нужно не зарезервировать узлы, а обеспечить отказоустойчивость сетевой доступности между ними, причем кластерному сервису, который там будет крутиться, можно указать только один ip-адрес для каждой ноды. Какие конкретно используются коммутаторы, не столь важно, достаточно знать, что L3-маршрутизацию (и как следствие, OSPF, RIP, BGP и т.д.) они не умеют, а так же они не стекируемые, что означает, что LACP тоже отпадает как средство резервирования. К сожалению, "плясать" приходится от имеющегося оборудования.