Перейти к содержимому
Калькуляторы

Всем привет.

 

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

post-116816-037179000 1396588016_thumb.jpeg

 

Собственно у 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 в такой конфигурации будет работать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да вот в том то и проблема, непонятно почему 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 

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Изменено пользователем nnm

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если 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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну не то что бы принципиален, но насколько я знаю на бзде можно зеркалить порты или через 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 для дальнейших разборов. Надо будет попробовать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

IEEE 802.1AX, IEEE 802.3

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Собсно про 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

а именно, то что судя по 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 ??

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Всем привет!

 

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

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

 

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

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

 

post-116816-032744800 1397545946_thumb.jpeg

 

Собственно на 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-гуру :))) Объясните плз где я накосячил.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Дальнейший гуглинг натолкнул меня на 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...

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Далее создаем 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 соединяете и не планируете вещать в физическую сеть то и соединяйте их напрямую сразу, без всяких хабов, свичей и тее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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:

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

mkpeer . hub tmp tmp

name .:tmp hubbb

mkpeer hubbb: ksocket kshook inet/dgram/udp

mkpeer hubbb: eiface eifhook ether

 

 

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

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

post-116816-015520300 1397809368_thumb.jpeg

 

Нужно сделать 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, но как реально поменять значения я не знаю.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Работает!!!

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.