Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
джамшутин высшей пробы, небольшой ISP провайдер в курсе как Вы решили их проблему?
Конечно, решение согласовано с руководителем этой сети, надо было решить без простоя в работе, через 2 недели придет оптика и городить что-то сложное мало смысла. А это первое что в голову пришло.
> Попытки объединить каналы по LACP не увенчались успехом
Мне кажется, что если радиоканалы настроены в режиме моста, то вполне могла сработать простая статическая агрегация (802.3ad).
Мне кажется, что если радиоканалы настроены в режиме моста, то вполне могла сработать простая статическая агрегация (802.3ad).
не сработала, первое что проверили.
Странно, нужно будет как-нибудь попробовать повторить эксперимент.
Ммм… А каким образом может не сработать статическая агрегация, не предполагающая согласований чего-либо? Ну не может она не заработать, так не бывает. Она либо поднимается и всё работает, либо поднимается и всё очень паршиво работает. Но подняться обязана.
Однако, да, чуточку стремно: нет кипалайвов, и придется вручную класть глюкающий радиоканал, если физика не упадет.
Ну и заодно: товарищ чуть ниже дело говорит про bridge. Единственное правильное решение.
Однако, да, чуточку стремно: нет кипалайвов, и придется вручную класть глюкающий радиоканал, если физика не упадет.
Ну и заодно: товарищ чуть ниже дело говорит про bridge. Единственное правильное решение.
А вы не озвучите нам причину побудившую создать такое дикое извращение? Почему не использовать множественные маршрутные таблицы? Ведь инструменты есть и есть давно, уж тем более во FreeBSD.
Множественные маршрутные таблицы поломают логику текущего биллинга. Там кроме этого сегмента маршрутизация такая, что туда только ROUTETABLES еще запихать, там и так и динамика и статика да и модуль фаирвола от биллинга не предусматривает работу более чем с одной таблицей. Какие еще варианты? Я сам прекрасно понимаю, что это изврат о чем написал дважды, но предложите решение лучше, чтоб без простоя сети и материальных затрат.
Я допускаю, что прочитав пост по диагонали упустил тот, единственно важный момент, который все объяснит. Но прочитав его ещё раз, так и не смог понять почему, не создать bridge из этих интерфейсов и на него повесить l3?
С обоих сторон свич L2, бридж и так есть, вернее их 2, объединить в один не вышло. Схема сервер, свич, точка доступа, бридж с другой точкой доступа, свич, абоненты. Если вы имеете в виду бридж на сервере? Если так, тоже не пойму чем он поможет при такой структуре. Если это вариант соединить мостом каждый вилан и родительский интерфейс, то на интерфейсе совсем другие функции, не говоря уже о том, что для брижда придется пересобрать ядро и каким-то образом модифицировать модуль фаирвола биллинга для работы с бридж интерфейсом. Может я не понял что вы имели в виду, объясните подробней.
Вы поясните не очевидный мне момент: в качестве решения проблемы нехватки полосы на радио-линке, вы поделили абонентов на два влана? Если это так, то вот что я имею ввиду:
FreeBSD Bridging
Как вариант.
Да даже перемычка на портах коммутатора, объединяющая ваши вланы мне видится менее «костыльным» вариантом, чем представленное решение.
Вы пожалуйста не обижайтесь на мою настойчивость, просто я так и не понял зачем ваш вариант нужен в данном случае. Если не прав, то с радостью в этом признаюсь.
FreeBSD Bridging
bridge0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether d2:41:75:d6:ff:0d
inet 172.16.1.254 netmask 0xffffff00 broadcast 172.16.1.255
inet 172.16.52.254 netmask 0xffffff00 broadcast 172.16.52.255
inet 172.16.3.254 netmask 0xffffff00 broadcast 172.16.3.255
inet 10.55.1.1 netmask 0xffffff00 broadcast 10.55.1.255
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: vlan2814 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 7 priority 128 path cost 55
member: vlan2819 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 6 priority 128 path cost 55
vlan2814: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:1b:b9:8b:ca:33
inet6 fe80::210:b5ff:fe0d:9c75%vlan103 prefixlen 64 scopeid 0x6
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (100baseTX <full-duplex,flowcontrol,rxpause,txpause>)
status: active
vlan: 2814 parent interface: em0
vlan2819: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:1b:b9:8b:ca:33
inet6 fe80::210:b5ff:fe0d:9c75%vlan104 prefixlen 64 scopeid 0x7
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (100baseTX <full-duplex,flowcontrol,rxpause,txpause>)
status: active
vlan: 2819 parent interface: em0Как вариант.
Да даже перемычка на портах коммутатора, объединяющая ваши вланы мне видится менее «костыльным» вариантом, чем представленное решение.
Вы пожалуйста не обижайтесь на мою настойчивость, просто я так и не понял зачем ваш вариант нужен в данном случае. Если не прав, то с радостью в этом признаюсь.
Сегодня проверил вариант с мостом.
Подымаю так:
интерфейс поднимается на всех ip, но подключенные пользователи его не видят и арпов на интерфейсе, кроме его собственных нет, может я не так бридж создаю?
Подымаю так:
cloned_interfaces="vlan2814 vlan2819 bridge0"
ifconfig_bridge0="inet 172.16.1.254 netmask 255.255.255.0 addm vlan2814 addm vlan2819 up"
ifconfig_bridge0_alias0="inet 172.16.52.254 netmask 255.255.255.0"
ifconfig_bridge0_alias1="inet 172.16.3.254 netmask 255.255.255.0"
ifconfig_bridge0_alias2="inet 10.55.1.1 netmask 255.255.255.0"
интерфейс поднимается на всех ip, но подключенные пользователи его не видят и арпов на интерфейсе, кроме его собственных нет, может я не так бридж создаю?
А как вы его создаёте? Ссылку на handbook читали?.. Попробуйте kldload if_bridge и man if_bridge до полного самадхи.
Зачем kldload if_bridge, если ядро собрано с device if_bridge, специально пересобрал. Сам мост создается как виртуальный интерфейс, но при этом пользователи из входящих в него виланов не видят сервер. Похоже дело в том, что мост по своей задумке должен работать без маршрутизатора (segments without having to create IP subnets and use a router). Своего случая или чего-либо похожего в хендбуке и других доках по мосту не нашел. Мне не надо гонять трафик между виланами не машрутизируя его, мне надо чтоб в обоих виланах сервер выступал для пользователей маршрутизатором. Будет время погоняю фряшный мост на стенде, снова останавливать живую сеть на эксперименты нет желания, до конца недели и с костылем поработает, а там и оптика дойдет.
Своего случая или чего-либо похожего в хендбуке и других доках по мосту не нашел.
32.5.7.4 Sticky Interfaces — FreeBSD Handbook — не ваш случай?
Экспериментировать на живой сети — это я вам скажу, почти всегда не правильно. Увы, но за давностью лет, у меня не осталось конфигов, что бы показать как оно должно быть. Стенд самое правильное решение, ещё помнится, promiscuous mode на физ. интерфейсах был крайне полезен.
Видать с глазами плохо стало, вы правы Sticky по описанию похож, на днях проверю на стенде — отпишусь. Стенд с радиомостами не так просто создать, чтоб имитировать нестабильность среды передачи, а при проводной сети работает LACP, попробую добиться похожих условий используя обычные вай-фай точки доступа через стену.
Проверил, все рано не то. В rc.conf прописываю
Интерфейс подымается
Но никого из клиентов не видно
И сеть соответственно тоже никто не получает, вот такие дела…
ifconfig_bridge0="inet 172.16.1.254 netmask 255.255.255.0 addm vlan2814 sticky vlan2814 addm vlan2819 sticky vlan2819 up"
ifconfig_bridge0_alias0="inet 172.16.52.254 netmask 255.255.255.0"
ifconfig_bridge0_alias1="inet 172.16.3.254 netmask 255.255.255.0"
ifconfig_bridge0_alias2="inet 10.55.1.1 netmask 255.255.255.0
Интерфейс подымается
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 02:24:b9:ca:cf:00
inet 172.16.1.254 netmask 0xffffff00 broadcast 172.16.1.255
inet 172.16.52.254 netmask 0xffffff00 broadcast 172.16.52.255
inet 172.16.3.254 netmask 0xffffff00 broadcast 172.16.3.255
inet 10.55.1.1 netmask 0xffffff00 broadcast 10.55.1.255
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: vlan2819 flags=953<LEARNING,DISCOVER,STICKY,PRIVATE,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 17 priority 128 path cost 55
member: vlan2814 flags=953<LEARNING,DISCOVER,STICKY,PRIVATE,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 14 priority 128 path cost 55
Но никого из клиентов не видно
arp -an -ibridge0
? (172.16.3.254) at 02:24:b9:ca:cf:00 on bridge0 permanent [bridge]
? (172.16.1.254) at 02:24:b9:ca:cf:00 on bridge0 permanent [bridge]
? (172.16.52.254) at 02:24:b9:ca:cf:00 on bridge0 permanent [bridge]
? (10.55.1.1) at 02:24:b9:ca:cf:00 on bridge0 permanent [bridge]
И сеть соответственно тоже никто не получает, вот такие дела…
Предсказываю!
Оптику не протянут. Решение из временного перейдёт в постоянно-временное. Сначала скрипт будет запускаться вручную на новых клиентах, потом переделают на запуск по крону. Всё заработает автоматически и про это забудут. Проработав 10 лет в углу, FreeBSD сервер упадёт из-за забившейся пыли и перегревания. И админ будущего, разбираясь что случилось, сначала офигеет, потом будет рвать волосы, потом смеяться, напишет и порвёт заявление об уходе, а потом запостит всё на какой-нить ресурс типа ithappens
Оптику не протянут. Решение из временного перейдёт в постоянно-временное. Сначала скрипт будет запускаться вручную на новых клиентах, потом переделают на запуск по крону. Всё заработает автоматически и про это забудут. Проработав 10 лет в углу, FreeBSD сервер упадёт из-за забившейся пыли и перегревания. И админ будущего, разбираясь что случилось, сначала офигеет, потом будет рвать волосы, потом смеяться, напишет и порвёт заявление об уходе, а потом запостит всё на какой-нить ресурс типа ithappens
Оптика протянется, чуток прогадали со временем и не успели до зимних праздников и нагрузка резко возросла — это затычка до конца каникул. Про запуск по крону раз в минуту писал, Вы невнимательны. Когда руководству сетей предлагаешь вариант быстро, без затрат, но через задницу или долго, с доп затратами, но «по-феншую», почти всегда выбирают первое. Я обрисовал варианты и дал выбрать, что было выбрано, то и сделал. Если кто знает, как решить по другому, быстро и без затрат — внимательно выслушаю. Я бы сам просто выделил новую подсеть и не делал этого ужаса, но условием было то, что ничего не нужно перенастраивать у абонентов со статикой (да да есть сети которые не используют DHCP). Заметка не об этом, а о том как использовать несколько одинаковых IP на разных интерфейсах, в некоторых случаях бывает удобно.
Зря надеетесь на оптику, её порвут, а потом трактором бухту переедут. Надо было писать как бы надолго, хотя бы сделать вид. Ну там в скрипт вставить поддержку --help, сам скрипт в репозиторий, вести версии, changelog. Тогда возможно и была бы и оптика…
А теперь надежды нет ;) Закон прост: чем больше изоленты, тем дольше это будет жить, а если делать надолго и с расчётом, то скорее всего через пару месяцев будет не нужно. Судьба любит изоленту…
P.S.: я не пытаюсь обидеть, это всё грустный сарказм. Сам писал жуткие костыли, а потом удивлялся, как эти костыли работали дольше и лучше, чем основательные решения.
А теперь надежды нет ;) Закон прост: чем больше изоленты, тем дольше это будет жить, а если делать надолго и с расчётом, то скорее всего через пару месяцев будет не нужно. Судьба любит изоленту…
P.S.: я не пытаюсь обидеть, это всё грустный сарказм. Сам писал жуткие костыли, а потом удивлялся, как эти костыли работали дольше и лучше, чем основательные решения.
Как ни печально, но так обычно всегда и бывает, и не только в администрировании но и в разработке ПО. Делается быстро как-нибудь, чтобы заработало, а потом так и работает и сверху лепится тоже что-то подобное.
какое радиооборудование используете?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сетевые извращения: несколько одинаковых ip на разных интерфейсах маршрутизатора в FreeBSD