[Lut]

[Тут уже сказали, что нужно построить связку IP-mac на этапе dhcp авторизации в той точке сети, которая уже не коммутатор (они пока не умеют от радиуса или dhcp сервера получать атрибуты на шейпинг и разгребать весь этот процесс с очередями и прочим, слабовато железо, но все может быть), но и пакет еще не пересек L3 границу, когда потерян мак адрес.

На данный момент, если отойти от юникса, это умеют делать как минимум три вендора.

Нет у меня никакого МАК уже.

Все клиентские МАКи финишировали на агрегации. Выше - только чистый IP.

[tgz]

tgz, плохо это на самом деле, keepilve сессии отследить не реально.

кстати, а что cisco isg на основе dhcp может работает через L3 сеть и dhcp релеи?

Умеет. Такая схема в документации описана. В живую не пробовал, дедушка оглох, а не а***л цыскины брасы брать.

Keepalive в данном случае осуществляется через малые leased time.

[Cr_net]

Умеет. Такая схема в документации описана. В живую не пробовал, дедушка оглох, а не а***л цыскины брасы брать.

Дед, ты по моему ещё и ослеп :) ну или я, такого описалова не видел нигде, в связке isg-dhcp там везде упоминается L2.

Но пойду попробую, вдруг чудеса случаются и правда работает :)

Keepalive в данном случае осуществляется через малые leased time.

это колено при tcp потоках например ftp-data работает через раз.

[Lanc1]

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

Здесь подробно описан механизм резервирования для IPoE клиентов. Балансировать на уровне подписчиков - это вряд ли, но на определить master-a для тех или иных груповых интерфейсов - без проблем.

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

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

[tgz]

Дед, ты по моему ещё и ослеп :) ну или я, такого описалова не видел нигде, в связке isg-dhcp там везде упоминается L2.

Но пойду попробую, вдруг чудеса случаются и правда работает :)

1. У цыски это называется Routed Access Networks.

2. Массовых пропаданий dhcp пакетов на высокозагруженных линках не наблюдал.

[Stak]

кстати, а что cisco isg на основе dhcp может работает через L3 сеть и dhcp релеи?

релеем для роутед абонентов емнип не может. А вот сервером - это пожалуйста.

[D^2]

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

Здесь подробно описан механизм резервирования для IPoE клиентов. Балансировать на уровне подписчиков - это вряд ли, но на определить master-a для тех или иных груповых интерфейсов - без проблем.

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

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

на КРОС2010 представители Ericsson как раз говорили, что они первые со своим SmartEdge кто решил такую проблему.

SE_NAG_Event_20100524_v01.pdf

[shicoy]

Согласен что SmartEdge интересное решение на рынке BRASов, скоро получим на тест. Статья по результатам как всегда с меня.

[Tosha]

Ну как, получили? Как результаты?

[C@T]

Заранее приношу извинения за то, что занимаюсь раскопками экскементов мамонта древних тем, но все-таки, хочется знать, существует ли в природе железный BRAS(а не софтовое решение), умеющий вот это:

но есть тупая задача которая решается тунельными брасами (l2tp/pppoe)

есть некий пул белых адресов и пул серых адресов, второй естественно больше первого.

так вот при IPoE хотелось бы при успешной аутентификации чтобы создавалась binat(на какой железке - второй вопрос) запись серого ip в белый, т.е. реализовывался тот же пул адресов при l2tp/pppoe(с возможной передачей через аттрибут реального адреса в который делать бинат, чтобы делать статически закреплённые адреса)

в ISG такого нет. где есть?

 

костыли из скриптов не предлагать :)

раздавать через DHCP белые адреса не предлагаь, компов может висеть не прошедших аутентификацию гораздо больше белого пула :)

 

хотя врядли кто-то из "изготовителей BRASов" будет на такое заморачитваться...

[mikevlz]

SmartEdge? Или я не особо понял вопроса. Натит аппаратно, натит хорошо. При аутентификации - совать абонента в класс, который натится, если ему доступ разрешен.

[C@T]

Натит аппаратно, натит хорошо

динамический нат NAT 1-в-1 (как при pptp/ppooe - одному "серому" IP - уникальный "белый" IP), на smartedge такого нет...

[D^2]

динамический нат NAT 1-в-1 (как при pptp/ppooe - одному "серому" IP - уникальный "белый" IP), на smartedge такого нет...

вроде на форуме приводили конфиги, как это настроено и работает

[shicoy]

Натит аппаратно, натит хорошо

динамический нат NAT 1-в-1 (как при pptp/ppooe - одному "серому" IP - уникальный "белый" IP), на smartedge такого нет...

Кстати есть ) в CG-NAT на софте 11.1.x и старше

[C@T]

вроде на форуме приводили конфиги, как это настроено и работает

вроде только статическое приводили, про динамическое в теме про SmartEdge ответили , что работать не будет (http://forum.nag.ru/forum/index.php?showtopic=65559&view=findpost&p=674933)

"Dynamic NAT 1 to 1 (не путать с NAPT) - только для L3 интерфейсов (не для multibind)"

А абоненты pppoe/clips, если я не ошибаюсь, терминируются как раз на multibind

Кстати есть

не статически, а именно динамическое назначение IP работает в новой версии? спасибо за инфу!

Изменено 12 июля, 2012 пользователем C@T

[Negator]

Для PPPoE подобные синхронизации может и необходимы, но существенный плюс самой технологии в этом плане, что если есть 2 BRAS с подключением абонентов, то при установлении сессии, кто из брасов первым ответил на клиентский PADI, с тем сессия и устанавливается, а поскольку более нагруженный брас будет отвечать с большей задержкой, то нагрузка будет более-менее равномерно распределяться между ними. Если же BRAS хлопается, то по idle-timeout абонент пытаеся переустановить сессию и подключается к оставшемуся BRAS. Все, технология проста до безобразия.

 

Все это хорошо только в теории. А вы а практике пробовали? На практике вовсе не так.

а поскольку более нагруженный брас будет отвечать с большей задержкой

Ну ну. На практике будет 600 сессий на 1 брасе и 30 штук на другом. И отвечать будет первый, несмотря на то, что он уже жует мегабит 700 трафа и 600-700 сессий.