RicoX 5 янв 2013 в 17:51

Сетевые извращения: несколько одинаковых ip на разных интерфейсах маршрутизатора в FreeBSD

4 мин

34K

Системное администрирование**nix*Сетевые технологии*

+16

Комментарии 29

iru 5 янв 2013 в 18:54

джамшутин высшей пробы, небольшой ISP провайдер в курсе как Вы решили их проблему?

RicoX 5 янв 2013 в 19:03

Конечно, решение согласовано с руководителем этой сети, надо было решить без простоя в работе, через 2 недели придет оптика и городить что-то сложное мало смысла. А это первое что в голову пришло.

iru 5 янв 2013 в 20:57

Первое что мне в голову приходит, это использовать более широкий радио канал либо Агрегация, но ни как не издевательство над стандартами ARP таблицы.
хотелось бы узнать какая пропускная способность и стабильность данного решения…

RicoX 5 янв 2013 в 21:07

Более широкий канал — нет оборудования, про агрегацию написал. Про стабильность не скажу, только сегодня поднял, пока работает пол дня. В данный момент 160/20 Mbit/s с каждого канала по 80/10 Mbit/s. Без этого изврата максимум через одну точку проходит чуть меньше 100 мегабит.

Amon_Sha 5 янв 2013 в 18:59

> Попытки объединить каналы по LACP не увенчались успехом

Мне кажется, что если радиоканалы настроены в режиме моста, то вполне могла сработать простая статическая агрегация (802.3ad).

RicoX 5 янв 2013 в 19:01

не сработала, первое что проверили.

Amon_Sha 5 янв 2013 в 19:25

Странно, нужно будет как-нибудь попробовать повторить эксперимент.

RicoX 5 янв 2013 в 19:29

Радиомост штука непредсказуемая, повторите будет интересно как на стенде себя поведет, а не в реальной сети.

Amon_Sha 5 янв 2013 в 19:43

А что за железо (свитчи, радио) используется, если не секрет?

RicoX 5 янв 2013 в 20:25

Свичи d-link 3200, точки Mikrotik SXT, сам только узнал от хозяина сетки, с радиооборудованием работают сами, обращаются когда задача не тривиальная.

JDima 5 янв 2013 в 22:08

Ммм… А каким образом может не сработать статическая агрегация, не предполагающая согласований чего-либо? Ну не может она не заработать, так не бывает. Она либо поднимается и всё работает, либо поднимается и всё очень паршиво работает. Но подняться обязана.
Однако, да, чуточку стремно: нет кипалайвов, и придется вручную класть глюкающий радиоканал, если физика не упадет.

Ну и заодно: товарищ чуть ниже дело говорит про bridge. Единственное правильное решение.

art0m 5 янв 2013 в 19:58

А вы не озвучите нам причину побудившую создать такое дикое извращение? Почему не использовать множественные маршрутные таблицы? Ведь инструменты есть и есть давно, уж тем более во FreeBSD.

RicoX 5 янв 2013 в 20:11

Множественные маршрутные таблицы поломают логику текущего биллинга. Там кроме этого сегмента маршрутизация такая, что туда только ROUTETABLES еще запихать, там и так и динамика и статика да и модуль фаирвола от биллинга не предусматривает работу более чем с одной таблицей. Какие еще варианты? Я сам прекрасно понимаю, что это изврат о чем написал дважды, но предложите решение лучше, чтоб без простоя сети и материальных затрат.

art0m 5 янв 2013 в 20:27

Я допускаю, что прочитав пост по диагонали упустил тот, единственно важный момент, который все объяснит. Но прочитав его ещё раз, так и не смог понять почему, не создать bridge из этих интерфейсов и на него повесить l3?

RicoX 5 янв 2013 в 21:01

С обоих сторон свич L2, бридж и так есть, вернее их 2, объединить в один не вышло. Схема сервер, свич, точка доступа, бридж с другой точкой доступа, свич, абоненты. Если вы имеете в виду бридж на сервере? Если так, тоже не пойму чем он поможет при такой структуре. Если это вариант соединить мостом каждый вилан и родительский интерфейс, то на интерфейсе совсем другие функции, не говоря уже о том, что для брижда придется пересобрать ядро и каким-то образом модифицировать модуль фаирвола биллинга для работы с бридж интерфейсом. Может я не понял что вы имели в виду, объясните подробней.

-1

art0m 5 янв 2013 в 21:28

Вы поясните не очевидный мне момент: в качестве решения проблемы нехватки полосы на радио-линке, вы поделили абонентов на два влана? Если это так, то вот что я имею ввиду:
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

Как вариант.
Да даже перемычка на портах коммутатора, объединяющая ваши вланы мне видится менее «костыльным» вариантом, чем представленное решение.
Вы пожалуйста не обижайтесь на мою настойчивость, просто я так и не понял зачем ваш вариант нужен в данном случае. Если не прав, то с радостью в этом признаюсь.

RicoX 8 янв 2013 в 18:31

Сегодня проверил вариант с мостом.
Подымаю так:

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

art0m 9 янв 2013 в 21:12

А как вы его создаёте? Ссылку на handbook читали?.. Попробуйте kldload if_bridge и man if_bridge до полного самадхи.

RicoX 9 янв 2013 в 21:45

Зачем kldload if_bridge, если ядро собрано с device if_bridge, специально пересобрал. Сам мост создается как виртуальный интерфейс, но при этом пользователи из входящих в него виланов не видят сервер. Похоже дело в том, что мост по своей задумке должен работать без маршрутизатора (segments without having to create IP subnets and use a router). Своего случая или чего-либо похожего в хендбуке и других доках по мосту не нашел. Мне не надо гонять трафик между виланами не машрутизируя его, мне надо чтоб в обоих виланах сервер выступал для пользователей маршрутизатором. Будет время погоняю фряшный мост на стенде, снова останавливать живую сеть на эксперименты нет желания, до конца недели и с костылем поработает, а там и оптика дойдет.

art0m 10 янв 2013 в 08:45

Своего случая или чего-либо похожего в хендбуке и других доках по мосту не нашел.

32.5.7.4 Sticky Interfaces — FreeBSD Handbook — не ваш случай?
Экспериментировать на живой сети — это я вам скажу, почти всегда не правильно. Увы, но за давностью лет, у меня не осталось конфигов, что бы показать как оно должно быть. Стенд самое правильное решение, ещё помнится, promiscuous mode на физ. интерфейсах был крайне полезен.

RicoX 10 янв 2013 в 11:09

Видать с глазами плохо стало, вы правы Sticky по описанию похож, на днях проверю на стенде — отпишусь. Стенд с радиомостами не так просто создать, чтоб имитировать нестабильность среды передачи, а при проводной сети работает LACP, попробую добиться похожих условий используя обычные вай-фай точки доступа через стену.

RicoX 10 янв 2013 в 12:51

Проверил, все рано не то. В 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]

И сеть соответственно тоже никто не получает, вот такие дела…

spiritedflow 5 янв 2013 в 20:02

Предсказываю!

Оптику не протянут. Решение из временного перейдёт в постоянно-временное. Сначала скрипт будет запускаться вручную на новых клиентах, потом переделают на запуск по крону. Всё заработает автоматически и про это забудут. Проработав 10 лет в углу, FreeBSD сервер упадёт из-за забившейся пыли и перегревания. И админ будущего, разбираясь что случилось, сначала офигеет, потом будет рвать волосы, потом смеяться, напишет и порвёт заявление об уходе, а потом запостит всё на какой-нить ресурс типа ithappens

+16

RicoX 5 янв 2013 в 20:20

Оптика протянется, чуток прогадали со временем и не успели до зимних праздников и нагрузка резко возросла — это затычка до конца каникул. Про запуск по крону раз в минуту писал, Вы невнимательны. Когда руководству сетей предлагаешь вариант быстро, без затрат, но через задницу или долго, с доп затратами, но «по-феншую», почти всегда выбирают первое. Я обрисовал варианты и дал выбрать, что было выбрано, то и сделал. Если кто знает, как решить по другому, быстро и без затрат — внимательно выслушаю. Я бы сам просто выделил новую подсеть и не делал этого ужаса, но условием было то, что ничего не нужно перенастраивать у абонентов со статикой (да да есть сети которые не используют DHCP). Заметка не об этом, а о том как использовать несколько одинаковых IP на разных интерфейсах, в некоторых случаях бывает удобно.

spiritedflow 5 янв 2013 в 20:33

Зря надеетесь на оптику, её порвут, а потом трактором бухту переедут. Надо было писать как бы надолго, хотя бы сделать вид. Ну там в скрипт вставить поддержку --help, сам скрипт в репозиторий, вести версии, changelog. Тогда возможно и была бы и оптика…

А теперь надежды нет ;) Закон прост: чем больше изоленты, тем дольше это будет жить, а если делать надолго и с расчётом, то скорее всего через пару месяцев будет не нужно. Судьба любит изоленту…

P.S.: я не пытаюсь обидеть, это всё грустный сарказм. Сам писал жуткие костыли, а потом удивлялся, как эти костыли работали дольше и лучше, чем основательные решения.

RicoX 5 янв 2013 в 20:39

Да какие обиды, я бы ваш комментарий переписал практически слово в слово, если бы не сам делал этот костыль. А в других сетях находил такое, о чем даже вспоминать страшно и при этом работало годами и всех устраивало.

helldesigner 5 янв 2013 в 21:15

Как ни печально, но так обычно всегда и бывает, и не только в администрировании но и в разработке ПО. Делается быстро как-нибудь, чтобы заработало, а потом так и работает и сверху лепится тоже что-то подобное.