Задумался я тут о том, как бы перевести текущую сеть на технологию 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 нет и не будет.
.thumb.png.5e5de58268d04b8680ee8682403b79cb.png)
.png.5746e4bc5ccc2b5b0ebf1ab3595a7771.png)