Две или более систем с переключением при отказе и балансировкой нагрузки.

Вот тут быстро отвечаю: когда PPPoE-сервер №1 достигает 300 клиентов, сомневаюсь, что есть надёжный способ заставить PPPoE-сервер №2 начать обслуживать остальных. Можно, наверное, сделать это с помощью каких-нибудь скриптов, но это будет довольно грязный хак.

А теперь длинный ответ: Мы заметили, что после 200+ PPPoE пользователей, MT иногда становится нестабильным. PPPoE-серверы прекрасно работают параллельно (у нас даже бывает 6 работающих одновременно), и как правило, они сами по себе выстраивают балансировку нагрузки. Помните, PPPoE – это уровень 2, и по соображениям безопасности не стоит присваивать IP-адрес интерфейсу PPPoE-сервера. Для избыточности просто запустите их все на одном VLAN или уровне 2. Первый PPPoE-сервер, который ответит на запрос входа CPE PPPoE, получит работу на время этой сессии, при условии, что имя сервиса, установленное в CPE, пустое. Если этот PPPoE-сервер (концентратор) умирает, клиенты, подключённые к этому PPPoE-серверу, автоматически начнут искать другой сервер для входа, и следующий, кто первым ответит, получит работу… немного в стороне от темы, но полезная информация. Если у вас приличные CPE, вышеуказанный процесс происходит очень быстро, то есть за 1-2 секунды. Cisco, M0n0wall и многие Linksys CPE справляются хорошо. (Не поверите, но наши тесты доказали, что все версии MT имеют худшего PPPoE-клиента из всех виденных. Он НИКОГДА не войдет автоматически, если его не перезагрузить или сторожевой таймер не заставит его перезагрузиться… M0n0wall имеет самый надёжный/быстрый PPPoE-клиент, который когда-либо видели. Не заморачивайтесь, если ваши CPE состоят в основном из MT! Из 6 MT-боксов, работающих PPPoE-сервером параллельно, в 9 случаях из 10 мы видим одинаковое количество клиентов, подключенных к каждому из них. Подсказка: не забудьте запустить динамический протокол маршрутизации выше ваших «параллельных» PPPoE-серверов или прокси-ARP, если вам лень.