Изоляция абонентов PPPoE

[dimzerman]

Сеть компании представляет собой большой L2 сегмент, примерно 200 коммутаторов. В основном используются коммутаторы SNR-S2950-24G, в агрегациях SNR-S2970G-24S, ядро - Mikrotik CCR1036-12G-4S.

Агрегации L3 не умеют, поэтому абоненты по L2 тянутся аж до ядра.

Метод подключения абонентов - PPPoE, ip-телефонии нет и не планируется. Один управляющий vlan на всех коммутаторах, один vlan для пользователей с получением "белого" адреса через pppoe и без pppoe, который простирается на всех коммутаторах. Для абонентов с серыми ip-адресами, которые затем летят в NAT, так же имеется 40 виланов, которые прописывались абсолютно в произвольном порядке, нет какого-то логического деления. По большей части в сети много колец, максимально из 16 коммутаторов. Но встречается и немного звёзд.  Уф.

 

Сейчас стоят следующие задачи: 

- избавиться от широковещательных штормов,

- избавиться от паразитного трафика от абонентов.

 

В будущем агрегации будут заменены на L3 коммутаторы и произведен переход на IPoE, но не в ближайшие пару лет.

 

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

А теперь, внимание, вопросы!

- Каким образом можно изолировать абонентов внутри одного vlan друг от друга? Это необходимо, чтобы отсечь широковещательный паразитный трафик.

Q-in-q эта модель коммутатора SNR не умеет. Стоит ли использовать Private Vlan, и таким образом принимать всех абонентов со всех коммутаторов в одном vlan на Микротике? 

Либо возможны какие-то ещё альтернативы?
- Стоит ли делать несколько Vlan управления? Я не смог найти информации, есть ли какой-то принцип деления вилана управления? Например, один на агрегацию или ещё как-то.

 

Edited February 4, 2021 by dimzerman

[stalker86]

Для начала избавиться от "Один vlan для пользователей с получением "белого" адреса через pppoe и без pppoe, который простирается на всех коммутаторах."
Перейти как минимум на vlan на коммутатор.
А дальше изоляция абонентских портов между собой

[dimzerman]

3 часа назад, stalker86 сказал:

Перейти как минимум на vlan на коммутатор.

на каждом коммутаторе будет свой отдельный абонентский vlan, хм. А если у меня будут клиенты со статическими адресами, в разных vlan, но из одной подсети, как мне тогда их объединять? Чтобы один клиент, допустим из 101 vlan, два клиента из 102 vlan и пять клиентов из 103 vlan могли видеть один и тот же шлюз по умолчанию. Делать Ip unnumbered, и машрут /32 до каждого в их vlan?

Edited February 4, 2021 by dimzerman

[Saab95]

Прописываете на каждом коммутаторе уникальные вланы для каждого абонентского порта, например начиная с 100 и так далее, все их стягиваете в центр.

На микротике заводите все эти вланы и в каждый делаете

 

/interface vlan
add arp=reply-only interface=bridge_vlan name=vlan_23 vlan-id=23

/ip address
add address=192.1.20.1/32 network=192.1.20.23 interface=vlan_23

/ip pool
add name=dhcp_pool_23 ranges=192.1.20.23

/ip dhcp-server
add add-arp=yes address-pool=dhcp_pool_23 disabled=no interface=vlan_23 lease-time=5m name=dhcp_23

Далее получаете плюсы:

1. Никакой передачи трафика напрямую между абонентами.

2. Никакого флуда на сети между портами - все идет только в центр.

3. Полная изоляция абонентов.

4. Полный контроль сети.

 

IP адреса будете раздавать поштучно и у всех абонентов будет большая маска подсети и у всех один шлюз.

 

5 часов назад, dimzerman сказал:

Стоит ли делать несколько Vlan управления? Я не смог найти информации, есть ли какой-то принцип деления вилана управления? Например, один на агрегацию или ещё как-то.

Влан управления это тот же канал для передачи мусорного трафика и флуда. Но тут встает вопрос - а если весь абонентский трафик во вланах, то зачем нужен влан управления?

Вот честно - вы достаете коммутатор из коробки и заходите в настройки по дефолтному IP - он же без влана работает?

И если в терминологии коммутатора указано что управление во влане 1, то есть без влана, а каждый абонентский порт упакован в свой влан - то абоненты же никак не смогут в управление попасть.

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

 

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

 

5 часов назад, dimzerman сказал:

В будущем агрегации будут заменены на L3 коммутаторы и произведен переход на IPoE, но не в ближайшие пару лет.

А сейчас что мешает перейти? И зачем L3 коммутаторы тут?

Что бы давать IPoE не нужны L3 коммутаторы, тут нужен прямой путь от абонентского порта в центр. Вы уже сейчас можете на старой сети тем абонентам, которые готовы перейти на новую авторизацию порты потихоньку во влан перекидывать и все.

 

А для полного счастья нужно существующую сеть микротиками роутерами разделить на сегменты, и между ними через L3 по OSPF уже в центр абонентский трафик передавать.

[dimzerman]

2 часа назад, Saab95 сказал:

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

многовато получится vlan, и с учетом роста сети и L2 агрегациями они быстро закончатся)
Сейчас думаю над темой vlan на коммутатор.

Я правильно понимаю, что на каждом коммутаторе все абонентские порты будут в одном  vlan, добавляется изоляция портов (трафик сегментация), и все vlan на всех коммутаторах получают через ip-unnumbered ip-адреса и доступ к общему шлюзу, из каждой абонентской vlan?
Тогда ещё один момент, если к коммутатору подключается, например, веб-камера, которой нужна отдельная ip-подсеть, нужно ли для этого делать отдельный vlan на каждом коммутаторе? Или, раз у нас порты изолированные внутри vlan, можно на тот же раздающий ip-адреса интерфейс по ip unnumbered добавить secondary ip, и камеру оставить в абонентском vlan? Или на каждый новый сервис, требующий отдельной подсети, нужно добавлять дополнительно на каждый коммутатор по vlan? Извините, если вопросы дурацкие, но я не могу найти реализацию vlan-per-switch без q-in-q.
 

Edited February 4, 2021 by dimzerman

[Saab95]

Тут зависит от типа авторизации.

 

Можно делать и один влан на коммутатор и тянуть его в центр. На коммутаторе настраиваете изоляцию портов (это когда все абонентские порты могут принимать и передавать трафик только в порт в сторону центра).

 

Но тут встает вопрос как отделять абонентов друг от друга. Здесь могут быть только 2 варианта:

 

1. Авторизация по порту, то есть по опции 82.

2. Авторизация по мак адресу.

 

В обоих случаях нужен радиус сервер в биллинге.

 

Вариант 1 плох тем, что будете зависеть от реализации схем коммутаторов, всякие там релеи и прочее устаревшее барахло. Но сам биллинг может быть тупой.

Вариант 2 самый хороший, но требует портала авторизации по такой схеме:

 

1. Клиент включает свое новое оборудование в любой порт любого коммутатора.

2. DHCP сервер запрашивает у радиус сервера (у биллинга), какой IP выдать на этот мак адрес. Если в биллинге такой не заведен - тогда выдать адрес из серой подсети, доступ из которой в интернет закрыт, и все запросы переавторизуются на портал авторизации.

3. Портал выдает ему в веб окно ввода логина и пароля (этот портал может быть и в составе биллинга), биллинг проверяет есть ли такой клиент, если есть то подставляет ему мак адрес этого абонента и через 5-10 минут (время аренды DHCP), абонент повторно запрашивает IP на свой мак, биллинг мак уже знает и выдает ему нужный IP адрес.

 

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

[laplundik]

Чет там сааб намудрил даже читать не стал много буков.

Самое простое разрешить кадры MAC протокола на портах пппое и запретить все.

Влан абонентский на коммутатор

Схема работает много лет, идеально. На всем оборудовании минимум конфига, конфиг на всех железках однотипный меняется vlan и ip адрес.

[dimzerman]

спасибо за информацию, попробую проверить на стенде)

[titan]

L3 ставить на агрегации не обязательно, достаточно одного L3 в ядре.

[Saab95]

В 07.02.2021 в 18:44, laplundik сказал:

Чет там сааб намудрил даже читать не стал много буков.

Надо было первое сообщение прочитать - там написано что будет переход на IPoE=)

 

46 минут назад, titan сказал:

L3 ставить на агрегации не обязательно, достаточно одного L3 в ядре.

Это зависит от размеров сети и имеющихся каналов. Иногда не всегда выгодно тянуть все в центр. Особенно если уже какое-то кольцо или некая связанность имеется в обход центрального узла.