Lanc1

Здесь подробно описан механизм резервирования для IPoE клиентов. Балансировать на уровне подписчиков - это вряд ли, но на определить master-a для тех или иных груповых интерфейсов - без проблем. Спасибо, посмотрел. Увы, чуда не случилось. у киски/джунипера есть аналогичные схемы для IPoE абонентов, приходящих по L2. Для IPoE абонентов, приходящих на BRAS по L3 у всех только костыли (ограничение технологии, тут уж. ничего не попишешь).

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

+1 Ни у cisco, ни у juniper я схемы динамического выделения адресов для схем с dhcp-option 82 не видел. Но тут JoeDoe говорит, что у Alcatel-Lucent уже все работает на базе SAP? На сайте Alcatel-Lucent , к сожалению, документация очень скромная и подробностей мне найти не удалось.

Дело не в "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.

Что вобщем-то равносильно фразе отключена аппаратно :)

Не будет на asr1000 работать pptp. Ни в какой версии софта. Официально pptp asr-ом не поддерживается. Насчет функционала BRAS (L2TP и прочее) функционал софта должен быть не ниже Adv. IP Services.

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