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

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

Имеем распределенную 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)Необходимо хорошо продуманное адресное пространство.

 

 

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

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


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

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

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


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

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

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

 

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

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

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


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

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

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


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

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, никаких проблем не возникало ни разу. Главное отправлять одну команду в одном соединении, после дисконнект и следующая.

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


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

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

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

 

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

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

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

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

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


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

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

 

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

 

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

 

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

 

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

 

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

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


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

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

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


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

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

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

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

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

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

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


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

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

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

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


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

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

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

 

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

 

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

 

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

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


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

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

 

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

 

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

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


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

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

 

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

 

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

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

 

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

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


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

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

 

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

 

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

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


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

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

 

ж))))))))))

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

 

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

 

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

 

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

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


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

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

 

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

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


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

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

 

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

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

 

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

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

 

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

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

 

 

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

 

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

 

Есть 3 пула

 

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

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

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

post-101104-053307500 1409491264_thumb.png

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


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

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

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

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


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

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

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

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

 

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

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

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


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

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

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

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


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

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

 

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

 

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

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


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

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

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

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

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

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


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

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

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

на длинках

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

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

 

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

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


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

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

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

на длинках

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

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

 

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

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

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

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


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.