PPPoE vs IPoE

[Bambuk]

Многие меня убеждают что PPPoE при Ethernet доступе не дело и надо юзать чистый IP с DHCP Option82.

Давайте обсудим технологии доступа абонентов PPPoE и чистого IP при Ethernet доступе.

Требования:

1. Выдаются белые динамические адреса. Пул адресов - /17. Статика - за деньги.

2. Учет трафика, в том числе между пользователями. Детальный учет не нужен, достаточно учета по сервисам, определяемым с помощью ACL.

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

4. Возможность динамически менять ACL в процессе работы без разрыва соединения.

5. Возможность выдавать пользователю подсети адресов.

6. Возможность работы пользователя под своими учетными данными из любой точки сети, с любого порта, независимо от технологии(Ethernet, xDSL, etc.).

7. Автоматический load balacing и failover BRASов. Т.е. чтоб сервера доступа равномерно загружались и когда один из них загнулся или производится его maintenance пользователи автоматически ушли на другие.

 

Расскажите как реализовать все эти требования в случае чистого IP, особенно 5-7?

C PPPoE это все прекрасно делается.

[vIv]

5) RIP/BGP - по вкусу. Юзер соответственно должен это уметь

6) 802.1X

7) VRRP для failover, а вот с load-balancing сложнее, - не так уж просто нагрузить L3 wirespeed switch :-) Для DHCP соотв-нно N серверов в порядке очерёдности

 

А вот с PPPoE очень смешно выглядит multicast :-(

Edited January 28, 2008 by vIv

[igoriii]

так ведь можно совместить, внутренние сервисы по ipoe, а в инет по pppoe

[vIv]

это если одна IP-подсеть в локале. а если больше? ;-)

а два default-router уживаются вместе ооочень непросто :-)

[edwin]

> внутренние сервисы по ipoe, а в инет по pppoe

 

Тогда уже лучше инет по pptp ...а то выходит помесь быка и носорога

[vIv]

> внутренние сервисы по ipoe, а в инет по pppoe

 

Тогда уже лучше инет по pptp ...а то выходит помесь быка и носорога

Проблема двух Default не пропадёт

[Bambuk]

vIv, как вы на wirespeed свиче обеспечите пункты 2 и 3 ? Приведите пример такого свича.

 

Нормальных агрегаторов PPTP(32К сессий 5-8Гбит/с в одном боксе) я не видел.

 

Прогресс не стоит на месте и мультикаст научили жить с PPPoE. IGMP proxy c PPP encapsulation. Т.е. если аксес устройство видит от клиента IGMP в обертке PPPoE, оно в дополнение к обычному IGMP snooping/proxy запоминает PPPoE session id, чтоб потом приходящий от апстрима мультикаст обертывать в PPPoE заголовок и отправлять этому клиенту. Не все производители это пока поддерживают, но все вполне реализуемо.

[nnm]

Прогресс не стоит на месте и мультикаст научили жить с PPPoE. IGMP proxy c PPP encapsulation. Т.е. если аксес устройство видит от клиента IGMP в обертке PPPoE, оно в дополнение к обычному IGMP snooping/proxy запоминает PPPoE session id, чтоб потом приходящий от апстрима мультикаст обертывать в PPPoE заголовок и отправлять этому клиенту. Не все производители это пока поддерживают, но все вполне реализуемо.

Скажите пожалуйста, а на каких коммутаторах доступа это поддерживается? Вообще у меня создается ощущение, что производители коммутаторов о PPPoE модели вообще не думают...

Как мне кажется, коммутаторы доступа независимо от модели должны изолировать абонентов друг от друга. И трафик между абонентами по хорошему должен передаваться через BRAS, где его ограничат и посчитают независимо от модели доступа.

С моей точки зрения чем PPPoE действительно лучше - так это наличием понятия 'сессия' не только на умном BRAS, но и у абонента. В DHCP с этим сложнее :(

[vIv]

2) sFlow/NetFlow примеров - бездна. CISCO, ProCurve, и ещё море. Даже D-Link sFlow местами освоил.

3) тут да, тут шейпер и QoS надо. Если шейпер на серверах сервисов и бордере есть и умеют красить трафик - то от нижестоящего нужно только QoS.

 

Пример: ProCurve 3500/6200, CISCO ME3400

 

Вот с шейпером - самая сложная задача из всех :-)

 

// Committed Access Rate ?

Edited January 28, 2008 by vIv

[Bambuk]

nnm, пока я это нашел у Huawei, правда не совсем на коммутаторе. Железка называется MA5600T. Для Ethernet доступа там есть 16 портовые 100baseFX платы. В железке 16 слотов, т.е. 256 оптических 100Мбит портов можно собрать и 4 10GE наверх в одном шасси.

Именно с буквой Т в конце, т.к. есть MA5600 просто - там этого нет.

 

Давайте вместе пинать производителей. Я уже d-link начал. Они говорят - будут еще запросы, будем думать.

 

 

2) Есть куча проблем с sFlow/NetFlow. Во-первых sampled при точном учете не устроит. Во-вторых, при динамических IP привязывать клиентов к их данным весьма сложно. Далее, они как правило считают трафик входящий на железку, а если пользователь себе ACL поставил, то этот трафик ему считать не надо. Ну и объемы данных - убиться можно.

 

Да, Committed Access Rate. Шейперы на таких железках - это миф. Попробуй посчитай сколько памяти надо под буфера хотябы для 4К сессий :) И для wirespeed это должна быть не обычная память роутпроцессора, а в асике, который форвардингом занимается.

[nnm]

nnm, пока я это нашел у Huawei, правда не совсем на коммутаторе. Железка называется MA5600T. Для Ethernet доступа там есть 16 портовые 100baseFX платы. В железке 16 слотов, т.е. 256 оптических 100Мбит портов можно собрать и 4 10GE наверх в одном шасси.

Именно с буквой Т в конце, т.к. есть MA5600 просто - там этого нет.

MA5600 это в душе DSLAM. На DSLAM тонкие манипуляции с PPPoE - достаточно распространенная функциональность. А вот на коммутаторах доступа нет. Согласитесь, что монстр с 16-ю слотами, занимащий пол-стойки, и потребляющий, что-то вроде киловатта на роль коммутатора доступа не тянет :)

 

Давайте вместе пинать производителей. Я уже d-link начал. Они говорят - будут еще запросы, будем думать.

Завидую Вашему оптимизму и настойчивости. :) Мне кажется, что это безнадежно... В Cisco кстати этого тоже нет. Скорее допилят DHCP....

 

2) Есть куча проблем с sFlow/NetFlow. Во-первых sampled при точном учете не устроит. Во-вторых, при динамических IP привязывать клиентов к их данным весьма сложно. Далее, они как правило считают трафик входящий на железку, а если пользователь себе ACL поставил, то этот трафик ему считать не надо. Ну и объемы данных - убиться можно.

 

Да, Committed Access Rate. Шейперы на таких железках - это миф. Попробуй посчитай сколько памяти надо под буфера хотябы для 4К сессий :) И для wirespeed это должна быть не обычная память роутпроцессора, а в асике, который форвардингом занимается.

Я возможно повторюсь, но мне кажется, что правильное решение - тупые (с точки зрения сервисов) коммутаторы на доступе, которые не умеют ничего кроме VLAN, коммутации, разграничения пользователей, какие-то элементарные механизмы защиты от MAC spoofing и может быть опционально MVR. Сервисы - на BRAS. Каковой BRAS имеет и достаточно памяти и умеет считать пользователей и статистику отдавать не в NetFlow в RADIUS. Только стоит зараза дорого :(

[Bambuk]

Интересно, а чего дремлют отечественные производители сетевого оборудования. Я б на их месте уже давно занялся разработкой edge железок с аппаратной реализацией предоставления сервисов, в которые бы втыкались коммутаторы доступа. Какой-нить Xilinx Virtex-5 штук 20 гигабитных портов, я думаю, не напрягаясь пережует. Даже если не сервисы, а препроцессинг трафика от клиентов делать типа реврайтинга пакетов и т.п. уже польза будет.

[nnm]

Штука в том, что железка с аппаратной реализацией сервисов - это пожалуй самое сложное, что есть в телекоме :) Не сделать ее не имея за плечами опыта и не набив шишек. Я предлагаю начать с коммутаторов доступа :)

[photon]

Интересно, а чего дремлют отечественные производители сетевого оборудования.

Ну это вы загнули. В России не смогут сделать даже конкурентноспособные MAC и PHY чипы для Gigabit Ethernet. Ну а ежели помечтать, то сделал бы кто-нибудь PCIe-девайс с аппаратными хэш-таблицами для NAT и эффективной классификации в per-user QoS.

Edited October 31, 2009 by photon

[photon]

Тогда уже лучше инет по pptp ...а то выходит помесь быка и носорога

Шило на мыло. Это устаревшее поделие Microsoft с уязвимостями в алгоритме аутентификации сейчас внедрять еще более бессмысленно, чем PPPoE. От PPTP уже даже Корбина отказалась в пользу L2TP.

 

Доступ в Интернет по PPPoE -- это своего рода дискриминация энд-юзеров и занижение планки качества обслуживания. Дескать, у меня в сети только серверы и маршрутизаторы будут иметь беспроблемный доступ по IPoE и с белыми IP, а вам -- только через туннели, с каким-нибудь гемором по поводу MTU и логинов/паролей, берите пока дают и еще скажите спасибо.

Edited October 31, 2009 by photon

[shicoy]

Неужели осталить провайдеры end-user с обсчетом межпользовательского трафика?

[jab]

Интересно, а чего дремлют отечественные производители сетевого оборудования.

Ну это вы загнули. В России не смогут сделать даже конкурентноспособные MAC и PHY чипы для Gigabit Ethernet. Ну а ежели помечтать, то сделал бы кто-нибудь PCIe-девайс с аппаратными хэш-таблицами для NAT и эффективной классификации в per-user QoS.

А смысл ? Делать отдельный девайс, рынок сбыта которого даже без учета цены исчисляется сотней-другой ?

[jab]

Доступ в Интернет по PPPoE -- это своего рода дискриминация энд-юзеров и занижение планки качества обслуживания.

"по PPPoE" уберите, и будет правильно. :-)))

 

Любой доступ в Интырнет является какой-нибудь дискриминацией и занижением планки качества обслуживания. Серые адреса - дискриминация, белые тоже дискриминация, в приличных странах

вон IPv6 раздают. Спамера забанил - дискриминация, разбанил - дискриминация, виндовые порты заблочил - дискриминация, не заблочил - дискриминация. Роутер на сети поставил - занижение

планки качества обслуживания, целых 5 миллисекунд *** к пингу в контре добавил. Роутер не поставил - занижение планки качества обслуживания, видеочат из-за троянов тормозит.

 

У меня вот есть и PPPoE, и IPoE, и PPTP, c серыми, белыми, черными адресами, натом и черти-чем еще. Абсолютно никакой разницы не вижу.

[Fduchun]

Из 5-7 пунктов самый сложный - это пункт 5 в модели Routed Subscriber - то есть когда у клиента стоит маршрутизатор за которым сидит нужная подсеть.

 

По 5-му пункту:

1-й способ - это статическое прописывание хостов на BNG (в терминологии TR-101, ранее назывался BRAS), что позволяет иметь несколько IP за одним MAC адресом.

2-й - в BNG должна быть фича, которая позволяет привязывать подсеть к одному MAC адресу, чтобы при динамическом заполнении anti-spoof таблицы у BNG не происходило конфликта

 

По 6-му все просто:

Уже давно все DSLAM и прочие девайсы - работают на базе Ethernet. Если ты используешь везде для агрегации единого вендора BNG, то в общем-то пофиг, какая среда подключения. Главное, провести типовую интеграцию и разработать модель подключения. Лучше делать просто VLAN или порт на концентратор абонентов (DSLAM, GPON OLT, Ethernet коммутатор). Но тогда изоляцию пользователей в пределах Broadcast домена должно делать само устройство концентрации. Проблема только с Wi-MAX (хотя там, такое, вроде бы есть) и с Wi-Fi - которое точно шареная среда.

Идентификация пользователя в IPoE ведется либо через web-портал (что многие считают проблемой, но на самом деле именно это обеспечит доступ из любой точки), либо на базе circuit-id, то есть того же VLAN. Но тогда, используя circuit-id как идентифкатор, теряем универсальность доступа. :)

 

По 7-му пункту все и просто и сложно:

Load Balancing можно делать только на базе per VLAN или per устройство концентрации. А Failover существенно проще чем в PPPoE модели. Так как нет сессии, то достаточно синхронизировать текущие состояния подключений между BNG (фактически, базы текущих активных абонентов) и все.

Edited October 31, 2009 by Fduchun

[JoeDoe]

Старая темка, однако.

Но читая список вопросов, ответ сам собой напрашивается - а почему надо выбирать?!

PPPoE для Multicast-a совсем не тянет - тогда начинаются всякие гибриды с MVR.

Все ответы на "нормальное" терминирование IPoE уже есть.

Правда, не всегда у всем известного мега-производителя.

 

[Voicemaster]

[...]

2. Учет трафика, в том числе между пользователями. Детальный учет не нужен, достаточно учета по сервисам, определяемым с помощью ACL.

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

vIv, как вы на wirespeed свиче обеспечите пункты 2 и 3 ? Приведите пример такого свича.

2) 3) ;-)

 

На сеть ставится PCRF, который пропишет policy в DPI , который, в свою очередь, вам на L7 разберет 500-600 протоколов, их проQoSит и проQuota'тит и учтет per service нужным образом.

 

 

Bambuk, вот вы мне другое скажите ;-)

 

Как мне на PPPoE сделать услугу, в которой у пользователя есть voip/tvoip as fast as possible, inet 50Mb на одновглазники/вконтакте, 1Mb на мир и dynamic 64Kb-1Mb в ЧНН на p2p ?

 

А! Одновглазников с лимитом 1Gb не отключать, если у юзверя бабло кончилось ;-)

 

;-)

 

.

Edited October 31, 2009 by Voicemaster

[jab]

Как мне на PPPoE сделать услугу, в которой у пользователя есть voip/tvoip as fast as possible, inet 50Mb на одновглазники/вконтакте, 1Mb на мир и dynamic 64Kb-1Mb в ЧНН на p2p ?

А! Одновглазников с лимитом 1Gb не отключать, если у юзверя бабло кончилось ;-)

;-)

Точно так же как и без PPPoE.

[Voicemaster]

Как мне на PPPoE сделать услугу, в которой у пользователя есть voip/tvoip as fast as possible, inet 50Mb на одновглазники/вконтакте, 1Mb на мир и dynamic 64Kb-1Mb в ЧНН на p2p ?

А! Одновглазников с лимитом 1Gb не отключать, если у юзверя бабло кончилось ;-)

;-)

Точно так же как и без PPPoE.

 

Ага, ценнички вспомним ;-)

 

.

[jab]

Ага, ценнички вспомним ;-)

На что ценнички ? На altq в ipfw ?

[Cr_net]

Ага, ценнички вспомним ;-)

На что ценнички ?

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