dimzerman Опубликовано 4 февраля, 2021 (изменено) · Жалоба Сеть компании представляет собой большой 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 управления? Я не смог найти информации, есть ли какой-то принцип деления вилана управления? Например, один на агрегацию или ещё как-то. Изменено 4 февраля, 2021 пользователем dimzerman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stalker86 Опубликовано 4 февраля, 2021 · Жалоба Для начала избавиться от "Один vlan для пользователей с получением "белого" адреса через pppoe и без pppoe, который простирается на всех коммутаторах." Перейти как минимум на vlan на коммутатор. А дальше изоляция абонентских портов между собой Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dimzerman Опубликовано 4 февраля, 2021 (изменено) · Жалоба 3 часа назад, stalker86 сказал: Перейти как минимум на vlan на коммутатор. на каждом коммутаторе будет свой отдельный абонентский vlan, хм. А если у меня будут клиенты со статическими адресами, в разных vlan, но из одной подсети, как мне тогда их объединять? Чтобы один клиент, допустим из 101 vlan, два клиента из 102 vlan и пять клиентов из 103 vlan могли видеть один и тот же шлюз по умолчанию. Делать Ip unnumbered, и машрут /32 до каждого в их vlan? Изменено 4 февраля, 2021 пользователем dimzerman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 4 февраля, 2021 · Жалоба Прописываете на каждом коммутаторе уникальные вланы для каждого абонентского порта, например начиная с 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 уже в центр абонентский трафик передавать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dimzerman Опубликовано 4 февраля, 2021 (изменено) · Жалоба 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. Изменено 4 февраля, 2021 пользователем dimzerman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 5 февраля, 2021 · Жалоба Тут зависит от типа авторизации. Можно делать и один влан на коммутатор и тянуть его в центр. На коммутаторе настраиваете изоляцию портов (это когда все абонентские порты могут принимать и передавать трафик только в порт в сторону центра). Но тут встает вопрос как отделять абонентов друг от друга. Здесь могут быть только 2 варианта: 1. Авторизация по порту, то есть по опции 82. 2. Авторизация по мак адресу. В обоих случаях нужен радиус сервер в биллинге. Вариант 1 плох тем, что будете зависеть от реализации схем коммутаторов, всякие там релеи и прочее устаревшее барахло. Но сам биллинг может быть тупой. Вариант 2 самый хороший, но требует портала авторизации по такой схеме: 1. Клиент включает свое новое оборудование в любой порт любого коммутатора. 2. DHCP сервер запрашивает у радиус сервера (у биллинга), какой IP выдать на этот мак адрес. Если в биллинге такой не заведен - тогда выдать адрес из серой подсети, доступ из которой в интернет закрыт, и все запросы переавторизуются на портал авторизации. 3. Портал выдает ему в веб окно ввода логина и пароля (этот портал может быть и в составе биллинга), биллинг проверяет есть ли такой клиент, если есть то подставляет ему мак адрес этого абонента и через 5-10 минут (время аренды DHCP), абонент повторно запрашивает IP на свой мак, биллинг мак уже знает и выдает ему нужный IP адрес. По сути только эта схема подходит для больших сетей, т.к. привязка к порту это отчасти плохо, особенно если сеть на коммутаторах и монтажники могут кабели перепутать у абонентов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
laplundik Опубликовано 7 февраля, 2021 · Жалоба Чет там сааб намудрил даже читать не стал много буков. Самое простое разрешить кадры MAC протокола на портах пппое и запретить все. Влан абонентский на коммутатор Схема работает много лет, идеально. На всем оборудовании минимум конфига, конфиг на всех железках однотипный меняется vlan и ip адрес. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dimzerman Опубликовано 8 февраля, 2021 · Жалоба спасибо за информацию, попробую проверить на стенде) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
titan Опубликовано 9 февраля, 2021 · Жалоба L3 ставить на агрегации не обязательно, достаточно одного L3 в ядре. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 9 февраля, 2021 · Жалоба В 07.02.2021 в 18:44, laplundik сказал: Чет там сааб намудрил даже читать не стал много буков. Надо было первое сообщение прочитать - там написано что будет переход на IPoE=) 46 минут назад, titan сказал: L3 ставить на агрегации не обязательно, достаточно одного L3 в ядре. Это зависит от размеров сети и имеющихся каналов. Иногда не всегда выгодно тянуть все в центр. Особенно если уже какое-то кольцо или некая связанность имеется в обход центрального узла. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...