[jab]

 

спор "что лучше: морковка, свекла или сельдерей ?"

[Voicemaster]

[...]

Кстати, в начале 2010 будет и L2-aware NAT, который позволит решить две задачи - мягкую миграцию на IPv6 и проблемы с масштабированием NAT-a на рутерах провайдера.

 

А можно с этого места поподробнее ? (с)

 

;-)

 

 

.

Изменено 2 декабря, 2009 пользователем Voicemaster

[JoeDoe]

[...]

Кстати, в начале 2010 будет и L2-aware NAT, который позволит решить две задачи - мягкую миграцию на IPv6 и проблемы с масштабированием NAT-a на рутерах провайдера.

 

А можно с этого места поподробнее ? (с)

 

Вот публичный application note на эту тему - там подробно расписано. Плюс можно посмотреть IETF draft-miles-behave-l2nat. Я не говорю, что это истина в последней инстанции, но как дешевая альтернатива stateful cgNAT - вполне.

 

[ingress]

почитал, учитывать некий ид(взятый из заголовка/тунеля) при нате - правильно.

 

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

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

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

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

 

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

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

[JoeDoe]

Если отвлечься от NAT-a, то сейчас при аутентификации на 7750 с помощью динамического SAPa, вы можете базируясь на информации Option 82 или VLAN ID (dot1q или qiniq) выдать адрес статически или динамически из пула и привязать этого конкретного подписчика к конкретному QoS профилю и к конкретному интерфейсу в любом VPRN (VRF) или в базовой рутинг инстанции. Я думаю, что при появлении L2-aware NAT можно будет привязывать и к конкретному внешнему адресу. Но пока - ждём 8.0.

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

Изменено 3 декабря, 2009 пользователем Lanc1

[Lanc1]

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

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

+1

 

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

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

 

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

Изменено 3 декабря, 2009 пользователем Lanc1

[Stak]

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

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

 

[JoeDoe]

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

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

[JoeDoe]

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

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

+1

 

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

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

 

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

Я уже здесь давал краткое описание работы ESM (Enhanced Subscriber Management) у Alcatel-Lucent. К сожалению, даже доступность мануалов не всегда помогает - уж больно они справочник напоминают. Есть у Alcatel-Lucent configuration notes и technical workshops - там да, всё описано, но они для внутреннего потребления, так сказать. (последний год service divison показывает хороший рост - наверное неплохо торгуют своим know how)

[tgz]

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

А если схема с DHCP Relay? И между интерфейсами нет L2 связности?

[visir]

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

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

Не нужно каждому пользователю выделять статический IP. И даже /30 на каждого юзера уже неактуально, /32 достаточно.

[mousus]

хорошо, IPoE считается трудным для резервирования на цисках, вот тут http://system-administrators.info/?p=3184 неплохо расписано как сделать отказоустойчивый фаервол на софтовых роутерах, carp как известно придумали глядя на hsrp, а еще человечество напридумывало таких ругательств как vrrp. Неужели никто не использует всё выше придуманное и оно и впрямь так бесполезно?

[visir]

хорошо, IPoE считается трудным для резервирования на цисках, вот тут http://system-administrators.info/?p=3184 неплохо расписано как сделать отказоустойчивый фаервол на софтовых роутерах, carp как известно придумали глядя на hsrp, а еще человечество напридумывало таких ругательств как vrrp. Неужели никто не использует всё выше придуманное и оно и впрямь так бесполезно?

Не смешивайте мягкое с теплым.

Синхронизация PIX/ASA есть с незапамятных временен, но для IPoE задачи другие.

[JoeDoe]

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

А если схема с DHCP Relay? И между интерфейсами нет L2 связности?

Архитектура подразумевает что между рутером и подписчиком L2 (IPoE или PPPoE), так как для идентификации подписчика используются пары IP-MAC адреса, построенные после аутентификации на основе option 82 или vlan id. Прямой L2 связи между самими рутерами не требуется. Если же есть проблемы с L2 в aggregation сети - то альтернативой может быть использование MPLS и e-pipe для проброски L2 траффика (есть рабочие примеры - 7705/7210 на доступе/базовых станциях, 7710/7750 - на управлении подписчиками, peering-e и т.п).

Решений же на все случаи жизни не бывает.

Изменено 3 декабря, 2009 пользователем JoeDoe

[Lut]

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

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

Не нужно каждому пользователю выделять статический IP. И даже /30 на каждого юзера уже неактуально, /32 достаточно.

Да я собственно не спорю, что с ip unnumbered можно /32 выдать пользователю.

На основании чего будем выдавать? Выдадим на основании opt.82. В DHCP у нас что прописано - порт Х получит IP Y.

Соответственно, на каждого абонента свой IP (в нашем случае белый).

 

Если указать, что порт X получит IP из пула Z, то тогда как мы будем идентифицировать абонента, чтобы его отполисить согласно тарифа?

[nevzorofff]

а D-Link DSA-7110 что за зверь? На сайте длинка нету, порылся немного — только продажные сайты с одинаковым текстом «и 3500 одновременными подключениями», которые то ли подключения, то ли локальная база на 3500 записей.

[Magnum72]

а D-Link DSA-7110 что за зверь? На сайте длинка нету, порылся немного — только продажные сайты с одинаковым текстом «и 3500 одновременными подключениями», которые то ли подключения, то ли локальная база на 3500 записей.

Это херня, больше 500-600 туннелей и нескольких десятков мегабит трафика они не тянут.

[rus-p]

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

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

Не нужно каждому пользователю выделять статический IP. И даже /30 на каждого юзера уже неактуально, /32 достаточно.

Да я собственно не спорю, что с ip unnumbered можно /32 выдать пользователю.

На основании чего будем выдавать? Выдадим на основании opt.82. В DHCP у нас что прописано - порт Х получит IP Y.

Соответственно, на каждого абонента свой IP (в нашем случае белый).

 

Если указать, что порт X получит IP из пула Z, то тогда как мы будем идентифицировать абонента, чтобы его отполисить согласно тарифа?

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

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

Изменено 4 декабря, 2009 пользователем rus-p

[visir]

Если указать, что порт X получит IP из пула Z, то тогда как мы будем идентифицировать абонента, чтобы его отполисить согласно тарифа?

Начните пойск в гагле с ключевой фразы "Cisco ISG".

 

UPD: а лучше даже с http://www.ciscoexpo.ru/moscow/2006/downlo...vleonov-RUS.pdf

Изменено 4 декабря, 2009 пользователем visir

[JoeDoe]

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

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

Кстати, сейчас появилась возможность авторизации не только через dhcp snooping, но и первому arp со стороны клиента, что позволяет авторизовать подписчиков со статической конфигурацией IP. Но по-любому нужна связка IP-MAC или NH(next-hop)-MAC в случае рутинга префиксов за клиентский хост.

Атрибуты шейпинга от RADIUS не спускаются, но идёт указание на использование того или иного профиля/шаблона. Конечно, это не даёт полной гибкости, но использование COA позволяет поменять профиль подписчику прямо "на ходу". А сколько реально шаблонов нужно для подписчиков?! Я не думаю, что тысячи.

[tgz]

***ь, а почему именно arp? А по любому неклассифицированному пакету нельзя?

[Lanc1]

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

[Cr_net]

***ь, а почему именно arp? А по любому неклассифицированному пакету нельзя?

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

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

[Cr_net]

либо стягивать по L2 абонентов к централизованным bras

и гонять локальный трафик через них. Я верю, такие схемы есть рабочие очевидно, но только у тех операторов, у которых очень много денег :)

у них денег больше потому что голова есть, в отличии от дающих засирать свою сеть давая гонять локал на скорости 100ки за ~0-∞ р, сейчас, а не лет через несколько.

Изменено 4 декабря, 2009 пользователем Cr_net