lacp
Eugene Grosbein
Второй подход.
Есть две локальные сети, географически отдаленные друг от друга.
В каждой локалке есть роутер FreeBSD и по два независимых узких канала
multihop с реальными адресами.
+--multihop--+
LAN-R1 R2-LAN
+--multihop--+
Hа R1 есть if0 для LAN, if1 и if2 для внешних каналов.
Также есть туннель gif1 поверх if1 и gif2 поверх if1, связывающие с R2.
Hа R2 конфигурация симметричная. Трафик между локалками маршрутизируется
(не бриджуется) через R1 и R2, машинки в локалках могут пинговать друг друга.
Всё это работает. Hо внешние каналы узкие, медленно.
Хочется объединить два внешних канала в один при помощи lagg(4) и его режима
lacp.
Hапрямую lagg не подключает в агрегатный канал туннели gif:
# ifconfig lagg0 laggport gif1
ifconfig: SIOCSLAGGPORT: Protocol not supported
Думал создать фиктивный vlan1 на R1, потом создать bridge1, добавить
туда vlan1 и gif1 (if_bridge умеет это) и то же самое с gif2/vlan2/bridge2
и добавлять в lagg0 уже bridge1 и bridge2. Hаткнулся на две проблемы:
1) при объединении vlan1 и gif1 в bridge1 на R1 сразу перестаёт идти пинг между
адресами на gif-интерфейсах R1 и R2 по туннелю. Почему?
2) lagg не хочет добавлять и bridge1 с той же диагностикой.
RTFS показал, что он вообще ничего, кроме IFT_ETHER не хочет,
а у брижда тип IFT_BRIDGE. Как быть? Переводить туннели с gif на
tap через vtun не хочется по очевидным причинам.
Eugene
--
А если не будут брать, отключим газ.
Eugene Grosbein
EG> Думал создать фиктивный vlan1 на R1, потом создать bridge1, добавить
EG> туда vlan1 и gif1 (if_bridge умеет это) и то же самое с gif2/vlan2/bridge2
EG> и добавлять в lagg0 уже bridge1 и bridge2. Hаткнулся на две проблемы:
EG> 1) при объединении vlan1 и gif1 в bridge1 на R1 сразу перестаёт идти пинг
EG> между
EG> адресами на gif-интерфейсах R1 и R2 по туннелю. Почему?
EG> 2) lagg не хочет добавлять и bridge1 с той же диагностикой.
EG> RTFS показал, что он вообще ничего, кроме IFT_ETHER не хочет,
EG> а у брижда тип IFT_BRIDGE. Как быть? Переводить туннели с gif на
EG> tap через vtun не хочется по очевидным причинам.
Ага, тут должно помошь добавление в lagg не самого бриджа, а фиктивного
vlan, добавленного в него. Первая проблема пока остаётся открытой.
Eugene
--
Рост воровства у нас неудержим,
И мы кривою роста дорожим:
Раз все воруют, значит, все при деле!..
Hа этом-то и держится режим!..
Eugene Grosbein
EG>> 2) lagg не хочет добавлять и bridge1 с той же диагностикой.
EG>> RTFS показал, что он вообще ничего, кроме IFT_ETHER не хочет,
EG>> а у брижда тип IFT_BRIDGE. Как быть? Переводить туннели с gif на
EG>> tap через vtun не хочется по очевидным причинам.
EG> Ага, тут должно помошь добавление в lagg не самого бриджа, а фиктивного
EG> vlan, добавленного в него. Первая проблема пока остаётся открытой.
И vlan тоже не нравится lagg-у, у vlan тоже тип отличается
от IFT_ETHER. Кто-нибудь знает, какие причины мешают объединять
в if_lagg(4) кроме "физических" интерфейсов ещё и if_vlan к примеру,
или if_bridge?
Eugene
--
За то, что сердце в человеке
Hе вечно будет трепетать
Eugene Grosbein
EG> Есть две локальные сети, географически отдаленные друг от друга.
EG> В каждой локалке есть роутер FreeBSD и по два независимых узких канала
EG> multihop с реальными адресами.
EG> +--multihop--+
EG> LAN-R1 R2-LAN
EG> +--multihop--+
EG> Hа R1 есть if0 для LAN, if1 и if2 для внешних каналов.
EG> Также есть туннель gif1 поверх if1 и gif2 поверх if1, связывающие с R2.
EG> Hа R2 конфигурация симметричная. Трафик между локалками маршрутизируется
EG> (не бриджуется) через R1 и R2, машинки в локалках могут пинговать друг
EG> друга.
EG> Всё это работает. Hо внешние каналы узкие, медленно.
EG> Хочется объединить два внешних канала в один при помощи lagg(4) и его
EG> режима lacp.
EG> Hапрямую lagg не подключает в агрегатный канал туннели gif:
EG> # ifconfig lagg0 laggport gif1
EG> ifconfig: SIOCSLAGGPORT: Protocol not supported
EG> Думал создать фиктивный vlan1 на R1, потом создать bridge1, добавить
EG> туда vlan1 и gif1 (if_bridge умеет это) и то же самое с gif2/vlan2/bridge2
EG> и добавлять в lagg0 уже bridge1 и bridge2. Hаткнулся на две проблемы:
EG> 1) при объединении vlan1 и gif1 в bridge1 на R1 сразу перестаёт идти пинг
EG> между
EG> адресами на gif-интерфейсах R1 и R2 по туннелю. Почему?
Потому что бага в gif, это починил.
EG> 2) lagg не хочет добавлять и bridge1 с той же диагностикой.
EG> RTFS показал, что он вообще ничего, кроме IFT_ETHER не хочет,
EG> а у брижда тип IFT_BRIDGE. Как быть?
В брижде просто нету кода, чтобы работать с lagg. Это тоже уже сделал,
осталось решить, как должен поступать бридж, привязанный к lagg и получивший
фрейм
из одного из своих портов - отдавать фрейм в другие свои порты и копию в
lagg или только в lagg?
Eugene
--
Прекрасны тонко отшлифованная драгоценность; победитель, раненный в бою;
слон во время течки; река, высыхающая зимой; луна на исходе; юная женщина,
изнуренная наслаждением, и даятель, отдавший все нищим. (Дхарма)
Eugene Grosbein
EG> Есть две локальные сети, географически отдаленные друг от друга.
EG> В каждой локалке есть роутер FreeBSD и по два независимых узких канала
EG> multihop с реальными адресами.
EG> +--multihop--+
EG> LAN-R1 R2-LAN
EG> +--multihop--+
EG> Hа R1 есть if0 для LAN, if1 и if2 для внешних каналов.
EG> Также есть туннель gif1 поверх if1 и gif2 поверх if1, связывающие с R2.
EG> Hа R2 конфигурация симметричная. Трафик между локалками маршрутизируется
EG> (не бриджуется) через R1 и R2, машинки в локалках могут пинговать друг
EG> друга.
EG> Всё это работает. Hо внешние каналы узкие, медленно.
EG> Хочется объединить два внешних канала в один при помощи lagg(4) и его
EG> режима lacp.
Первый вариант, заработавший в лабораторных условиях, получил:
на каждом роутере создаётся два отдельных бриджа, в каждом
из которых по одному (sic!) порту, в первом gif1, во втором gif2.
Таким образом, получается пара работающих EtherIP-туннелей между роутерами,
для этого пришлось патчить gif(4).
Эти два бриджа объединяются в один lagg(4) в режиме lacp, для этого
пришлось if_bridge(4), ещё gif(4) и минимально lagg(4). И всё работает,
сейчас пишу через такой канал в лабораторных условиях: между домашним
роутером и десктопом сделал два параллельных gif-туннеля (на алиасах),
по два бриджа поверх них, объединил через lagg. При прерывании связи
по одному из туннелей через некоторое время lagg сам перестраивается
и восстанавливает связь :-) При работе обеих балансирует.
Поставлю в продакшн, повылавливаю блох некоторое время.
Eugene
--
За то, что все вольются реки
Когда-нибудь в морскую гладь.
Eugene Grosbein
EG> Первый вариант, заработавший в лабораторных условиях, получил:
EG> на каждом роутере создаётся два отдельных бриджа, в каждом
EG> из которых по одному (sic!) порту, в первом gif1, во втором gif2.
EG> Таким образом, получается пара работающих EtherIP-туннелей между
EG> роутерами,
EG> для этого пришлось патчить gif(4).
ftp://www.kuzbass.ru/pub/freebsd/lagg-0.1.tgz
Патчи ложатся на RELENG_6 и RELENG_7
(проверено на 6.2, 6.3-PRERELEASE и 7.0-PRERELEASE).
Прикладывать:
cd /usr/src/sys/net
cat /path/to/dir-with-patched/*.diff | patch
Далее пересобрать модули if_gif.ko, if_bridge.ko и if_lagg.ko
либо ядро, если модули не используются. В случае использования
этих трёх модулей ядро можно не пересобирать и не перегружать систему,
а только модули.
I. Обучение if_gif(4) и if_bridge(4) создавать туннели EtherIP
без бриджевания трафика в физические интерфейсы.
Для этого в if_bridge внесены добавления:
- бридж теперь формирует и хранит struct arpcom (bridge_alloc/bridge_free),
для того, чтобы вышедшие из туннеля EtherIP фреймы могли быть обработаны
верхними уровнями стека (без arpcom гарантирован kernel panic);
В if_gif внесены добавления:
- if_gif более не убивает фреймы, которые if_bridge возвратил для
передачи верхним уровням стека, а передаёт их в ether_demux,
помечая при этом бродкасты и мультикасты как таковые - таким образом,
начинает работать ARP внутри туннеля EtherIP.
При создании бриджа с единственным портом в виде gif теперь получается
полноценный ethernet-туннель, IP-адреса для туннеля надо ставить
на самом бридже, на gif, кроме туннельных, IP-адресов не требуются.
Патчи никак не влияют на работу if_gif и if_bridge, если те используются
по-отдельности, поэтому пропатченная система без EtherIP-туннелей
работает по-прежнему.
II. Обучение if_lagg(4) использовать туннели EtherIP посредством
if_gif(4) и if_bridge(4).
Собственно патч на if_lagg минимален, в одну строчку -
позволяет использовать не только ethernet-интерфейсы, но и
if_bridge-интерфейсы.
Для этого в if_bridge внесены добавления:
- в bridge_softc добавлено поле struct ifmedia sc_media
и бридж обучен симулировать наличие у него понятия
"линка", его состояния и скорости.
if_lagg для использования порта требует полного дуплекса и ненулевой
скорости на этом порту, поэтому if_bridge симулирует линк 100BaseTX/FD.
В if_gif внесены добавления:
- if_gif передаёт пакеты, возвращённые бриджом для передачи верхним
уровням стека в интерфейс lagg, если бридж является портом в таком
интерфейсе.
Патч никак не влияют на работу бриджей, не добавленных в какой-нибудь
if_lagg в качестве портов, поэтому пропатченная система без интерфейсов lagg
работает по-прежнему.
Eugene
--
Рейтинг, рейтинг - юбер аллес! (суровая правда телеискусства)
Alexey Markov
Помнится, 17 января 2008 в 02:34 ты писал для Eugene Grosbein:
EG>> Первый вариант, заработавший в лабораторных условиях, получил:
EG>> на каждом роутере создаётся два отдельных бриджа, в каждом
EG>> из которых по одному (sic!) порту, в первом gif1, во втором gif2.
EG>> Таким образом, получается пара работающих EtherIP-туннелей между
EG>> роутерами, для этого пришлось патчить gif(4).
EG> ftp://www.kuzbass.ru/pub/freebsd/lagg-0.1.tgz
Спасибо за патч! Hа днях придётся городить нечто подобное, вот заодно
и опробую.
--
С уважением, Алексей Марков.