Jump to content
Калькуляторы

В чем главная Техническая сложность? в предоставлении VLAN на пользователя

А кто-нибудь пробовал при такой схеме в качестве агрегатора использовать Juniper EX3200? Есть ли в нем ip unnumbered? С первого взгляда железка смотрится сурово :) - 7000 ACE, uplink-модули либо под 2xXFP либо 4xSFP, GVRP, JunOS.

Стоит дешевле новой 3750G.

Share this post


Link to post
Share on other sites
Осталось ответить на 1 вопрос:

А зачем при таком железе ВЛАН на порт? слава богу у 3028 и 3526 есть АЦЛ и управление полосой.... отключать и включать можно по СНМП...

ТАК ЗАЧЕМ ВЛАН на порт? Гемора себе добавить???? :-)...

Хм... Тоже вариант. Надо будет поразмыслить над ним. Просто я занимаюсь доксисом и привык, что мимо меня никакой трафик не пройдет. То же самое в локалке даст только vlan.

Тогда встречный вопрос: есть ли опыт, как живут эти аппараты при, скажем, десятке правил на порт, 100% подключений и все 24 пользователя нагружают порты, как могут? Просто тэг на пакет подвесить - это одно, а покопаться в его внутренностях и на основе раскопанного вынести вердикт - это несколько другое :)

 

Вопрос агрегации кучи оптики с домов или групп домов это всё равно не отменяет :)

Share this post


Link to post
Share on other sites

Я думаю, можно не только jab-а, можно и кого подешевле...

Share this post


Link to post
Share on other sites
А кто-нибудь пробовал при такой схеме в качестве агрегатора использовать Juniper EX3200? Есть ли в нем ip unnumbered?

Нету в нём ip unnumbered. И хз когда будет. Так же и в 4200.

Share this post


Link to post
Share on other sites
Осталось ответить на 1 вопрос:

А зачем при таком железе ВЛАН на порт? слава богу у 3028 и 3526 есть АЦЛ и управление полосой.... отключать и включать можно по СНМП...

ТАК ЗАЧЕМ ВЛАН на порт? Гемора себе добавить???? :-)...

Хм... Тоже вариант. Надо будет поразмыслить над ним. Просто я занимаюсь доксисом и привык, что мимо меня никакой трафик не пройдет. То же самое в локалке даст только vlan.

Тогда встречный вопрос: есть ли опыт, как живут эти аппараты при, скажем, десятке правил на порт, 100% подключений и все 24 пользователя нагружают порты, как могут? Просто тэг на пакет подвесить - это одно, а покопаться в его внутренностях и на основе раскопанного вынести вердикт - это несколько другое :)

 

Вопрос агрегации кучи оптики с домов или групп домов это всё равно не отменяет :)

Прекрасно они живут... их пол России испльзует.

Share this post


Link to post
Share on other sites

Ну вот я начала писать статью, покритикуйте. И добавьте в неё больше практики. Ибо она у меня обобщающая.

Широкое использование ACL на оборудовании доступа было востребовано в

классической схеме построения сетей привязка IP, MAC и VLAN на квартал).

L2 коммутатор. Основная задача ACL – защита абонентов от атак различного типа и контроль действий абонента, а так же выставление приоритетов для различного типа трафика. Если все пользователи находятся в одном VLAN: Абонент A сканирует свой сегмент сети, выясняет IP адреса абонентов и шлет им броадкаст запрос (ARP request) c их IP адресом. В итоге, к примеру, абоненты C и B находящиеся в одном VLAN получают этот пакет и отвечают на него, пересылая свои данные: IP и MAC. В итоге Абонент А может получить данные обо все абонентах в сети. Абонент А посылает ARP поддельный пакет абоненту С (авторизация для ARP пакетов не требуется), где будет указанно, что у абонента B теперь другой MAC адрес, фактически подставляя свой. Теперь абонент C будет думать, что общается с абонентом B, а на самом деле общается с абонентом A.

Таким образом, можно подменить адрес почтового сервера или DNS сервера, что в итоге может привести к полному перехвату данных от всех абонентов абонентом А (злоумышленником). Злоумышленник так же может увеличить нагрузку на все коммутаторы, в сети рассылая запросы ARP с неизвестными MAC адресами – вызывая Unicast Storm. Аналогично ведут себя почтовые вирусы.

Изоляция портов не помогает избежать данной ситуации, поскольку все запросы приходят на соседний порт коммутатора через порт следующего коммутатора. Привязка IP, MAC так же не помогает, поскольку MAC адрес

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

Если все пользователи находятся в одном VLAN:

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

включены сразу в коммутатор L3.

На всех коммутаторах должны поддерживаться следующие функции: Port Isolation, привязка

IP&MAC, ACL, ограничение штормов Unicast

Достоинства

+ Большой выбор оборудования

Недостатки

- Дорогое решение, необходима прокладка отдельной оптики до каждого дома и использование

мощных коммутаторов L3

- Большие эксплуатационные затраты на управление оборудованием

- Большое время реакции при добавлении/смене абонентами компьютеров

Итог: необходимость поддержки большого количества ACL в коммутаторах доступа и постоянный

контроль их актуальности.

Вес трафик необходимо доводить до точки объединения на L3

коммутаторах. Где VLAN с разных кварталов объединяются в один и

абоненты могут обмениваться трафиком по IP. Это увеличивает нагрузку на сетевые элементы сети:

коммутаторы L3 начинают маршрутизировать трафик вместо коммутации и работать с приоритетами на L3. При использовании центрального маршрутизатора сеть менее подвержена перегрузкам.

Итог: Большая нагрузка на сеть из-за использования коммутаторов L3 для маршрутизации трафика.

 

Share this post


Link to post
Share on other sites

что-то всё у Вас в голове перемешалось: и АРЛ-спуфинг, и топологии сети доступа... Оба подхода работоспособны, и, более того, это не единственные способы - есть ещё туннели... А то что Вы пытаетесь написать - есть в wiki на этом самом сайте. По крайней мере частично.

 

Возвращаясь к теме топика - в предоставлении влан на пользователя нет ТЕХНИЧЕСКИХ сложностей, есть сложности ЭКОНОМИЧЕСКИЕ.

Share this post


Link to post
Share on other sites
Получается всего-то в 3 раза дороже заявленного - как у правильных интеграторов :P

А 6500 умеет терминировать более 4к vlan'ов?

... И приведите пример "правильных интеграторов" со сравнимой ценой.

Про правильных интеграторов имелась ввиду не цена решения, а разница в первоначально заявленной и в конце полученной :) Извиняюсь за косность изложения приведшую к непоняткам.

 

___

 

Про vlan-per-user я бы сказал так. Пока клиент причесан и построен - по одному адресу в руки все вполне себе легко и просто - при установке клиентского свича нарулил виртуалок по числу портов, принял их на терминирующей железки и порядок. Но как только начинается попытка мешания физиков/юриков или реализация "светлых мыслей" слегка выбивающихся из начальной концепции, то сложность удержания системы от хаоса растет пропорционально разношерстности типов подключений/услуг

Share this post


Link to post
Share on other sites
А 6500 умеет терминировать более 4к vlan'ов?
Есть один хитрый способ, пригоден также для 35,36,37 и 45: http://forum.nag.ru/forum/index.php?s=&amp...st&p=386273

 

post-4886-1237216793_thumb.png

 

Потолок где-то 8К на 65 или 64К на 76й.

зачем так усложнять? две оптики к разным свичам..

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

между свичами маршрутизация есно.

Share this post


Link to post
Share on other sites
зачем так усложнять? две оптики к разным свичам..
Это развёрнутая схема тестового стенда, причем больше она относится к ISG на 7200 с резервированием. В оригинале идея намного проще:

post-4886-1225194523_thumb.png

 

масштабируется очень просто, ставится ещё одна железка, с ещё одной тысячей уникальных вланов, и на неё перекидывается часть домов.
С уникальными вланами есть проблема - их макс. 4К, и администрировать их удовольствие ниже средного...

Share this post


Link to post
Share on other sites
вот труъ аггрегация, осталось по ip unnumbered добить окончательно суппорт(уже плавно приближается к этому) :)

Кто ж спорит))) Только вот когда они "добъются"? Без unnumbered же оно не тру)))

Share this post


Link to post
Share on other sites
Я думаю, можно не только jab-а, можно и кого подешевле...

Я из серверной материнки 4-Core XEON выжал где-то 1.2-1.3 Gbps без винта, но с контролем доставки "на той стороне в логи" (не TCP, свойформат пакетов). Допускаю, что я непрофессионал.

Share this post


Link to post
Share on other sites

Core Quad 2.83, мать с 4 сетевухами гигабитными на борту (броадкомы какие-то там без особых выкрутасов, но хавают прерывания через MSI-X), работает как агреатор от шлюзов доступа, у них это маршрут по умолчанию, выводит в инет через 3 мировых аплинка с фул вью и столько-же локальных точек обмена трафика (где трафика много бегает но маршрутов до 3 тыс). Сетевухи в ЛАСП подняты со свичем, абы утилизировать полосу всю. Там понятно вланы бегают. Так вот такой сервер по графикам уже было за 400 кило пакетов заваливал при этом загрузка ядер в районе 33-37 % так как каждое яро свою сетевуху хавает, а ласп паралелит нагрузку то вполне ровно по ядрам ложится в пределах 1-2 % разница). Трафика реальн бегало при таких раскладах 2.8-3 Гига, на вход и сотвественно стоко на выход :) ибо типа большая одна сетевуха на 4 гигабита.

На тему агрегатора кучи юзеров на линухе (про фрю не скажу) (через вланы с подсетями или влан на юзера), там особая проблема становится, что часть кода которая отвечает за арп обработку немного странноватая. И ядро на каждую попытку определить мак, что ядро кинуло запрос и запомнило в таблицы как еще не определен мак, создает таймер ядра (видел когда этих таймеров тьма была создана, по этой причине, и на одном и ядер практически отжиралось все время ядровым потоком евент, что какраз и обрабатывает списки таймеров). А такой шквал легко генерит 10-20 юзеров с вирусами и ли сканерами сети что сканят соседние сегменты (апаратные коммутаторы 3 уровня, средних цен, вообще уходили в коматоз со своими максимум в 800 Мгц процами. Вот все хочу эту часть поменять ядра но все нету времени доделать. Также по поводу ната на линухе если подкрутить в ядре размер хеш масива конектов к реальной нагрузке то лихо линейно маштабируется производительность. А то туда забили 16384 размер а когда конектов под 80-100 к вивист то уже хеш часто в списки выстраивается :(, а поминять этот параметр или в модуле правь код или при его загрузке через параметры, а потом уже в работе все поменять низя, ибо это шаред список для всех ядер системы. Вот такое по производительности железок на базе ПК.

Edited by JMan

Share this post


Link to post
Share on other sites

Ребята я вот в чем торможу.

1) Поставил я на доступ скажем DES-3028 (прописал там VLAN-ы)

2) Поставил кошку 3550 для терминирования VLAN-ов и все VLAN-ы с коммутаторов доступа поднялись на 3550.

3) Для того чтобы пользователи не могли входить в систему (Интернет и локалка) без авторизации поставил сервер Микротик / ФриБСД и кошку 3550 соединил с этим серваком и стал терминировать на нём PPPoE.

 

Теперь я не врубаюсь, после такой лабуды пользователи будут друг друга видеть или каждый будет в своём VLAN-е ?

Трафик любой будет бегать через сервер Микротик / ФриБСД так как это PPPoE?

 

В целом не понятен принцип взаимосвязи между кошкой 3550 и сервер Микротик / ФриБСД ..

 

 

Прошу объяснить!

 

 

 

Share this post


Link to post
Share on other sites
Ребята я вот в чем торможу.

1) Поставил я на доступ скажем DES-3028 (прописал там VLAN-ы)

2) Поставил кошку 3550 для терминирования VLAN-ов и все VLAN-ы с коммутаторов доступа поднялись на 3550.

3) Для того чтобы пользователи не могли входить в систему (Интернет и локалка) без авторизации поставил сервер Микротик / ФриБСД и кошку 3550 соединил с этим серваком и стал терминировать на нём PPPoE.

Это зачем? Откуда тут взялся этот рудимент?

Share this post


Link to post
Share on other sites

непонятно зачем PPPoE если кошка умеет ip unnambered. Используйте её для терминирования, а бсд-писюк для шейпинга\ната\управления доступом

Share this post


Link to post
Share on other sites
непонятно зачем PPPoE если кошка умеет ip unnambered. Используйте её для терминирования, а бсд-писюк для шейпинга\ната\управления доступом
Я еще не знаю что такое IP unumbered. Ну даже в этом случае по какому принципу происходит связь между Cisco 3550 и ФриБСД?

 

 

Share this post


Link to post
Share on other sites

http://www.cisco.com/en/US/products/hw/swi...#switchdatabase

 

Тут написано что 3550 поддерживает всего 8 SVI, это означает что лишь 8 пользователей могут одновременно вести обмен меж собой находясь в разных VLAN-ах ?

Share this post


Link to post
Share on other sites
Тут написано что 3550 поддерживает всего 8 SVI,

Это рекомендованное число SVI интерфейсов. Максимум их на 3550 1000.

Share this post


Link to post
Share on other sites

Значит получается что наиболее частый сценарий это установка на агрегацию кошек 3550 на агрегацию, выделение VLAN на пользователя. Один VLAN выделен для шлюза на FreeBSD через который юзеры выходят в Интернет. И что закрыть пользователю доступ скажем к локалке или к Интернет биллинг заливает новые ACL на кошку с определенной периодичностью. А если сетка большая и есть ядро в лице кошки 6509, то чтобы пропустить через кошку больше кол-во VLAN и стерминировать их на 6509 применяют Qinq, всё верно ?

 

Share this post


Link to post
Share on other sites

Qinq просто так на лан картах не стерминируешь.

Share this post


Link to post
Share on other sites
Qinq просто так на лан картах не стерминируешь.
D-link 3028 поддерживает ведь Qinq разве нет?

 

 

Share this post


Link to post
Share on other sites
Qinq просто так на лан картах не стерминируешь.
D-link 3028 поддерживает ведь Qinq разве нет?

Полноценный QinQ поддерживает только 3528. А в 3028 кастрированный - без "пропуска" BPDUшек.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this