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

tt128

Пользователи
  • Публикации

    19
  • Зарегистрирован

  • Посещение

О tt128

  • Звание
    Абитуриент
  1. 1 проц с двумя ядрами или 2 проца с одним ядром - частота 3Ггц Память 6Гб Харды пока не нужны, но можно серваки и со scsi.
  2. Привет всем! Может кто-то распродает остатки морально устаревшего железа? Нужно 10 серверов, можно с ddr2, на 771 сокете или другие конфигурации. Желательно 1U, но не принципиально. Главное недорого.
  3. LACP + EtherIP

    Всем привет. Можно подумать в принципе, почему нет... Согласен можно все было решить роутингом, но нужен был именно L2 , и в качестве эксперимента поднятие LACP. Это скорее ради выяснения принципиальных возможностей... Но собственно продолжаем тему. Не все так гладко как хотелось бы, после некоторого времени тестирования такой конфигурации, наткнулись на проблему скорее всего связанную с MTU и битом DF. Выглядит это так как будто часть траффика пролезает в канал (ICMP, SMTP, GRE итд...), а часть нет (SSH например отваливается по таймауту так и не спросив пароль.) Я вот пытаюсь понять, что именно происходит с MTU при прохождении R2 - R3 когда netgraph перекидывает пакетики из туннеля в туннель ?? Собственно на всех ифейсах и физических и ngethX стоит MTU 1500. Подозреваю что его надо менять. Когда такую же конфигурацию мы собирали на OpenVPN - L2 udp туннелях то там была опция link-mtu 1533, без нее была очень похожая ситуация. Есть у кого-нибудь мысли по этому поводу??
  4. LACP + EtherIP

    Спасибо огромное за разъяснение :)) Очень помогло. Итак возвращаемся в первоначальной задаче: Нужно сделать 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, но как реально поменять значения я не знаю.
  5. LACP + EtherIP

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

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

    Дальнейший гуглинг натолкнул меня на 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... У кого нибудь есть мысли?
  8. LACP + EtherIP

    Всем привет! Засел за изучение 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-гуру :))) Объясните плз где я накосячил. Заранее всем спасибо.
  9. LACP + EtherIP

    И еще в догонку.... Терзает меня одна мысль... а именно, то что судя по 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 ?? Где то натыкался в сети, но сейчас что-то не найду никак.
  10. LACP + EtherIP

    Собсно про 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
  11. LACP + EtherIP

    Прямых туннелей не получится сделать, так как у R1 есть доступ только к R2 или R3, но не к R4. Поэтому делаем два туннеля R1-R2 + R2-R4 и так же с R3. Да, netgraph - это вещь очень полезная, я про нее всегда помню :)) просто не пользовал раньше, сейчас читаю про него :))
  12. LACP + EtherIP

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

    Да вы все верно понимаете :)) Собственно вся загвоздка в пропуске LACP PDU через bridge. Подскажите пожалуйста согласно каким именно стандартам, а то сходу не получилось найти. Ну и собственно продолжение экпериментов. Совсем забыл указать что БЗД -то у меня на 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.
  14. LACP + EtherIP

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

    Да, L3 - скука :)) Хочеца больше L2 секаса :)) В данном случае это скорее не для решения конкретной задачи, а для понимания теоретических возможностей. Хочется понять, в принципе LACP должен работать в таком случае или нет.