tt128

:) Спасибо теперь понятнее стало. Просто на будущее, у номера AS мало общего с ЛИР аккаунтом. И почем нынче AS6679 ?

Так может вы расскажете нам, что все таки вы имели ввиду? Никаких претензий, просто реально интересно что именно вы продаете? Спасибо.

А это вы из чего такой вывод сделали?

ээээ... я еще раз полюбопытствую, а что вы вкладываете в понятие "ЛИР аккаунт" ?

Простите мое любопытство, а что такое четырехзначный ЛИР аккаунт??

Что-то мы совсем отдалились от темы... Может создадим отдельную ветку для обсуждения работы LIR-ов и вопросов про PA/PI ?

Нет, ну если вы берете канал у магистрала и он же вам (по символической цене или бесплатно отдает PA), то понятное дело он хочет чтобы вы юзали эту PA только в рамках его канала. Но даже в этом случае, ничто вам не мешает анонсить свою сеть в любые аплинки. Но конечно при условии что вы можете управлять своей сетью сами (то есть LIR дает вам доступ к объектам route и domain). А если вы возьмете PA у любого LIR который даже не является оператором связи, то вам никто слова не скажет, анонсируйте куда хотите. Технически никаких отличий PA от PI - НЕТ!

Но позвольте, как же вас понимать? И в тоже время Таки как раз, как и в любой отрасли, либо стабильно от мэтров, либо как повезёт от «ооо из задрищенска». Так а что не так с PA поясните пожалуйста? И для чего по вашему нужна своя AS? Исключительно для PI ? Да даже с PI нет сейчас никаких проблем, либо ищем IPv4 на вторичном рынке, либо раскуриваем IPv6. Ну так после 2012-го это норма... провайдер не всегда лир и наоборот. Лиры теперь это отдельный бизинесс, нравится нам с вами это или нет...

:)) Ну это смотря, что етсь для вас достойный лир? Все относительно... А может это, значить... Самому лиром заделаца? Всяко проще будет... Да и ежели сетей-то боле чем /24 то и оброк меньше платить чужеземным лирам. З.Ы. Простите за слог... Воскресенье, выходной :))

Может тут - https://www.ripe.net/membership/indices/RU.html ???

А в чем проблемы то с обратной зоной и PA ? И вообще с точки зрения использования никакой разницы между PA и PI я что-т не вижу.

Так потому что не надо NCC держать за дурачков :) Если посмотреть на указанную вами сеть в RIPE DB и на ООО которому она была выдана в ЕГРЮЛ, судя по записям в ЕГРЮЛ компания была ликвидирована аж в марте 2012 года. Так что все закономерно.

1 проц с двумя ядрами или 2 проца с одним ядром - частота 3Ггц Память 6Гб Харды пока не нужны, но можно серваки и со scsi.

Привет всем! Может кто-то распродает остатки морально устаревшего железа? Нужно 10 серверов, можно с ddr2, на 771 сокете или другие конфигурации. Желательно 1U, но не принципиально. Главное недорого.

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

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

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

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

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

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

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

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

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

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