VLAN per user

[mlevel]

Хто реально використовує? Хочеться відійти від IP-MAC binding.

Технлогія в загальному дуже цікава, і але єдине "але" - потрібно мати чітку прив`язку абонента до порта.

Хто працює по такій схемі, поділіться будь - ласка досвідом.

[Зоррик]

Тоже инетересно.

[Melanxolik]

ну так все зависит какое железо на конце у вас стоит, везде свои плюсы и минусы.

подумайте где у вас option82 реализуется.

и на чем брасы у вас, где соберетесь агрегировать пачку vlan

[Зоррик]

На доступе железо управляемое, но зоопарк. Агрегация Л3, там зоопарк поменьше (циски нортелы). Л3 собираются в кучу через Л2 свич, в который также включеные биллиг, бордер, насы, аплинки. Щас все бегает по пптп. Хотелось бы перейти на IPoE. Доступ опцию 82 не умеет.

[Melanxolik]

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

в обще советую сперва стендик собрать и обкатать ip unnumbered, потом уже потихоньку сдвигать это в сторону чтобы разобрать сам процесс.

а дальше можно и isg попробовать.

[Зоррик]

Ip unnumbered не совсем интересно, так так реальники заканчиваются а новых взять негде . Планирую перходить на нат. А там особой экономии не нужно. Есть идея прокинуть вланы до Л3 а там уже опция 82, или просто скриптом дхцп конфиг генерить по /30. Хотелось бы увидить методы автоматизации управления /30 на юзера. А то как то руками все настраивать не впичетляет.

[mlevel]

При великій кількості клієнтів потрібна підтримка Q-in-Q на обладнанні ядра/агрегації.

[KaYot]

С NATом? Не смешите мои яйца.

[Melanxolik]

ну если unnumbered не интересно... то сказать не чего.

вот только не понятно, а что мешает сделать такую схему:

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

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

[Зоррик]

У Вас такое реализовано?

[Melanxolik]

Начинали реализацию, но у нас utm, далеко не уедешь, ну есть еще факторы, так что только на 50 процентов работа была выполнена.

Внешку давали при первом обращении пользователя.

В остальном не вижу причин почему нельзя реализовать.

[ntil]

использую 65й каталист со вторым супом для агрегации линков с домов + терминация вланов (макс 2к вланов), уже пару лет. дешево и сердито.

если нужно больше - тогда 720й суп и мона нагородить более 50 к вланов (не Q-in-Q), правда схемка весьма специфичная получается и есть требования к топологии сети - не более 4к вланов в одном физическом сегменте.

[Зоррик]

ip unnumbered или /30? Роуты на циске биллинг поднимает или вручную?

[ntil]

/29 для серых

конфигурация скриптом (единоразово), с импортом БД вланов из биллинга. роуты естественно localconnected и не конфигурятся

 

биллинг самописный

 

PI у нас тока /24 поэтому в аннамберед нет необходимости , но как минимум у 720 го супа проблем быть не должно (на втором просто не пробовал)

 

думаю апгрейдится со временем на 720й с прицелом на v6, а там точно аннаберед ни к селу ни к городу.

[KaYot]

использую 65й каталист со вторым супом для агрегации линков с домов + терминация вланов (макс 2к вланов), уже пару лет. дешево и сердито.

если нужно больше - тогда 720й суп и мона нагородить более 50 к вланов (не Q-in-Q), правда схемка весьма специфичная получается и есть требования к топологии сети - не более 4к вланов в одном физическом сегменте.

50k вланов на sup720 это фантастика. Всего 4к, столько же как и на вашем sup2 или 4ех 3550-24..

[ntil]

нет.

вся фича в том, что физический интерфейс работает не в switchport mode а как лз. на нем городятся субинтерфейсы с 801.q тегами

итого ограничение в 4к вланов на физический порт. а портов у нас много (например с десяток карт по 48 СФП). лишь-бы ТКАМов на все про все хватило. у 720го их много больше чем у суп2.

 

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

[KaYot]

нет.

вся фича в том, что физический интерфейс работает не в switchport mode а как лз. на нем городятся субинтерфейсы с 801.q тегами

итого ограничение в 4к вланов на физический порт. а портов у нас много (например с десяток карт по 48 СФП). лишь-бы ТКАМов на все про все хватило. у 720го их много больше чем у суп2.

 

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

Ткни пальцем если не сложно, где говорится о возможности стериминировать >4k вланов на 6500+sup720.

Там же тупо ограничение в 4к саб-интерфейсов, а на q-in-q он терминировать не умеет. Где-то в соседней теме находили решение(то ли 32к, то ли 64к), sup720+ES карты, ну да стоимость такого решения получается космической.

[ntil]

в итоге не совсем верно я описал. (точнее совсем не верно). но всетаки можно больше 4к (самих интерфейсов правда при этом 4к) и тоже не более 4 к вланов на порт.

 

http://forum.nag.ru/forum/index.php?showtopic=45488

вот собсно суть.

[KaYot]

Дык это уже не vlan per user, а vlan per как получится

[ntil]

функционально эквивалентно.

т.е. для доступа это именно что влан-на-рыло

[127.0.0.1]

Хотелось бы поднять тему. Сейчас используем ip unnumbered и vlan на дом. Думаем перестроить все vlan на абонента. Но тут возникает вопрос как правильно\эффективно обслуживать сеть.  Например есть дом в котором есть 24 клиента и нам нужно заменить коммутатор на другой. Как я понял нужно пометить все кабеля которые приходят на тп иначе не сможем определить в какой порт включать клиента.

Кто и как решает данный вопрос ?

[loki]

бирки с номерами квартир на кабель и централизация админки коммутаторов?

[Melanxolik]

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

[ntil]

 

Хотелось бы поднять тему. Сейчас используем ip unnumbered и vlan на дом. Думаем перестроить все vlan на абонента. Но тут возникает вопрос как правильно\эффективно обслуживать сеть.  Например есть дом в котором есть 24 клиента и нам нужно заменить коммутатор на другой. Как я понял нужно пометить все кабеля которые приходят на тп иначе не сможем определить в какой порт включать клиента.

Кто и как решает данный вопрос ?

хотел уточнить, сколько абонов в сети? от этого зависит исполнение узла агрегации.

 

у меня свитчи админятся централизовано (плюс учет свободных\занятых\битых портов), сейчас еще с биллингом интеграцию делаю - единая система лучше чем две раздельных. вланы индивидуальны, по 2к вланов на ветку. агрегация 6500.

 

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

 

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

 

плясать все-таки необходимо от агрегации, если она уже в наличии. не выкидывать ведь 6500 если он не умеет q-in-q по человечески (эт отдельная песня).

 

но, однако автоматизация настройки коммутаторов нивелирует недостатки 1го и 2го подхода (а на средней сети уже при любом подходе это необходимо)

[127.0.0.1]

 

 

Хотелось бы поднять тему. Сейчас используем ip unnumbered и vlan на дом. Думаем перестроить все vlan на абонента. Но тут возникает вопрос как правильно\эффективно обслуживать сеть.  Например есть дом в котором есть 24 клиента и нам нужно заменить коммутатор на другой. Как я понял нужно пометить все кабеля которые приходят на тп иначе не сможем определить в какой порт включать клиента.

Кто и как решает данный вопрос ?

хотел уточнить, сколько абонов в сети? от этого зависит исполнение узла агрегации.

 

у меня свитчи админятся централизовано (плюс учет свободных\занятых\битых портов), сейчас еще с биллингом интеграцию делаю - единая система лучше чем две раздельных. вланы индивидуальны, по 2к вланов на ветку. агрегация 6500.

 

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

 

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

 

плясать все-таки необходимо от агрегации, если она уже в наличии. не выкидывать ведь 6500 если он не умеет q-in-q по человечески (эт отдельная песня).

 

но, однако автоматизация настройки коммутаторов нивелирует недостатки 1го и 2го подхода (а на средней сети уже при любом подходе это необходимо)

Сеть небольшая, до 1000.  Сейчас думаем к какому варианту лучше склонится.