Перейти к содержимому
Калькуляторы

Lanc1

Пользователи
 Просмотреть профиль  Активность

  • Публикации

    8

  • Зарегистрирован

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем Lanc1

  1. Опубликовано · Жалоба на ответ

    И каким же образом эта синхронизация на ALU работает для DHCP(IPoE) абонентов, так что позволяет производить резервирование хотя бы, не говорю пока про балансировку?
    Здесь подробно описан механизм резервирования для IPoE клиентов. Балансировать на уровне подписчиков - это вряд ли, но на определить master-a для тех или иных груповых интерфейсов - без проблем.

    Спасибо, посмотрел. Увы, чуда не случилось. у киски/джунипера есть аналогичные схемы для IPoE абонентов, приходящих по L2.

    Для IPoE абонентов, приходящих на BRAS по L3 у всех только костыли (ограничение технологии, тут уж. ничего не попишешь).

  2. Опубликовано · Жалоба на ответ

    Ни у cisco, ни у juniper я схемы динамического выделения адресов для схем с dhcp-option 82 не видел.
    Может быть плохо искали? Если мне не изменяет пямять, то адреса ввыделяются динамически с пула дхцп сервера, запущеного на том же ISG или ERX.

    Да, динамически, но немного не о том речь.

    А о том, что в большинстве реализаций с 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 мигрируют (имеется в виду исключительно сервис доступа в инет). А пока не собираются.

  3. Опубликовано · Изменено пользователем Lanc1 · Жалоба на ответ

    Для IPoE (+opt.82) надо на каждого пользователя выделить статический IP (т.е. строго определенный ИП, который будет выдаваться по DHCP), соответственно, в случае "белых" адресов надо 1 белый адрес на 1 абонента. PPPoE в этом плане выглядит симпотичнее (:

    Есть варианты обохода? Вроде как есть решения связанные со связкой radius+dhcp?

    +1

     

    Ни у cisco, ни у juniper я схемы динамического выделения адресов для схем с dhcp-option 82 не видел.

    Но тут JoeDoe говорит, что у Alcatel-Lucent уже все работает на базе SAP?

     

    На сайте Alcatel-Lucent , к сожалению, документация очень скромная и подробностей мне найти не удалось.

  4. Опубликовано · Изменено пользователем 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) абонентов, так что позволяет производить резервирование хотя бы, не говорю пока про балансировку?

  5. Опубликовано · Жалоба на ответ

    Идеальной технологии, увы нет. везде нужно искать компромиссы. PPTP, понятно - умер почти.

    С IPoE тоже не все так гладко, т. к. отсутствуют механизмы резервирования встроенные, если два или больше брасов и один из них грохается (обещали сделать такую поддержку в след. версии DHCP, но пока нет).

    + с IPoE проблема как уже сказали с NAT (если блок большой публичных адресов не отхватите).

    У PPPoE проблема с тем, что L2 нужно пробрасывать до BRAS. Если есть IP/MPLS ядро с ES платами на 7600, то проблем с этим быть не должно (функционал routed pseudowire)).

    С PPTP в моем разумении проще всего мигрировать на L2TP, так как тоже используется туннелирование поверх IP сети в режиме, когда клиенты выполняют роль LAC, а BRAS - LNS.

  7. Опубликовано · Жалоба на ответ

    А в ответ тишина :(

    У меня даже L2TP не поднимается. Видимо рейт-лимиты на ин и оут не нравятся.

    Не будет на asr1000 работать pptp. Ни в какой версии софта. Официально pptp asr-ом не поддерживается.

     

    Насчет функционала BRAS (L2TP и прочее) функционал софта должен быть не ниже Adv. IP Services.

     

  8. Опубликовано · Жалоба на ответ

    зачем искать?! по ASR обращайтесь

    и если я не ошибась там Crypto - это софтовая фича

    Неверно. Crypto фича для ESP 10-N отключена аппаратно. То есть проапдейтить его до Crypto не получится.

     

    ESP10-N говорят пока в России нет. Будем искать.

    Через любого цискиного золотого партнера или дистрибутора - доставка ~2 мес.