mlevel Опубликовано: December 1, 2011 at 18:32 Опубликовано: December 1, 2011 at 18:32 Хто реально використовує? Хочеться відійти від IP-MAC binding. Технлогія в загальному дуже цікава, і але єдине "але" - потрібно мати чітку прив`язку абонента до порта. Хто працює по такій схемі, поділіться будь - ласка досвідом.
Зоррик Опубликовано: October 4, 2012 at 12:20 Опубликовано: October 4, 2012 at 12:20 Тоже инетересно.
Melanxolik Опубликовано: October 4, 2012 at 14:00 Опубликовано: October 4, 2012 at 14:00 ну так все зависит какое железо на конце у вас стоит, везде свои плюсы и минусы. подумайте где у вас option82 реализуется. и на чем брасы у вас, где соберетесь агрегировать пачку vlan
Зоррик Опубликовано: October 5, 2012 at 13:37 Опубликовано: October 5, 2012 at 13:37 На доступе железо управляемое, но зоопарк. Агрегация Л3, там зоопарк поменьше (циски нортелы). Л3 собираются в кучу через Л2 свич, в который также включеные биллиг, бордер, насы, аплинки. Щас все бегает по пптп. Хотелось бы перейти на IPoE. Доступ опцию 82 не умеет.
Melanxolik Опубликовано: October 5, 2012 at 20:03 Опубликовано: October 5, 2012 at 20:03 тогда придется на доступе городить vlanы, что тоже в приципе не проблема. в обще советую сперва стендик собрать и обкатать ip unnumbered, потом уже потихоньку сдвигать это в сторону чтобы разобрать сам процесс. а дальше можно и isg попробовать.
Зоррик Опубликовано: October 5, 2012 at 20:07 Опубликовано: October 5, 2012 at 20:07 Ip unnumbered не совсем интересно, так так реальники заканчиваются а новых взять негде . Планирую перходить на нат. А там особой экономии не нужно. Есть идея прокинуть вланы до Л3 а там уже опция 82, или просто скриптом дхцп конфиг генерить по /30. Хотелось бы увидить методы автоматизации управления /30 на юзера. А то как то руками все настраивать не впичетляет.
mlevel Опубликовано: October 5, 2012 at 21:07 Автор Опубликовано: October 5, 2012 at 21:07 При великій кількості клієнтів потрібна підтримка Q-in-Q на обладнанні ядра/агрегації.
KaYot Опубликовано: October 5, 2012 at 21:16 Опубликовано: October 5, 2012 at 21:16 С NATом? Не смешите мои яйца.
Melanxolik Опубликовано: October 6, 2012 at 10:43 Опубликовано: October 6, 2012 at 10:43 ну если unnumbered не интересно... то сказать не чего. вот только не понятно, а что мешает сделать такую схему: клиенту по умолчанию подключается серый ip, при желании он может подключить в личном кабинете внешний ip на порт, дальше можно выдавать внешники или из динамики или если ему надо статика то прописывается отдельной статьей расходов, как бы логика простая, реализовать тоже вполне возможно... ну а дальше не прошла оплата за статику бросаем или в динамику с передергиванием порта в час ночи, или в серый. А чтобы внешники экономились, можно просто подключать внешние динамикой как услугу бесплатно сроком на 1месяц...
Зоррик Опубликовано: October 7, 2012 at 06:44 Опубликовано: October 7, 2012 at 06:44 У Вас такое реализовано?
Melanxolik Опубликовано: October 7, 2012 at 13:43 Опубликовано: October 7, 2012 at 13:43 Начинали реализацию, но у нас utm, далеко не уедешь, ну есть еще факторы, так что только на 50 процентов работа была выполнена. Внешку давали при первом обращении пользователя. В остальном не вижу причин почему нельзя реализовать.
ntil Опубликовано: October 8, 2012 at 05:48 Опубликовано: October 8, 2012 at 05:48 использую 65й каталист со вторым супом для агрегации линков с домов + терминация вланов (макс 2к вланов), уже пару лет. дешево и сердито. если нужно больше - тогда 720й суп и мона нагородить более 50 к вланов (не Q-in-Q), правда схемка весьма специфичная получается и есть требования к топологии сети - не более 4к вланов в одном физическом сегменте.
Зоррик Опубликовано: October 8, 2012 at 12:19 Опубликовано: October 8, 2012 at 12:19 ip unnumbered или /30? Роуты на циске биллинг поднимает или вручную?
ntil Опубликовано: October 8, 2012 at 16:01 Опубликовано: October 8, 2012 at 16:01 /29 для серых конфигурация скриптом (единоразово), с импортом БД вланов из биллинга. роуты естественно localconnected и не конфигурятся биллинг самописный PI у нас тока /24 поэтому в аннамберед нет необходимости , но как минимум у 720 го супа проблем быть не должно (на втором просто не пробовал) думаю апгрейдится со временем на 720й с прицелом на v6, а там точно аннаберед ни к селу ни к городу.
KaYot Опубликовано: October 8, 2012 at 16:28 Опубликовано: October 8, 2012 at 16:28 использую 65й каталист со вторым супом для агрегации линков с домов + терминация вланов (макс 2к вланов), уже пару лет. дешево и сердито. если нужно больше - тогда 720й суп и мона нагородить более 50 к вланов (не Q-in-Q), правда схемка весьма специфичная получается и есть требования к топологии сети - не более 4к вланов в одном физическом сегменте. 50k вланов на sup720 это фантастика. Всего 4к, столько же как и на вашем sup2 или 4ех 3550-24..
ntil Опубликовано: October 8, 2012 at 16:41 Опубликовано: October 8, 2012 at 16:41 нет. вся фича в том, что физический интерфейс работает не в switchport mode а как лз. на нем городятся субинтерфейсы с 801.q тегами итого ограничение в 4к вланов на физический порт. а портов у нас много (например с десяток карт по 48 СФП). лишь-бы ТКАМов на все про все хватило. у 720го их много больше чем у суп2. на наге есть обширная статья как такое организовать.
KaYot Опубликовано: October 8, 2012 at 17:25 Опубликовано: October 8, 2012 at 17:25 нет. вся фича в том, что физический интерфейс работает не в switchport mode а как лз. на нем городятся субинтерфейсы с 801.q тегами итого ограничение в 4к вланов на физический порт. а портов у нас много (например с десяток карт по 48 СФП). лишь-бы ТКАМов на все про все хватило. у 720го их много больше чем у суп2. на наге есть обширная статья как такое организовать. Ткни пальцем если не сложно, где говорится о возможности стериминировать >4k вланов на 6500+sup720. Там же тупо ограничение в 4к саб-интерфейсов, а на q-in-q он терминировать не умеет. Где-то в соседней теме находили решение(то ли 32к, то ли 64к), sup720+ES карты, ну да стоимость такого решения получается космической.
ntil Опубликовано: October 8, 2012 at 18:58 Опубликовано: October 8, 2012 at 18:58 в итоге не совсем верно я описал. (точнее совсем не верно). но всетаки можно больше 4к (самих интерфейсов правда при этом 4к) и тоже не более 4 к вланов на порт. http://forum.nag.ru/forum/index.php?showtopic=45488 вот собсно суть.
KaYot Опубликовано: October 8, 2012 at 19:08 Опубликовано: October 8, 2012 at 19:08 Дык это уже не vlan per user, а vlan per как получится
ntil Опубликовано: October 8, 2012 at 19:16 Опубликовано: October 8, 2012 at 19:16 функционально эквивалентно. т.е. для доступа это именно что влан-на-рыло
127.0.0.1 Опубликовано: June 11, 2013 at 23:44 Опубликовано: June 11, 2013 at 23:44 Хотелось бы поднять тему. Сейчас используем ip unnumbered и vlan на дом. Думаем перестроить все vlan на абонента. Но тут возникает вопрос как правильно\эффективно обслуживать сеть. Например есть дом в котором есть 24 клиента и нам нужно заменить коммутатор на другой. Как я понял нужно пометить все кабеля которые приходят на тп иначе не сможем определить в какой порт включать клиента. Кто и как решает данный вопрос ?
loki Опубликовано: June 12, 2013 at 02:06 Опубликовано: June 12, 2013 at 02:06 бирки с номерами квартир на кабель и централизация админки коммутаторов?
Melanxolik Опубликовано: June 12, 2013 at 05:08 Опубликовано: June 12, 2013 at 05:08 В таких схемах лучше свичи доступа включать в свичи района и паковать в qinq, дальше уже распаковывать в центре, тогда у вас будет единная топология, и все свичи доступа будут содержать одни и теже vlan, что значительно облегчит их замену.
ntil Опубликовано: June 12, 2013 at 05:40 Опубликовано: June 12, 2013 at 05:40 Хотелось бы поднять тему. Сейчас используем ip unnumbered и vlan на дом. Думаем перестроить все vlan на абонента. Но тут возникает вопрос как правильно\эффективно обслуживать сеть. Например есть дом в котором есть 24 клиента и нам нужно заменить коммутатор на другой. Как я понял нужно пометить все кабеля которые приходят на тп иначе не сможем определить в какой порт включать клиента. Кто и как решает данный вопрос ? хотел уточнить, сколько абонов в сети? от этого зависит исполнение узла агрегации. у меня свитчи админятся централизовано (плюс учет свободных\занятых\битых портов), сейчас еще с биллингом интеграцию делаю - единая система лучше чем две раздельных. вланы индивидуальны, по 2к вланов на ветку. агрегация 6500. на средней-крупной сети подход q-in-q - влан на коммутатор, а в нем инкапсулированы влан на юзера будет скорее всего уже обусловлен не удобством а необходимостью. при этом подходе все-таки будет тот-же геммор с админингом свитчей, хотя возможно менее проблемный чем вланы россыпью. есть еще вариант - выделенный физический порт на агрегации на дом (выделенная лямбда или волокно) - тогда все свитчи настроены одинаково в плане вланов (хотя скорее всего будет несколько вариантов настройки - перывй, второй, третий, и т.п. свитч на дом) плясать все-таки необходимо от агрегации, если она уже в наличии. не выкидывать ведь 6500 если он не умеет q-in-q по человечески (эт отдельная песня). но, однако автоматизация настройки коммутаторов нивелирует недостатки 1го и 2го подхода (а на средней сети уже при любом подходе это необходимо)
127.0.0.1 Опубликовано: June 13, 2013 at 22:33 Опубликовано: June 13, 2013 at 22:33 Хотелось бы поднять тему. Сейчас используем ip unnumbered и vlan на дом. Думаем перестроить все vlan на абонента. Но тут возникает вопрос как правильно\эффективно обслуживать сеть. Например есть дом в котором есть 24 клиента и нам нужно заменить коммутатор на другой. Как я понял нужно пометить все кабеля которые приходят на тп иначе не сможем определить в какой порт включать клиента. Кто и как решает данный вопрос ? хотел уточнить, сколько абонов в сети? от этого зависит исполнение узла агрегации. у меня свитчи админятся централизовано (плюс учет свободных\занятых\битых портов), сейчас еще с биллингом интеграцию делаю - единая система лучше чем две раздельных. вланы индивидуальны, по 2к вланов на ветку. агрегация 6500. на средней-крупной сети подход q-in-q - влан на коммутатор, а в нем инкапсулированы влан на юзера будет скорее всего уже обусловлен не удобством а необходимостью. при этом подходе все-таки будет тот-же геммор с админингом свитчей, хотя возможно менее проблемный чем вланы россыпью. есть еще вариант - выделенный физический порт на агрегации на дом (выделенная лямбда или волокно) - тогда все свитчи настроены одинаково в плане вланов (хотя скорее всего будет несколько вариантов настройки - перывй, второй, третий, и т.п. свитч на дом) плясать все-таки необходимо от агрегации, если она уже в наличии. не выкидывать ведь 6500 если он не умеет q-in-q по человечески (эт отдельная песня). но, однако автоматизация настройки коммутаторов нивелирует недостатки 1го и 2го подхода (а на средней сети уже при любом подходе это необходимо) Сеть небольшая, до 1000. Сейчас думаем к какому варианту лучше склонится.
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВойти
Уже зарегистрированы? Войдите здесь.
Войти сейчас