[tt128]

Всем привет.

 

Есть такая схемка:

 

Собственно у R1 есть два пути к R4 через R2 или через R3

Везде бегает L2, тоесть все линки это etherIP туннели.

На R2 и R3 настроены бриджи объединяющие два сегмента.

 

Все вобщем то прекрасно, но хочется сделать агрегирование, ибо линки не сильно быстрые.

На всех тазиках стоит БЗД.

На R1 и R4 сделаны lagg0 ифейсы:

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
media: Ethernet autoselect
status: active
laggproto loadbalance lagghash l2,l3,l4
laggport: tap1 flags=4<ACTIVE>
laggport: tap0 flags=4<ACTIVE>

 

Бздя судя по манам умеет агрегировать несколькими способами:

 

failover
fec/loadbalance
roundrobin
lacp

 

Собственно можно сказать что все кроме LACP работает корректно.

Если ставим на R1 и R4 ifconfig lagg0 laggproto lacp

то линка нету такое ощущение что не проходят LACPDU

status: active
laggproto lacp lagghash l2,l3,l4
laggport: tap1 flags=0<>
laggport: tap0 flags=0<>

 

и флаги кажет пустые....

 

Собственно гложет меня мысль, что я чего-то важного недопонимаю :)))

Подскажите плз вообще LACP в такой конфигурации будет работать?

[secandr]

Поднимите третий уровень и поставьте балансировку по OSPF, допустим.

[tt128]

Да, L3 - скука :))

Хочеца больше L2 секаса :))

В данном случае это скорее не для решения конкретной задачи, а для понимания теоретических возможностей.

Хочется понять, в принципе LACP должен работать в таком случае или нет.

[zhenya`]

если промежуточные узлы будут пропускать через себя лацпбпду, то все взлетит

[tt128]

Да вот в том то и проблема, непонятно почему R2 и R3 не пропускают LACPDU.

Конфиг бриджа стандартный:

bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 02:89:5e:bb:3f:02
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: tap6 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
        ifmaxaddr 0 port 17 priority 128 path cost 2000000
member: tap4 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
        ifmaxaddr 0 port 19 priority 128 path cost 2000000

 

Нагуглил тут одну ссылочку https://forums.freebsd.org/viewtopic.php?&t=19278

Собственно там тоже решения нету, но советуют на промежуточных R2 и R3 сделать ифейсы lagg0 lagg1 и уже их добавлять в бридж.

Хотя я не вижу в этом смысла особенно, но попробовал, - как и ожидалось не пашет.

 

На R1 и R4 по прежнему линки не активны

status: active
laggproto lacp lagghash l2,l3,l4
laggport: tap1 flags=0<>
laggport: tap0 flags=0<>

 

Кстати кто нибудь знает можно ли tcpdump-ом поглядеть LACPDU или я глупости говорю?

       tcpdump -n -e -i lagg0 

 

молчит совсем.

[NiTr0]

Хочется понять, в принципе LACP должен работать в таком случае или нет.

Если R2,R3 не льют и не получают из сети никакого трафика (т.е. служат тупыми мостами), и если пропускают LACPDU пакеты - скорее всего взлетит. Бридж по идее не должен ничего фильтровать.

Но я та понимаю, первое условие не выполняется (ибо не от скуки же промежуточные хосты воткнуты).

[nnm]

Подскажите плз вообще LACP в такой конфигурации будет работать?

 

Согласно стандартам, bridge не может транслировать LACP PDU из одного интерфейса в другой. В операторских коробках могут быть опции, отключающие такую фильтрацию, но в BSD их похоже нет.

Edited April 4, 2014 by nnm

[tt128]

Если R2,R3 не льют и не получают из сети никакого трафика (т.е. служат тупыми мостами), и если пропускают LACPDU пакеты - скорее всего взлетит. Бридж по идее не должен ничего фильтровать.

Но я та понимаю, первое условие не выполняется (ибо не от скуки же промежуточные хосты воткнуты).

 

Да вы все верно понимаете :))

Собственно вся загвоздка в пропуске LACP PDU через bridge.

 

Согласно стандартам, bridge не может транслировать LACP PDU из одного интерфейса в другой. В операторских коробках могут быть опции, отключающие такую фильтрацию, но в BSD их похоже нет.

 

Подскажите пожалуйста согласно каким именно стандартам, а то сходу не получилось найти.

 

Ну и собственно продолжение экпериментов.

Совсем забыл указать что БЗД -то у меня на R1 - 10.0-RELEASE, а вот на R4 - 8.3-RELEASE

 

В 10-ке появился syctl net.link.lagg.lacp.debug=1

врубаем его и при старте lagg0 вываливает это:

lagg0: link state changed to DOWN
lagg0: link state changed to UP
can't re-use a leaf (lacp_strict_mode)!
can't re-use a leaf (rx_test)!
can't re-use a leaf (tx_test)!
tap1: promiscuous mode enabled
tap1: promiscuous mode disabled
tap0: promiscuous mode enabled
tap0: promiscuous mode disabled
lagg0: link state changed to DOWN
tap0: link state changed to DOWN
tap0: Ethernet address: 00:bd:37:a2:4f:00
tap0: link state changed to UP
lagg0: link state changed to UP
tap0: media changed 0x0 -> 0x20, ether = 1, fdx = 0, link = 1
tap0: partner timeout changed
tap0: -> UNSELECTED
tap1: media changed 0x0 -> 0x20, ether = 1, fdx = 0, link = 1
tap1: partner timeout changed
tap1: -> UNSELECTED
lacp_select_tx_port: no active aggregator

 

начинаю гуглить на тему lacp_strict_mode и нахожу интересную штуку:

kern/185967: Link Aggregation LAGG: LACP not working in 10.0

 

и соответствующий патчик:

http://lists.freebsd.org/pipermail/freebsd-net/2014-February/037745.html

 

Вобщем, ставим патч, пересобираем ядро, грузимся, проверяем:

 

tap1: collecting disabled

tap0: collecting disabled

lagg0: link state changed to DOWN

lagg0: link state changed to UP

tap0: media changed 0x0 -> 0x20, ether = 1, fdx = 0, link = 1

tap0: partner timeout changed

tap0: -> UNSELECTED

tap1: media changed 0x0 -> 0x20, ether = 1, fdx = 0, link = 1

tap1: partner timeout changed

tap1: -> UNSELECTED

lacp_select_tx_port: no active aggregator

 

что-то безрезультатно…

Собственно позже для чистоты эксперимента я попробовал все это на между двумя FreeBSD-9

Все то же самое, bridge не пропускает LACP PDU.

Может ему не нравится то что у tap интерфейсов стоит - media: Ethernet autoselect ??

в ручную менять не хочет:

ifconfig tap0 media 100baseTX
ifconfig: SIOCSIFMEDIA (media): Invalid argument

 

В итоге на сегодняшний день я так и не нашел способа заставить bridge прозрачно пропускать через себя LACP.

[ChargeSet]

а бридж принципиален? FreeBSD умеет зерклалить порты? А отлавливать и форвардить определенные датаграммы?

[tt128]

Ну не то что бы принципиален, но насколько я знаю на бзде можно зеркалить порты или через if_bridge или через ng_bridge, так как до netgraph еще руки не дошли, то пока ковыряю if_bridge.

Собственно судя по handbook в if_bridge есть опция:

span
A span port transmits a copy of every Ethernet frame received by the bridge.

 

Но это не совсем то что нужно.

 

По поводу форвардить определенные датаграммы, то вроде как есть

net.link.ether.ipfw
            Controls whether layer-2 packets are passed to ipfw.  Default is
            no.

 

 

тоесть в теории L2 можно отдавать ipfw для дальнейших разборов. Надо будет попробовать.

[ChargeSet]

может быть я сейчас ляпну глупость. но r1-r4 туннели л2тп решили бы вопрос, как мне кажется. тем более что выше более опытные товарищи подсказали про lacp и бриджи

[nnm]

Подскажите пожалуйста согласно каким именно стандартам, а то сходу не получилось найти.

 

IEEE 802.1AX, IEEE 802.3

[vlad11]

Позвольте напомнить про существование Netgraph.

[tt128]

но r1-r4 туннели л2тп решили бы вопрос, как мне кажется.

Прямых туннелей не получится сделать, так как у R1 есть доступ только к R2 или R3, но не к R4.

Поэтому делаем два туннеля R1-R2 + R2-R4 и так же с R3.

 

Позвольте напомнить про существование Netgraph.

Да, netgraph - это вещь очень полезная, я про нее всегда помню :)) просто не пользовал раньше, сейчас читаю про него :))

[tt128]

Собсно про netgraph...

ng_bridge как и ожидалось тоже не пропускает LACP PDU

по крайней мере у меня не завелось:

ngctl mkpeer tap0: bridge lower link0
ngctl name tap0:lower bnet0
ngctl connect tap1: bnet0: lower link1
ngctl connect tap0: bnet0: upper link2
ngctl connect tap1: bnet0: upper link3
ngctl msg tap0: setpromisc 1
ngctl msg tap1: setpromisc 1
ngctl msg tap0: setautosrc 0
ngctl msg tap1: setautosrc 0

 

Пакетики бегают все норм, но LACP не поднимается... Ну это я так скорее для очистки совести проверил.

Попробовал на R1 и R4 вместо lagg0 поюзать ng_one2many.

Все вроде бы неплохо... НО, как определять если один из линков упал??? Можно наверное сделать туннели не через openvpn а через netgraph например.. Вобщем надо поковырять еще.

Или еще вариант, использовать lagg0 fec/loadbalance плюс костыль какой нить написать, чтобы проверял живость тунеля и если сдох то убирать его из lagg0

[tt128]

И еще в догонку....

Терзает меня одна мысль...

а именно, то что судя по lacp debug, на R1:

lagg0: link state changed to DOWN
lagg0: link state changed to UP
can't re-use a leaf (lacp_strict_mode)!
can't re-use a leaf (rx_test)!
can't re-use a leaf (tx_test)!
tap1: promiscuous mode enabled
tap1: promiscuous mode disabled
tap0: promiscuous mode enabled
tap0: promiscuous mode disabled
lagg0: link state changed to DOWN
tap0: link state changed to DOWN
tap0: Ethernet address: 00:bd:37:a2:4f:00
tap0: link state changed to UP
lagg0: link state changed to UP
tap0: media changed 0x0 -> 0x20, ether = 1, fdx = 0, link = 1
tap0: partner timeout changed
tap0: -> UNSELECTED
tap1: media changed 0x0 -> 0x20, ether = 1, fdx = 0, link = 1
tap1: partner timeout changed
tap1: -> UNSELECTED
[b]lacp_select_tx_port: no active aggregator[/b]

 

lagg0 даже не пытается отправлять ничего в интерфейсы, и естественно до R2 и R3 LACP PDU даже не доходят,

мне кажется что это из-за того что на ифейсе tap нельзя выбрать среду, там стоит media: Ethernet autoselect

Может кто знает способ как задать ему принудительно например 100baseTX ??

Где то натыкался в сети, но сейчас что-то не найду никак.

[tt128]

Всем привет!

 

Засел за изучение netgraph, сильно жалею что не делал этого раньше :(

Знающие люди проясните картину плз...

 

Итак есть три роутера R1 - R2 -R4, все как и раньше у R1 есть связь с R2 но нету с R4, задача сделать L2 линк средствами netgraph между R1- R4.

Для наглядности картинка:

 

 

Собственно на R1 создаем свитч и коннектим его по UDP к R2

mkpeer . bridge lower link0
name .:lower sw
mkpeer sw: ksocket link1 inet/dgram/udp
msg sw:link1 bind inet/1.1.1.1:1201
msg sw:link1 connect inet/1.1.1.2:1201

 

Далее создаем ethernet интерфейс:

mkpeer . eiface hook ether

 

И пытаемся его приконектить к нашему свитчу:

 

connect sw: ngeth0: link2 upper

 

И получаем ошибку

ngctl: send msg: Protocol family not supported

 

Прошу помощи у netgraph-гуру :))) Объясните плз где я накосячил.

Заранее всем спасибо.

[tt128]

Дальнейший гуглинг натолкнул меня на ng_tee

Как мне кажется в моем случае это то что нужно для R2

Конфиг на R2 такой:

+ mkpeer tee dummy left2right
+ name dummy mytee
+ mkpeer mytee: ksocket left inet/dgram/udp
+ name mytee:left udp1
+ mkpeer mytee: ksocket right inet/dgram/udp
+ name mytee:right udp2

+ msg udp1: bind inet/1.1.1.2:1201
+ msg udp1: connect inet/1.1.1.1:1201

+ msg udp2: bind inet/2.2.2.2:1202
+ msg udp2: connect inet/2.2.2.1:1202

 

Попробовал, все пашет как часы, перекидывает пакетики, R1 пингает R4, вобщем почти то что надо.... НО есть один момент

Хотелось бы вместо интерфейсов точка-точка ng0 использовать ngeth0 и на R4 например добавить его в бридж с физическим ифейсом, тем самым получаем на R1 ethernet порт со свитча в который воткнут R4 своим физическим интерфейсом.

Вопрос именно в том как настроить на R1...

У кого нибудь есть мысли?

[Ivan_83]

Далее создаем ethernet интерфейс: mkpeer . eiface hook ether И пытаемся его приконектить к нашему свитчу: connect sw: ngeth0: link2 upper

В топку, сразу коннектим куда нужно:

mkpeer sw: eiface link2 ether

(man ng_eiface говорит что у ноды есть только ether хук, никаких upper)

Вот ещё пример мостостроения: http://habrahabr.ru/post/86553/

 

Для моста tee не нужен, либо hub либо switch (bridge), притом у последнего производительность должна быть хуже.

А если вы только ng_eiface с ng_ksocket соединяете и не планируете вещать в физическую сеть то и соединяйте их напрямую сразу, без всяких хабов, свичей и тее.

[tt128]

А если вы только ng_eiface с ng_ksocket соединяете и не планируете вещать в физическую сеть то и соединяйте их напрямую сразу, без всяких хабов, свичей и тее.

 

Да, это логично, но соединить мне нужно один конец туннеля с другим, физический ифейс то на R2 всего один. Как в этом случае быть?

ng_tee думаю вполне неплохо с этим справится.

[Ivan_83]

ng_ksocket - отправляет/принимает пакеты через стёк ОС(и свой хук), вот ОС их сама в сеть и отправит и примет.

[tt128]

Такс, отлично, примерно начинаю предствлять... нетграф я только начал раскуривать, так что не бейте сильно :)) Если не сложно можно пару строчек как именно сконфигурить в данном случае?

[Ivan_83]

mkpeer . hub tmp tmp

name .:tmp hubbb

mkpeer hubbb: ksocket kshook inet/dgram/udp

mkpeer hubbb: eiface eifhook ether

 

Дальше ngctl отключается от tmp хука хаба и он начинает гонять пакеты напрямую между двумя хуками.

До отключения можно ещё сокет настроить, можно и потом отправляя сообщения на hubbb:kshook.

 

Без хаба:

ngctl mkpeer eiface link1 ether

ngctl mkpeer ngeth0: ksocket ether inet/dgram/udp

ngctl msg ngeth0:ether bind inet/1.1.1.1:1201

...

Убить конструкцию: ngctl shutdown ngeth0:

Вероятно нужно поставить какие то не нулевые и не мультикастовые маки на созданные виртуальные сетевушки, для нормальной работы.

[tt128]

mkpeer . hub tmp tmp

name .:tmp hubbb

mkpeer hubbb: ksocket kshook inet/dgram/udp

mkpeer hubbb: eiface eifhook ether

 

 

Спасибо огромное за разъяснение :)) Очень помогло.

Итак возвращаемся в первоначальной задаче:

 

Нужно сделать LACP через два разных канала.

Собственно рабочая конфигурация:

 

на R1:

#!/bin/sh

/usr/sbin/ngctl mkpeer eiface link1 ether
/usr/sbin/ngctl mkpeer ngeth0: ksocket ether inet/dgram/udp
/usr/sbin/ngctl msg ngeth0:ether bind inet/1.1.1.1:10002
/usr/sbin/ngctl msg ngeth0:ether connect inet/1.1.1.2:10002
/usr/sbin/ngctl name ngeth0:ether R2

/usr/sbin/ngctl mkpeer eiface link2 ether
/usr/sbin/ngctl mkpeer ngeth1: ksocket ether inet/dgram/udp
/usr/sbin/ngctl msg ngeth1:ether bind inet/1.1.1.1:10003
/usr/sbin/ngctl msg ngeth1:ether connect inet/1.1.1.3:10003
/usr/sbin/ngctl name ngeth1:ether R3

/sbin/ifconfig ngeth0 up
/sbin/ifconfig ngeth0 ether xx:xx:xx:xx:xx:xx
/sbin/ifconfig ngeth1 up
/sbin/ifconfig ngeth1 ether xx:xx:xx:xx:xx:xx
/sbin/ifconfig lagg0 create
/sbin/ifconfig lagg0 laggproto lacp laggport ngeth0 laggport ngeth1 up
/sbin/ifconfig lagg0 inet x.x.x.1/30 up

 

 

на R2:

#!/bin/sh

/usr/sbin/ngctl -f- <<EOF
mkpeer . hub tmp tmp
name .:tmp hubbb

mkpeer hubbb: ksocket kshook inet/dgram/udp
msg hubbb:kshook bind inet/1.1.1.2:10002
msg hubbb:kshook connect inet/1.1.1.1:10002
name hubbb:kshook R1

mkpeer hubbb: ksocket kshook1 inet/dgram/udp
msg hubbb:kshook1 bind inet/2.2.2.2:10001
msg hubbb:kshook1 connect inet/2.2.2.1:10001
name hubbb:kshook1 R4
EOF

 

 

на R3:

#!/bin/sh

/usr/sbin/ngctl -f- <<EOF
mkpeer . hub tmp tmp
name .:tmp hubbb

mkpeer hubbb: ksocket kshook inet/dgram/udp
msg hubbb:kshook bind inet/1.1.1.3:10003
msg hubbb:kshook connect inet/1.1.1.1:10003
name hubbb:kshook R1

mkpeer hubbb: ksocket kshook1 inet/dgram/udp
msg hubbb:kshook1 bind inet/2.2.2.3:10004
msg hubbb:kshook1 connect inet/2.2.2.1:10004
name hubbb:kshook1 R4
EOF

 

на R4:

#!/bin/sh

/usr/sbin/ngctl mkpeer eiface link1 ether
/usr/sbin/ngctl mkpeer ngeth0: ksocket ether inet/dgram/udp
/usr/sbin/ngctl msg ngeth0:ether bind inet/2.2.2.1:10001
/usr/sbin/ngctl msg ngeth0:ether connect inet/2.2.2.2:10001
/usr/sbin/ngctl name ngeth0:ether R2

/usr/sbin/ngctl mkpeer eiface link2 ether
/usr/sbin/ngctl mkpeer ngeth1: ksocket ether inet/dgram/udp
/usr/sbin/ngctl msg ngeth1:ether bind inet/2.2.2.1:10004
/usr/sbin/ngctl msg ngeth1:ether connect inet/2.2.2.3:10004
/usr/sbin/ngctl name ngeth1:ether R3

/sbin/ifconfig ngeth0 up
/sbin/ifconfig ngeth0 ether xx:xx:xx:xx:xx:xx

/sbin/ifconfig ngeth1 up
/sbin/ifconfig ngeth1 ether xx:xx:xx:xx:xx:xx

/sbin/ifconfig lagg0 create
/sbin/ifconfig lagg0 laggproto lacp laggport ngeth0 laggport ngeth1 up
/sbin/ifconfig lagg0 inet x.x.x.2/30 up

 

Работает!!!

Вообще netgraph конечно вещь!! Без нее никак в данной ситуации, ибо я не нашел других способов перекидывать LACPDU через бридж.

 

Кстати кто-нибудь знает как в БДЗ выбрать для lagg интерфейса таймауты поменьше (тобишь в терминологии цизки lacp timeout short) хочется поэксперементировать, а то со стандартными 30/90 сек. как-то долго ждать :))

Я поглядел в исходниках ieee8023ad_lacp.h , там вроде есть упоминание LACP_FAST_TIMEOUT_TIME и LACP_SLOW_PERIODIC_TIME, но как реально поменять значения я не знаю.

[vlad11]

 

Работает!!!

Вообще netgraph конечно вещь!! Без нее никак в данной ситуации, ибо я не нашел других способов перекидывать LACPDU через бридж.

 

Сумеете оформить статью на хабре?