Lanc1
-
Публикации
8 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем Lanc1
-
-
Может быть плохо искали? Если мне не изменяет пямять, то адреса ввыделяются динамически с пула дхцп сервера, запущеного на том же ISG или ERX.Ни у cisco, ни у juniper я схемы динамического выделения адресов для схем с dhcp-option 82 не видел.Да, динамически, но немного не о том речь.
А о том, что в большинстве реализаций с dhcp. opt82. На одного абонента (неважно активен он сейчас или нет) выдается 1 паблик ip (или если приватный, то nat и все дела...).
А в случае с pppoe, напр. можно держать пул ip адресов публичный = по размеру активных абонентов в часы макс. нагрузки (а это меньше чем 1 абонент=1 публичный ip).
Схема с ISG хорошо должна работать, когда ISG является dhcp relay или локальным dhcp сервером. А если такой возможности нет, то и приходим к схеме 1 ip на 1-го dhcp абонента.
Чтобы делать ISG (или ERX) dhcp релеем, то получается, либо bras-ы нужно расставлять локально по узлам (очень дорого), либо стягивать по L2 абонентов к централизованным bras
и гонять локальный трафик через них. Я верю, такие схемы есть рабочие очевидно, но только у тех операторов, у которых очень много денег :)
Когда допилят dhcp, конечно все кто сейчас на PPPoE сидят постепенно на IPoE мигрируют (имеется в виду исключительно сервис доступа в инет). А пока не собираются.
-
Опубликовано · Изменено пользователем Lanc1 · Жалоба на ответ
Для IPoE (+opt.82) надо на каждого пользователя выделить статический IP (т.е. строго определенный ИП, который будет выдаваться по DHCP), соответственно, в случае "белых" адресов надо 1 белый адрес на 1 абонента. PPPoE в этом плане выглядит симпотичнее (:Есть варианты обохода? Вроде как есть решения связанные со связкой radius+dhcp?
+1
Ни у cisco, ни у juniper я схемы динамического выделения адресов для схем с dhcp-option 82 не видел.
Но тут JoeDoe говорит, что у Alcatel-Lucent уже все работает на базе SAP?
На сайте Alcatel-Lucent , к сожалению, документация очень скромная и подробностей мне найти не удалось.
-
Опубликовано · Изменено пользователем Lanc1 · Жалоба на ответ
Если у Cisco нет такого - не надо говорить что такого нет вообще. ALU 7710/7450/7750 синхронизирует подписчиков между двумя рутерами, как для IPoE так и для PPPoE, с текущим статусом, QoS профилями каждого и т.п. Свитчи или DSLAMы могут подключаться как через 2 uplinka, так и через кольцо к обеим рутерам. Кстати, в начале 2010 будет и L2-aware NAT, который позволит решить две задачи - мягкую миграцию на IPv6 и проблемы с масштабированием NAT-a на рутерах провайдера.Дело не в "Cisco" или "не Cisco", а в ограничениях технологии, которая повторюсь не предполагает схем с резервированием/балансировкой трафика между несколькими bras. То что какой-то вендор накрутил своих фич/костылей еще не значит, что технология рулит сама по себе. Напр. для того же Cisco я разрабатывал схемы с балансировкой/резервированием между двумя или более bras, и оно работает, но опять же повторюсь, это костыли + это непростая схема с ограничениями.
Для PPPoE подобные синхронизации может и необходимы, но существенный плюс самой технологии в этом плане, что если есть 2 BRAS с подключением абонентов, то при установлении сессии, кто из брасов первым ответил на клиентский PADI, с тем сессия и устанавливается, а поскольку более нагруженный брас будет отвечать с большей задержкой, то нагрузка будет более-менее равномерно распределяться между ними. Если же BRAS хлопается, то по idle-timeout абонент пытаеся переустановить сессию и подключается к оставшемуся BRAS. Все, технология проста до безобразия.
И каким же образом эта синхронизация на ALU работает для DHCP(IPoE) абонентов, так что позволяет производить резервирование хотя бы, не говорю пока про балансировку?
-
Идеальной технологии, увы нет. везде нужно искать компромиссы. PPTP, понятно - умер почти.
С IPoE тоже не все так гладко, т. к. отсутствуют механизмы резервирования встроенные, если два или больше брасов и один из них грохается (обещали сделать такую поддержку в след. версии DHCP, но пока нет).
+ с IPoE проблема как уже сказали с NAT (если блок большой публичных адресов не отхватите).
У PPPoE проблема с тем, что L2 нужно пробрасывать до BRAS. Если есть IP/MPLS ядро с ES платами на 7600, то проблем с этим быть не должно (функционал routed pseudowire)).
С PPTP в моем разумении проще всего мигрировать на L2TP, так как тоже используется туннелирование поверх IP сети в режиме, когда клиенты выполняют роль LAC, а BRAS - LNS.
-
она не отключена, тупо не припаяна микросхема :)
Что вобщем-то равносильно фразе отключена аппаратно :)
-
А в ответ тишина :(
У меня даже L2TP не поднимается. Видимо рейт-лимиты на ин и оут не нравятся.
Не будет на asr1000 работать pptp. Ни в какой версии софта. Официально pptp asr-ом не поддерживается.
Насчет функционала BRAS (L2TP и прочее) функционал софта должен быть не ниже Adv. IP Services.
-
Неверно. Crypto фича для ESP 10-N отключена аппаратно. То есть проапдейтить его до Crypto не получится.зачем искать?! по ASR обращайтесьи если я не ошибась там Crypto - это софтовая фича
ESP10-N говорят пока в России нет. Будем искать.Через любого цискиного золотого партнера или дистрибутора - доставка ~2 мес.
25k pptp sess / 1Mpps
в Активное оборудование Ethernet, IP, MPLS, SDN/NFV...
Опубликовано · Жалоба на ответ
Спасибо, посмотрел. Увы, чуда не случилось. у киски/джунипера есть аналогичные схемы для IPoE абонентов, приходящих по L2.
Для IPoE абонентов, приходящих на BRAS по L3 у всех только костыли (ограничение технологии, тут уж. ничего не попишешь).