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

Балансировка PPPoE BRAS

Здравствуйте.

 

Планируем к установке PPPoE BRAS в локалке. Есть возможность установить несколько для надежности.

Вопрос: как предсказуемо балансировать нагрузку? Понятно, что клиент в случае если он получит несколько

PADO, то выберет тот, который пришел первым. Но тогда получается только резервирование, балансировка

постольку-поскольку. Если выдавать клиентам разные ServiceName, получится некое подобие балансировки,

но снижется надежность. У кого какие будут мысли? Заранее спасибо за ответы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Понятно, что клиент в случае если он получит несколько

PADO, то выберет тот, который пришел первым. Но тогда получается только резервирование, балансировка

постольку-поскольку.

Как показывает практика, клиенты в этом случае раскидываются между брасами поровну, так что и балансировка тоже будет.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если БРАСы идентичны, то балансировка будет практически поровну...

Конечно, статистически, при больших временных интервалах и большом количестве клиентов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ок, с этим разобрались. Т.е. ставим 2 BRAS - получаем систему, где абоненты равномерно распределяются по железкам. Все хорошо.

Вопрос следующий: если абоненту по PPPoE выдается статический серый\реальный адрес? В варианте где статической\динамической

маршрутизацией каждый BRAS "держит" определенную подсеть, если абонент благодаря резервированию окажется на чужой железке,

то работать он не сможет. Читал в соседней ветке про вариант анонсить \32 абонентские маршруты с BRASов на центральный роутер.

Каким IGP это лучше делать? Не станет ли плохо центральному роутеру, который все это примет от нескольких тысяч \32 маршутов?

Тут писали что на OSPF это очень все мрачно выглядит? Может RIPv2? Или все таки OSPF с какими-то специфическими настройками (ASBR и т.п.)?

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ок, с этим разобрались. Т.е. ставим 2 BRAS - получаем систему, где абоненты равномерно распределяются по железкам. Все хорошо.

Вопрос следующий: если абоненту по PPPoE выдается статический серый\реальный адрес? В варианте где статической\динамической

маршрутизацией каждый BRAS "держит" определенную подсеть, если абонент благодаря резервированию окажется на чужой железке,

то работать он не сможет. Читал в соседней ветке про вариант анонсить \32 абонентские маршруты с BRASов на центральный роутер.

Каким IGP это лучше делать? Не станет ли плохо центральному роутеру, который все это примет от нескольких тысяч \32 маршутов?

Тут писали что на OSPF это очень все мрачно выглядит? Может RIPv2? Или все таки OSPF с какими-то специфическими настройками (ASBR и т.п.)?

зависит от количества /32 сетей. тыщи 2-3 ospf вытянит (на нормальной железке), если больше - ibgp

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Здравствуйте.

BRAS'ы какого вендора ?

1) Простой способ балансировки по ресурсам/текущей загруженности роутера.

Оба BRAS'а слушают PADI от клиентов в одном сегменте(ах).

Кто менее загружен, шустрее (CPU Mhz/Ghz) - тот быстрее отвечает PADO.

Если Cisco, то

2) Cisco specific, Controlled redundancy/static balancing

PPPoE Smart Server Selection

http://www.cisco.com/en/US/docs/ios/bbdsl/..._pppoe_sss.html

12.2(33)SB, 10K

12.2(33)SRC, 73/72

 

P.S. По поводу /32 - iBGP. Хотя, с 2K префиксов - что больше нравится/лучше умеется и работает стабильно в конкретном environment, отвечая требованиям.

Изменено пользователем devs

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Здравствуйте.

BRAS'ы какого вендора ?

1) Простой способ балансировки по ресурсам/текущей загруженности роутера.

Оба BRAS'а слушают PADI от клиентов в одном сегменте(ах).

Кто менее загружен, шустрее (CPU Mhz/Ghz) - тот быстрее отвечает PADO.

 

P.S. По поводу /32 - iBGP. Хотя, с 2K префиксов - что больше нравится/лучше умеется и работает стабильно в конкретном environment, отвечая требованиям.

BRASы AlliedTelesyn AT-AR770S. Конечно это не совсем прям BRAS, но мы его сейчас так используем.

В соседней ветке немного подробнее описано что и как: http://forum.nag.ru/forum/index.php?showtopic=45642

Пока что на каждом из них физически абоненты закреплены, просто думаю-планирую как сделать свободную

регистрацию, чтобы привязки не было + получить с помощью этого еще и резервирование.

BGP-4 на этих железках опционально, скорее всего за доп. денюжку. Насколько хорошо железки с ним работают - непонятно.

Так что буду пробовать то, что гарантировано менее ресурсоёмко, скорее всего RIPv2.

Изменено пользователем Sergey_Taurus

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Можно попробовать средствами биллинга выдавать адрес из диапазона в зависимости от ID BRAS'а. Если, конечно, биллинг это умеет. =)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тут в подобной теме (в разделе программное обеспечение) Ivan Rostovikov посоветовал не iBGP а RIP - нагрузка на канал побольше, зато на проц - поменьше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Можно попробовать средствами биллинга выдавать адрес из диапазона в зависимости от ID BRAS'а. Если, конечно, биллинг это умеет. =)

Ключевая фраза: "абоненту по PPPoE выдается статический серый\реальный адрес". Выдавать что-то в какой-либо зависимости от чего-то не подходит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тут в подобной теме (в разделе программное обеспечение) Ivan Rostovikov посоветовал не iBGP а RIP - нагрузка на канал побольше, зато на проц - поменьше.

ну раз советует... только что rip что ospf - у них предел по префиксам есть. Где-то 5-7 тысяч (у рипа кстати он меньше) - но требует уже не слабых железок. Как и было выше сказано если у вас 2-3 тысячи префиксов: что хотите - то и используете, если больше - не ставьте грабли себе под ноги. наступите - ударит больно.

Изменено пользователем Konstantin Klimchev

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не, RIP на цисках как раз жрёт процессор сильно больше OSPF. Да и баги такие время от времени вылазят, как будто его и не тестят...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.