Jump to content
Калькуляторы

DHCP vs PPPoE Сравнения.

Добрый день. Извиняюсь, если подобная тема, в том или ином виде, уже была.

Имеем распределенную Wi-Fi сеть, для авторизации и шейпинга пользуемся в данный момент PPPoE.

 

По работе возникла необходимость качественного сравнения PPPoE и DHCP организации доступа к сети, для принятия решения, оправдан ли переход на статику, и появится ли возможность увеличения числа абонентов, без построения дополнительных базовых станций.

С PPPoE все понятно, связка следующая: UTM5 + Radius(UTM'овский) + Mikrotik(PPPoE BRAS).

С DHCP немного сложнее: В том же UTM'е, при создании абонента, ему присваивается IP, MAC, тариф и VLAN. Далее, при обнаружении изменения состояния блокировки абонента, UTM вызывает скрипт, который через SSH создает на Mikrotik'е статическую ARP запись, статическую DCHP lease и queue, с нужной скоростью для определенного MAC'а.

Скрипты отработаны, все в порядке.

С точки зрения безопасности: VLAN до базовой станции, сегментация траффика(изоляция портов, при которой траффик может направлять лишь из порта, получившего его, в порт, направленный к ядру. Т.е. абоненты не увидят даже широковещательного траффика соседей).

 

Теперь сравниваем PPPoE и наш Static-DCHP:

 

Преимущества PPPoE:

Обслуживание биллинга и замена клиентской части относительно проще.

1)Нет привязки к MAC'у, что делает простым замену оборудования, в случае неисправности: нужно только настроить PPPoE на новом оборудовании.

2)Проще работа с IP пулами: адреса раздаются разным BRAS'ам, в разных VLAN'ах, из одних и тех же пулов.

3)Работа механизма авторизации и шейпинга "из коробки".

 

Недостатки PPPoE:

Скорость меньше, затрат больше.

1)Бо'льшая нагрузка на процессоры оборудования, работающего с PPPoE(коммутаторам, по понятным причинам, по большей части пофигу).

2)Больший размер служебных заголовков, как следствие, меньше полезной нагрузки можно передать вприципе.

3)Сложность масштабирования, так как влан от BRAS'a должен проходить до абонента непосредственно, и, если все брасы включены через агрегатор, кол.-во вланов не должно превышать стандартного числа.

 

 

Преимущество DHCP:

Понятнее, проще, менее требовательно к ресурсам сети, дешевле.

1)Простота и скорость настройки терминирующих устройств и клиентской части.

2)Прозрачность механизма работы и диагностики.

3)Минимальный размер служебных заголовков, нагрузки процессоров - большая скорость(По личному опыту, в конктесте wifi, во время пиковых нагрузок разница в 2-3 раза).

4)Простота масштабирования.

 

Недостатки DHCP:

Больше работы с ядром.

1)Необходима четкая отработка сриптов, отрабатываемых при блокировках\разблокировках.

2)Необходимо хорошо продуманное адресное пространство.

 

 

Прошу правок и дополнений.

Share this post


Link to post
Share on other sites

Узкое место тут - скрипты по ссш, это костыли. И емнип, у микротиков pppoe софтовый, что какбы намекает.

Share this post


Link to post
Share on other sites

Вяло как то.

 

Давайте похоливарим.

Share this post


Link to post
Share on other sites

а чего холиварить

из плюсов DHCP, то что он простой у саппорта работы меньше, а с pppoe много мороки и юзерам и саппорту

 

Узкое место тут - скрипты по ссш, это костыли

согласен, по-моему на брасе не должно быть серверного функционала, логичней держать там dhcp proxy (dhcp relay более тупой, но и он сойдет), а биллинг пусть управляет dhcp-сервером напрямую, идеальный вариант когда сервер встроен в сам биллинг. правда надо думать как поступить с нарезкой скорости (идеальный вариант как в Германии, отдавать сервис на скорости порта и не париться по таким мелочам)

Share this post


Link to post
Share on other sites

Последний прикол с DHCP/IPv4oE. Абоненту выдаётся маска /22, есть некие роутеры, которые для hw-nat держут arp-таблицу тоже в hw и если на WAN выдаётся маска короче, чем /23(hw arp размером 512 записей), то ничего толком не работает. Название CPE/вендора не хочется писать здесь, но в магазине их не купишь. Когда будет фикс - х/з. Если перейти на софтрежим, то обещают максимум мегабит 30

Share this post


Link to post
Share on other sites

1)Бо'льшая нагрузка на процессоры оборудования, работающего с PPPoE(коммутаторам, по понятным причинам, по большей части пофигу).

 

Не является проблемой, т.к. можно поставить более мощное оборудование или несколько серверов рядом.

 

2)Больший размер служебных заголовков, как следствие, меньше полезной нагрузки можно передать вприципе.

 

Не является проблемой, если в качестве CPE у вас не клиентские компьютеры, можно увеличить MTU в каналах и будут проходить пакеты 1500 байт без фрагментации.

 

3)Сложность масштабирования, так как влан от BRAS'a должен проходить до абонента непосредственно, и, если все брасы включены через агрегатор, кол.-во вланов не должно превышать стандартного числа.

 

Никаких сложностей, как раз у PPPoE самое простое масштабирование. Влан от браса не обязательно должен проходить до абонента, его можно упаковать в EoIP туннель, или поставить маленькие брасы прямо рядом с абонентами, как вариант делать их прямо на БС. А в центр данные пойдут уже по L3.

 

Преимущество DHCP:

1)Простота и скорость настройки терминирующих устройств и клиентской части.

 

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

 

2)Прозрачность механизма работы и диагностики.

 

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

 

3)Минимальный размер служебных заголовков, нагрузки процессоров - большая скорость(По личному опыту, в конктесте wifi, во время пиковых нагрузок разница в 2-3 раза).

 

Что-то не так настроили, что в 2 раза разница. По нашим сравнениям ее вообще нет.

 

4)Простота масштабирования.

 

Как раз сложность, поставьте ка 10 брасов и заведите абонентов на них.

 

Недостатки DHCP:

Больше работы с ядром.

1)Необходима четкая отработка сриптов, отрабатываемых при блокировках\разблокировках.

 

Обычно со скриптами не бывает проблем, если перед отправкой любой команды сначала отправлять аналогичную на удаление этого параметра.

 

2)Необходимо хорошо продуманное адресное пространство.

 

Как раз с этим проблем никаких нет, если использовать IPoE, то есть раздавать только 1 адрес абоненту.

 

из плюсов DHCP, то что он простой у саппорта работы меньше, а с pppoe много мороки и юзерам и саппорту

 

У нас например 3 типа подключений:

 

1. PPPoE на антенне абонента, дальше по кабелю автоматом.

2. PPPoE на компьютере/роутере абонента.

3. IPoE раздается автоматом 1 адрес.

 

Соответственно по пункту 1 вообще никто не звонит и нет никакой мороки юзерам и саппорту, т.к. все работает без проблем, по пункту 2 иногда звонят пароль спросить или уточняют, почему не соединяется, по пункту 3 самое большое количество звонков, т.к. абоненты ставят роутеры с нуля, которые автоматом получают настройки и раздают инет, но после что-то ломается с роутером и они жалуются, при этом со стороны саппорта видно, что роутер адрес получил, но до абонента интернет не идет. Решается перенастройкой клиентского роутера.

 

Но у нас PPPoE поверх L3 идет на брасы, а IPoE терминируется рядом с абонентами и так же идет на брасы уже в виде L3.

 

Узкое место тут - скрипты по ссш, это костыли. И емнип, у микротиков pppoe софтовый, что какбы намекает.

 

Уже лет 5 а то и более используем SSH, никаких проблем не возникало ни разу. Главное отправлять одну команду в одном соединении, после дисконнект и следующая.

Share this post


Link to post
Share on other sites

Влан от браса не обязательно должен проходить до абонента, его можно упаковать в EoIP туннель,

Нахрена плодить дополнительные сущности в виде доптуннелей?

 

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

А с EoIP будет все прозрачно, да.

Что-то не так настроили, что в 2 раза разница. По нашим сравнениям ее вообще нет.

Как минимум 2% на заголовки.

Share this post


Link to post
Share on other sites

Нахрена плодить дополнительные сущности в виде доптуннелей?

 

Для удобства, т.к. есть только 2 устройства, которые являются разными сторонами туннеля, соответственно все остальное не влияет на работу и может перенастраиваться, кроме всего есть возможность делать резервные каналы и т.п.

 

А с EoIP будет все прозрачно, да.

 

Да, если использовать правильно.

 

Как минимум 2% на заголовки.

 

Ничего страшного в этом нет.

Share this post


Link to post
Share on other sites

Вы тогда либо пишите шо он(оверхед) есть, но это не смертельно, либо тогда ничего не пишите. Иначе складывается вчепятление что вы несете чушь.

Share this post


Link to post
Share on other sites

Используя Ubilling - очень даже ничего масштабируются НАСы при дхцп.

А тунель - не есть хорошо, как минимум при кратковременном обрыве сессии нужно время, что бы старая закрылась, тем самым дать новой открыться.

И получается, что вместо 2 секунд отсутствия - получаем около двух минут. Мелочь, а неприятно.

Да и в придачу у Сааба никогда нет ни с чем проблем, ни с микротиками, ни с тунелированым трафиком.

ДХЦП проще в разы, особенно когда задействуешь 82 опцию, то жизнь вообще радужной становится!

Share this post


Link to post
Share on other sites

ДХЦП проще в разы, особенно когда задействуешь 82 опцию, то жизнь вообще радужной становится!

Не знаю, нам не с чем сравнивать, мы сразу строили сеть на opt82. Те же, кто ушел от туннелей на IPoE, говорят что саппорт не нарадуется.

Share this post


Link to post
Share on other sites

А тунель - не есть хорошо, как минимум при кратковременном обрыве сессии нужно время, что бы старая закрылась, тем самым дать новой открыться.

И получается, что вместо 2 секунд отсутствия - получаем около двух минут. Мелочь, а неприятно.

 

Ну так поставьте таймаут PPPoE 30 секунд или 60, вместо того, что по умолчанию стоит, тогда при кратковременных обрывах соединения прерываться не будут. У нас на радио 60 секунд стоит, можно даже клиентскую антенну с базы скинуть, пока она все частоты снова просканит и подключится, произойдет только кратковременная пауза, а после снова данные побегут в сеть без обрывов соединений.

 

Не знаю, нам не с чем сравнивать, мы сразу строили сеть на opt82. Те же, кто ушел от туннелей на IPoE, говорят что саппорт не нарадуется.

 

У каждого типа авторизации есть основные сферы применения, например PPPoE одинаково хорошо работает в беспроводных и кабельных сетях, а IPoE хорошо только для кабельной сети, т.к. заморачиваться с добавлением вланов или L2 туннелей на антеннах не удобно, тут уже опять выходит третий тип подключения - когда до антенны связь по L3 (PPPoE или DHCP), а на самой поднят OSPF и на кабельном интерфейсе раздается абоненту белая или серая сеть.

Share this post


Link to post
Share on other sites

правда надо думать как поступить с нарезкой скорости (идеальный вариант как в Германии, отдавать сервис на скорости порта и не париться по таким мелочам)

 

Если совсем не резать на брасе(или где-то в ядре) даунстрим(к абоненту), то это потенциальная уязвимость к DOS-атаке по полосе в сторону доступа. Если сверху напихают 1Gb/s трафика в сторону одного абонента, то это помешает работе многим другим, да ещё и буферы будет расходовать прилично(на переходах 10G-1G, 1G-100M)

 

Нет ничего плохого в том, чтобы отдавать абоненту 100М(или какая у него скорость порта), но всё-таки в ядре нужно удалять лишний трафик, заведомо не вписывающийся в порт к абоненту.

Share this post


Link to post
Share on other sites

правда надо думать как поступить с нарезкой скорости (идеальный вариант как в Германии, отдавать сервис на скорости порта и не париться по таким мелочам)

 

Если совсем не резать на брасе(или где-то в ядре) даунстрим(к абоненту), то это потенциальная уязвимость к DOS-атаке по полосе в сторону доступа. Если сверху напихают 1Gb/s трафика в сторону одного абонента, то это помешает работе многим другим, да ещё и буферы будет расходовать прилично(на переходах 10G-1G, 1G-100M)

 

Нет ничего плохого в том, чтобы отдавать абоненту 100М(или какая у него скорость порта), но всё-таки в ядре нужно удалять лишний трафик, заведомо не вписывающийся в порт к абоненту.

действительно, у нас буквально на днях посреди ночи прилетело нельколько гиг трафика и подропалось на брасе, дальше в сеть не ушло. похоже досили какого-то абонента. интересно, зачем кому-то досить физика.

 

наверное защиту от такого надо прорабатывать в рамках общей концепции безопасности сети

Share this post


Link to post
Share on other sites

похоже досили какого-то абонента. интересно, зачем кому-то досить физика

 

может там порнотрансляция или кардшаринг был поднят. за такое задосят запросто

 

ну вообще, если не физ.лиц, то банки с белыми ip, покупающие мегабит 20 могут тоже подосить, с таким сталкивался раньше. не так давно китайцы(или спуф под китайцев) досили один наш институт во время экзаменов. пришлось пойти им на встречу и повесить egress acl на их саб, но трафик всё равно долетал до PE

Share this post


Link to post
Share on other sites

по пункту 3 самое большое количество звонков, т.к. абоненты ставят роутеры с нуля, которые автоматом получают настройки и раздают инет, но после что-то ломается с роутером и они жалуются

 

ж))))))))))

Роутеры с PPPOE, видимо, либо никогда не ломаются, либо при поломке юзеры не звонят и не жалуются? :))) Ну и "перенастройку клиентского роутера" тоже, наверное, в этом случае делать не надо; всё чинится само? :))

 

У нас, по опыту, после ухода с туннелей на ipoe, нагрузка на техподдержку упала в несколько раз. И "абоненты ставят роутеры с нуля, которые автоматом получают настройки" - не недостаток, а офигенно удобно и круто.

 

Далее, при обнаружении изменения состояния блокировки абонента, UTM вызывает скрипт, который через SSH создает на Mikrotik'е статическую ARP запись, статическую DCHP lease и queue, с нужной скоростью для определенного MAC'а.

 

Ужс) Благородный дон что-нибуть слышал о freeradius и его rlm_***?

Share this post


Link to post
Share on other sites

Роутеры с PPPOE, видимо, либо никогда не ломаются, либо при поломке юзеры не звонят и не жалуются? :))) Ну и "перенастройку клиентского роутера" тоже, наверное, в этом случае делать не надо; всё чинится само? :))

 

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

Share this post


Link to post
Share on other sites

У нас в сети IPoE используется с привязкой к маку. Так вот, по моему мнению привязка к маку проще и лучше, чем pppoe.

 

Плюс PPPoE - есть логин пароль, который нужно только ввести в оборудование

Минус - это ошибки, которые могут возникать при подключении.

 

Плюс IPoE с привязкой к МАКу - нет никаких настроек, всё автоматически

Минус - сама привязка к МАКу

 

А вот простота настройки PPPoE в отличии от привязки к МАКу - это двояко. У нас 1500 клиентов и настроить любой вид подключения для них проблема. Звонят в любом случае.

Только в случае с IPoE и МАКом, переписать мак дело одной минуты, а объяснить как настроить PPPoE подключение в роутере уже проблема.

 

 

2)Проще работа с IP пулами: адреса раздаются разным BRAS'ам, в разных VLAN'ах, из одних и тех же пулов.

 

Мы отдаём белые динамические адреса через DHCP с привязкой к МАКу.

 

Есть 3 пула

 

Unknown - серый пул, который выдаётся всем по умолчанию. На нём переадресация на заглушку с сообщением о незарегистрированном устройстве.

whiteIP - белый пул адресов, который выдаётся статическим Leases

inetoff - серый пул, который выдаётся абонентам при отключении за неуплату. На нём тоже заглушка.

post-101104-053307500 1409491264_thumb.png

Share this post


Link to post
Share on other sites

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

Справедливости ради стоит сказать, что ближайшие лет 5 на рутеры с вана доступ запрещен под дефолту.

Share this post


Link to post
Share on other sites

Плюс IPoE с привязкой к МАКу - нет никаких настроек, всё автоматически

Минус - сама привязка к МАКу

У нас нет привязок к маку для IPOE - клиент волен втыкать любой девайс, он заработает мгновенно и автоматически. А вот для pppoe привязка к маку обязательна, школьники ведь любят делиться логинами.

 

Вообще по сути вопроса - любые тоннели на доступе - печаль и зло, и оно должно быть уничтожено.

Недавно у нас начались заявки от абонентов обновившихся до windows 8.1 - там глобальные грабли с pppoe, настроить соединение не удается вообще(вылетает с ошибками). Пока заявки единичные, решаем ускоренным переводом дома на ipoe, но ведь с каждым днем их будет больше.

Share this post


Link to post
Share on other sites

А вот для pppoe привязка к маку обязательна, школьники ведь любят делиться логинами.

решение уже 100500 лет назад придумали в виде pppoe+ - это тоже самое, что и opt82 в случае ipv4oe с dhcp-сигнализацией

Share this post


Link to post
Share on other sites

У нас нет привязок к маку для IPOE - клиент волен втыкать любой девайс, он заработает мгновенно и автоматически.

 

Бывают ситуации, что привязку к маку приходиться пользовать.

 

Я не рекомендую пользоваться привязкой, но нам проблем это никаких не прибавляет.

Share this post


Link to post
Share on other sites

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

Справедливости ради стоит сказать, что ближайшие лет 5 на рутеры с вана доступ запрещен под дефолту.

RouterScan так не считает))

Edited by Diamont

Share this post


Link to post
Share on other sites

У нас нет привязок к маку для IPOE - клиент волен втыкать любой девайс, он заработает мгновенно и автоматически

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

на длинках

Функция MAC Notification необходима для отсылки уведомляющих сообщений - trap - по протоколу SNMP... Функция отсылает уведомляющие сообщения в случае добавления, удаления или изменения МАС адресов на тех портах коммутатора, на которых она настроена.

на цисках есть полностью аналогичная возможность

 

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

Share this post


Link to post
Share on other sites

У нас нет привязок к маку для IPOE - клиент волен втыкать любой девайс, он заработает мгновенно и автоматически

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

на длинках

Функция MAC Notification необходима для отсылки уведомляющих сообщений - trap - по протоколу SNMP... Функция отсылает уведомляющие сообщения в случае добавления, удаления или изменения МАС адресов на тех портах коммутатора, на которых она настроена.

на цисках есть полностью аналогичная возможность

 

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

А зачем вообще вам эти маки уперлись? У нас vlan-per-user, на порту клиента разрешено 2 мака, что бы он не воткнул - мгновенно получит тот же IP и продолжит работу.

Скрипт маки собирает чисто для статистики и удобства техподдержки, но это совершенно отдельный сервис.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this