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