Перевод сети на vlan per user

[televid]

Задумался я тут о том, как бы перевести текущую сеть на технологию vlan per user.

Сейчас сделан влан на коммутатор доступа, и оно как бы работает, но хочется лучше. Схема сети такая - микротик в качестве браса и маршрутизатора (на нём бгп с одним default route и одним пиринговым соединением, шейперы, файерволл, нат и dhcp-серверы для домовых вланов). Коммутатор ядра - SNR 4550, который сейчас занимается только несколькими вланами - ядро, аплинки и менеджмент. Коммутаторы агрегации - SNR2995. На агрегации домовые вланы сразу терминируются и дальше до микротика идёт уже L3 в влане ядра. Между агрегациями и микротиком поднят OSPF, чтобы не писать маршруты руками. Также на агрегациях подняты dhcp-релеи в домовых вланах. На доступе полный зоопарк от DES3526 и SNR2985 до пары DCN и Huawei. Абонентские порты все в первом влане, который на агрегации терминируется как порядковый.

 

Что мне нравится - однотипная конфигурация доступа. Монтажники просто берут готовый подменный коммутатор с типовым конфигом и всё. Это важно, так как коммутаторы выходят из строя не то чтобы часто, но именно в неподходящий момент. Достаточно простая и прозрачная конфигурация всего остального. Практически чистый роутинг, загрузка микротика выше 20% не поднимается, даже с учётом немаленького списка блокировки БелГИЭ на файерволле и кучи PCQ-очередей. Отсутствие привязки абонента к порту/влану  - сдох порт/перебили кабель - монтажники приехали, пересадили абонента на другой порт или вообще на соседний коммутатор без лишних телодвижений.

 

Что мне не нравится - невозможность выдачи белых адресов и ipv6. Отсутствие привязки абонента в биллинге кроме как по мак-адресу (в биллинге нет информации об ip-адресе пользователя, dhcp-серверы на микротике просто обращаются к радиус-серверу биллинга), из-за чего пришлось писать скрипты для микротика, которые работают ооочень медленно. Ну и вообще некоторый бардак в организации сети - строилось всё абы как (на плинтах, например, не помечено какие это порты коммутатора), биллинг натягивался на уже работавшую сеть как сова на глобус.

 

Чего хочется - в идеале чтобы со стороны биллинга и абонентов это выглядело как плоская сеть, на самом деле ею не являясь. Чтобы не пришлось вводить привязки адресов к домовым вланам. Избавиться от OSPF - работает без нареканий, но для ipv6 всё равно надо переходить на OSPFv3, так что почему бы его вообще не выкинуть. Возможность выдачи абонентам как белых, так и серых адресов, в дуалстеке. Желательно просто по нажатию кнопочки в личном кабинете (т.е. по умолчанию все абоненты за натом). Однотипной конфигурации доступа и агрегации (чтобы биллингу для выдачи белого адреса не надо было жонглировать вланами по всей цепочке). И хотелось бы сохранить связность внутри сети. Внутреннего трафика мало, но пусть будет.

 

Собрал тестовый стенд, проверил пару идей и все мне как-то не очень понравились. Обычный vlan per user через qinq с подобием ip unnumbered потребует заведения на микротике примерно 7200 вланов, их интерфейсов и dhcp-релеев (300 домовых коммутаторов по 24 порта, но абонентов всего полторы тысячи). Не уверен, что такое будет работать устойчиво. Либо придётся городить скрипты, которые будут это как-то создавать динамически. Т.е. например, есть default vlan без доступа в остальную сеть, при выдаче в нём адреса абоненту срабатывает lease-скрипт, которые перекидывает это всё куда надо (не обязательно микротиковский скрипт, по идее можно делать это биллингом при получении радиус-запроса).

Если делать supervlan на SNR4550, то он поддерживает только до 512 субвланов на один супервлан, плюс надо указывать какие диапазоны в каких субвланах, т.е. всё равно "дробить сеть на сегменты" и привязывать абонентов к коммутаторам (иначе арп-запросы уложат процессор).

Теоретически ещё можно использовать supervlan на агрегации, сразу терминируя абонентские вланы, но такой вариант я не тестировал, да и не слишком он на мой взгляд лучше текущей схемы. Текущую схему в аттаче прилагаю.

Может, кто-то делал что-то подобное?

 

PS. Денег на циску с ip unnumbered нет и не будет.

[TriKS]

40 минут назад, televid сказал:

Обычный vlan per user через qinq с подобием ip unnumbered потребует заведения на микротике примерно 7200 вланов

Да.

40 минут назад, televid сказал:

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

Забудьте. Это дичайшая фигня выйдет.

40 минут назад, televid сказал:

Отсутствие привязки абонента в биллинге кроме как по мак-адресу (в биллинге нет информации об ip-адресе пользователя, dhcp-серверы на микротике просто обращаются к радиус-серверу биллинга), из-за чего пришлось писать скрипты для микротика, которые работают ооочень медленно. Ну и вообще некоторый бардак в организации сети - строилось всё абы как (на плинтах, например, не помечено какие это порты коммутатора), биллинг натягивался на уже работавшую сеть как сова на глобус.

С этого и начать.

 

40 минут назад, televid сказал:

Также на агрегациях подняты dhcp-релеи в домовых вланах.

Зачем?

40 минут назад, televid сказал:

Между агрегациями и микротиком поднят OSPF, чтобы не писать маршруты руками.

Зачем?

40 минут назад, televid сказал:

На агрегации домовые вланы сразу терминируются и дальше до микротика идёт уже L3 в влане ядра.

Зачем?

 

 

Все что вам надо - сделать простой L2. Побить сегменты на Svlan's. Допустим каждый свич - свой Svlan, абонпорты- cvaln's допустим с 101-124. Все типово выйдет. Разные только S на агрегаторах, что будут паковать, ну и адреса для управления. 

Edited March 23, 2020 by TriKS

[zavndw]

если брас не принципиален, то к простому L2 добавляете accel-ppp (в нем заводите Svlan) и с билллингом по радус стыкуете

[pingz]

Хотите все просто, то микротик вам не подойдет. Автоматически интерфейсы может создавать cisco(про qnq не знаю, скорее да чем нет), juniper может создавать qnq интерфейсы автоматически, но есть свои проблемы флоу льется не как у микротика + на mx серии нет ната без платы. Думаю на Хуавей то же есть, ерексоны в 2021 не стоит рассматривать. 

 

Оптимальное решение скорее всего скат (:

[EShirokiy]

@televid про микротик забудьте, он в принципе как брас - говно, сами в подобной ситуации были. Используйте Accel-ppp разворачивается достаточно просто, если знакомы с линуксом. На агрегации будете разворачивать QinQ в сторону доступа, но доступе пропишите вланы, например 101-124. Биллинг какой? Пишите в чатик в телеграме, там помогут с accel https://t.me/accel_ppp

 

[Ser]

Я тоже vlan-per-user делал. Accel-ppp не взлетел.

Пришлось накидать скрипты и сделать брас на linux.

Единственное, пришлось dhcp-relay убрать на отдельный linux, который работает в виртуалке.

 

Биллинг выдает адреса на основании option82 remote-id

 

Свичи домовые имеют типовой конфиг, развиланивают порты 101-124

 

На агрегации добавляем s-vid .

 

Все достаточно просто и универсально.

 

Если нужны подробности, обращайтесь.

 

Есть еще https://therouter.net/, но автор куда-то пропал.

Edited March 24, 2020 by Ser

[televid]

Понятно, всем спасибо. Скорее всего действительно будем переходить на брас на линуксе. Когда-то смотрел в сторону vyatta/vyos/cumulus, но они слегка для другого сделаны.

Ещё такой вопрос - как при vlan per user решать ситуацию, когда в одном ящике доступа два коммутатора на одной жиле? И правильно ли я понимаю, чтобы потом не выдирать из двойного тегирования влан управления домовыми коммутаторами, на агрегации нужен не просто qinq, а selective qinq, который влан управления будет пропускать как обычно, а абонентские вланы заворачивать в svlan?

[TriKS]

Для доступа к управлению - да.

[EShirokiy]

@televid можно повесить управление на s-vlan, те на свитче управление будет в 1ом влане.

[televid]

@EShirokiy Тоже вариант. Но тут проблема в том, что на DES3526, например, поменять влан управления просто так не получится - при загрузке нового конфига коммутатор его тут же начинает выполнять построчно, теряет управление и остаётся в раздрае, когда старый интерфейс уже погашен, а новый не поднят. Это на нормальных коммутаторах можно скопировать конфиг в startup.cfg и перезагрузиться.

[semop]

Ага)

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

[LostSoul]

1 час назад, televid сказал:

коммутатор его тут же начинает выполнять построчно

да ладно?

много раз подгружал с tfp фрагменты конфига меняющие IP/шлюз, все было ок.

активация snmp запросом, если что

 

[televid]

@LostSoul вот по snmp я не пробовал, спасибо за подсказку.

[televid]

А вообще можно как-то выкрутиться, когда порты коммутаторов не подписаны? Обходить, проверять и подписывать некому, увы. Информацию по существующим абонентам можно простеньким скриптом собрать, а как быть с новыми?

[AlKov]

36 минут назад, televid сказал:

а как быть с новыми?

Выдать монтажнику нетбук с известным МАС адресом и искать его (этот МАС) на коммутаторе доступа.

Для длинк-ов командой telnet show fdb mac 11-22-33-44-55-66, которая выдаст номер порта.

Можно и по snmp, но тогда придётся "расшифровывать" ответ скриптом. В telnet проще, всё на ассоциативном уровне. :)

[igaroper]

В 24.03.2020 в 10:25, Ser сказал:

Я тоже vlan-per-user делал. Accel-ppp не взлетел.

Пришлось накидать скрипты и сделать брас на linux.

Единственное, пришлось dhcp-relay убрать на отдельный linux, который работает в виртуалке.

 

Биллинг выдает адреса на основании option82 remote-id

 

Свичи домовые имеют типовой конфиг, развиланивают порты 101-124

 

На агрегации добавляем s-vid .

 

Все достаточно просто и универсально.

 

Если нужны подробности, обращайтесь.

 

Есть еще https://therouter.net/, но автор куда-то пропал.

 

Поделитесь, пожалуйста конфигами. Планирую перейти на такую же схему. Пока не получается

[pppoetest]

В 23.03.2020 в 21:04, zavndw сказал:

если брас не принципиален, то к простому L2 добавляете accel-ppp (в нем заводите Svlan) и с билллингом по радус стыкуете

Запустил по этой схеме, в продакте 2й месяц, ненарадуюсь.

 

В 24.03.2020 в 13:23, televid сказал:

Ещё такой вопрос - как при vlan per user решать ситуацию, когда в одном ящике доступа два коммутатора на одной жиле?

У мну в биллинге, в инвентори, есть такой параметр как №коммутатора в колбасе(0-х), на основе него и генерится конфиг для свитча, где номер c-vlan = 100 + №коммутатора в колбасе * 48 + номер порта, а на агрегации соот-щие selective qinq policy

В 24.03.2020 в 13:23, televid сказал:

И правильно ли я понимаю, чтобы потом не выдирать из двойного тегирования влан управления домовыми коммутаторами, на агрегации нужен не просто qinq, а selective qinq, который влан управления будет пропускать как обычно, а абонентские вланы заворачивать в svlan?

Именно так, у нас selective qinq

[ne-vlezay80]

В 23.03.2020 в 17:17, televid сказал:

PS. Денег на циску с ip unnumbered нет и не будет.

На linux хуть - netns per user :))
На linux это есть