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

25k pptp sess / 1Mpps Какой железкой можно получить?

 

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

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


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

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

 

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

 

;-)

 

 

.

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

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


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

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

 

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

 

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

 

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


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

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

 

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

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

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

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

 

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

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

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


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

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

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


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

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

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


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

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

+1

 

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

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

 

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

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

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


Ссылка на сообщение
Поделиться на других сайтах
Ни у cisco, ни у juniper я схемы динамического выделения адресов для схем с dhcp-option 82 не видел.
Может быть плохо искали? Если мне не изменяет пямять, то адреса ввыделяются динамически с пула дхцп сервера, запущеного на том же ISG или ERX.

 

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


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

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

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

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


Ссылка на сообщение
Поделиться на других сайтах
Для 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)

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


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

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

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


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

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

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

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


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

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

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


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

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

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


Ссылка на сообщение
Поделиться на других сайтах
Здесь подробно описан механизм резервирования для 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 и т.п).

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

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

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


Ссылка на сообщение
Поделиться на других сайтах
Для 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, то тогда как мы будем идентифицировать абонента, чтобы его отполисить согласно тарифа?

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


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

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

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


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

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

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

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


Ссылка на сообщение
Поделиться на других сайтах
Для 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 границу, когда потерян мак адрес.

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

Изменено пользователем rus-p

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


Ссылка на сообщение
Поделиться на других сайтах
Если указать, что порт X получит IP из пула Z, то тогда как мы будем идентифицировать абонента, чтобы его отполисить согласно тарифа?
Начните пойск в гагле с ключевой фразы "Cisco ISG".

 

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

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

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


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

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

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

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

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


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

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

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


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

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


Ссылка на сообщение
Поделиться на других сайтах
Блять, а почему именно arp? А по любому неклассифицированному пакету нельзя?
tgz, плохо это на самом деле, keepilve сессии отследить не реально.

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

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


Ссылка на сообщение
Поделиться на других сайтах
либо стягивать по L2 абонентов к централизованным bras

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

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

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


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

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас