tt128 Posted April 4, 2014 · Report post Всем привет. Есть такая схемка: Собственно у 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 в такой конфигурации будет работать? Share this post Link to post Share on other sites
secandr Posted April 4, 2014 · Report post Поднимите третий уровень и поставьте балансировку по OSPF, допустим. Share this post Link to post Share on other sites
tt128 Posted April 4, 2014 · Report post Да, L3 - скука :)) Хочеца больше L2 секаса :)) В данном случае это скорее не для решения конкретной задачи, а для понимания теоретических возможностей. Хочется понять, в принципе LACP должен работать в таком случае или нет. Share this post Link to post Share on other sites
zhenya` Posted April 4, 2014 · Report post если промежуточные узлы будут пропускать через себя лацпбпду, то все взлетит Share this post Link to post Share on other sites
tt128 Posted April 4, 2014 · Report post Да вот в том то и проблема, непонятно почему 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 молчит совсем. Share this post Link to post Share on other sites
NiTr0 Posted April 4, 2014 · Report post Хочется понять, в принципе LACP должен работать в таком случае или нет. Если R2,R3 не льют и не получают из сети никакого трафика (т.е. служат тупыми мостами), и если пропускают LACPDU пакеты - скорее всего взлетит. Бридж по идее не должен ничего фильтровать. Но я та понимаю, первое условие не выполняется (ибо не от скуки же промежуточные хосты воткнуты). Share this post Link to post Share on other sites
nnm Posted April 4, 2014 (edited) · Report post Подскажите плз вообще LACP в такой конфигурации будет работать? Согласно стандартам, bridge не может транслировать LACP PDU из одного интерфейса в другой. В операторских коробках могут быть опции, отключающие такую фильтрацию, но в BSD их похоже нет. Edited April 4, 2014 by nnm Share this post Link to post Share on other sites
tt128 Posted April 7, 2014 · Report post Если 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. Share this post Link to post Share on other sites
ChargeSet Posted April 7, 2014 · Report post а бридж принципиален? FreeBSD умеет зерклалить порты? А отлавливать и форвардить определенные датаграммы? Share this post Link to post Share on other sites
tt128 Posted April 7, 2014 · Report post Ну не то что бы принципиален, но насколько я знаю на бзде можно зеркалить порты или через 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 для дальнейших разборов. Надо будет попробовать. Share this post Link to post Share on other sites
ChargeSet Posted April 7, 2014 · Report post может быть я сейчас ляпну глупость. но r1-r4 туннели л2тп решили бы вопрос, как мне кажется. тем более что выше более опытные товарищи подсказали про lacp и бриджи Share this post Link to post Share on other sites
nnm Posted April 7, 2014 · Report post Подскажите пожалуйста согласно каким именно стандартам, а то сходу не получилось найти. IEEE 802.1AX, IEEE 802.3 Share this post Link to post Share on other sites
vlad11 Posted April 8, 2014 · Report post Позвольте напомнить про существование Netgraph. Share this post Link to post Share on other sites
tt128 Posted April 8, 2014 · Report post но r1-r4 туннели л2тп решили бы вопрос, как мне кажется. Прямых туннелей не получится сделать, так как у R1 есть доступ только к R2 или R3, но не к R4. Поэтому делаем два туннеля R1-R2 + R2-R4 и так же с R3. Позвольте напомнить про существование Netgraph. Да, netgraph - это вещь очень полезная, я про нее всегда помню :)) просто не пользовал раньше, сейчас читаю про него :)) Share this post Link to post Share on other sites
tt128 Posted April 8, 2014 · Report post Собсно про 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 Share this post Link to post Share on other sites
tt128 Posted April 8, 2014 · Report post И еще в догонку.... Терзает меня одна мысль... а именно, то что судя по 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 ?? Где то натыкался в сети, но сейчас что-то не найду никак. Share this post Link to post Share on other sites
tt128 Posted April 15, 2014 · Report post Всем привет! Засел за изучение 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-гуру :))) Объясните плз где я накосячил. Заранее всем спасибо. Share this post Link to post Share on other sites
tt128 Posted April 15, 2014 · Report post Дальнейший гуглинг натолкнул меня на 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... У кого нибудь есть мысли? Share this post Link to post Share on other sites
Ivan_83 Posted April 15, 2014 · Report post Далее создаем 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 соединяете и не планируете вещать в физическую сеть то и соединяйте их напрямую сразу, без всяких хабов, свичей и тее. Share this post Link to post Share on other sites
tt128 Posted April 15, 2014 · Report post А если вы только ng_eiface с ng_ksocket соединяете и не планируете вещать в физическую сеть то и соединяйте их напрямую сразу, без всяких хабов, свичей и тее. Да, это логично, но соединить мне нужно один конец туннеля с другим, физический ифейс то на R2 всего один. Как в этом случае быть? ng_tee думаю вполне неплохо с этим справится. Share this post Link to post Share on other sites
Ivan_83 Posted April 15, 2014 · Report post ng_ksocket - отправляет/принимает пакеты через стёк ОС(и свой хук), вот ОС их сама в сеть и отправит и примет. Share this post Link to post Share on other sites
tt128 Posted April 15, 2014 · Report post Такс, отлично, примерно начинаю предствлять... нетграф я только начал раскуривать, так что не бейте сильно :)) Если не сложно можно пару строчек как именно сконфигурить в данном случае? Share this post Link to post Share on other sites
Ivan_83 Posted April 16, 2014 · Report post 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: Вероятно нужно поставить какие то не нулевые и не мультикастовые маки на созданные виртуальные сетевушки, для нормальной работы. Share this post Link to post Share on other sites
tt128 Posted April 18, 2014 · Report post 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, но как реально поменять значения я не знаю. Share this post Link to post Share on other sites
vlad11 Posted April 18, 2014 · Report post Работает!!! Вообще netgraph конечно вещь!! Без нее никак в данной ситуации, ибо я не нашел других способов перекидывать LACPDU через бридж. Сумеете оформить статью на хабре? Share this post Link to post Share on other sites
