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

Выбор роутера для небольшого провайдера

А в чем глючноть и костыльность IPoE/DHCP. Мне кажется время всяких ПППоЕ прошло, когда люди перестали воровать инет с чужого кабеля. Зачем этот гемор с настройкой ПППоЕ для клиента?

Share this post


Link to post
Share on other sites
11 минут назад, VolanD666 сказал:

А в чем глючноть и костыльность IPoE/DHCP.

В том, что в них по определению нет сессий, они эмулируются первым пакетом и таймаутом.

Эта эмуляция и сама по себе не идеальна, плюс на нее накладываются еще и сбои/глюки BRAS.

Share this post


Link to post
Share on other sites

Да, IPoE/DHCP костыль, но вот почему-то IEEE 802.1x не взлетел.

Share this post


Link to post
Share on other sites

А причем тут dot1x? Это немного другая тема. Щас задача поднятия сессии именно в том, чтобы на нее политики навешать. А dot1x это про огранчиение доступа к сети. А не взлетел он, т.к. в ОС такие пляски были с авторизацией, что клиенты просто рыдали.

Share this post


Link to post
Share on other sites
55 минут назад, VolanD666 сказал:

Щас задача поднятия сессии именно в том, чтобы на нее политики навешать.

Расскажите какие политики вы навешиваете сейчас для своих абонентов?

И как они меняются в зависимости от абоне6нта.

Edited by Стич

Share this post


Link to post
Share on other sites
4 минуты назад, Стич сказал:

Расскажите какие политики вы навешиваете сейчас для своих абонентов?

Ну скоростные конечно. Странный вопрос, а вы как делаете?

Edited by VolanD666

Share this post


Link to post
Share on other sites
5 минут назад, VolanD666 сказал:

Ну скоростные конечно. Странный вопрос, а вы как делаете?

Я о наличия необходимости сессий.

Мы навешиваем политики на абонентский IP, который постоянный.

 

Share this post


Link to post
Share on other sites
Только что, Стич сказал:

Я о наличия необходимости сессий.

Мы навешиваем политики на абонентский IP, который постоянный.

 

Ну если мы с вами говорим про ISG, сессия то там есть. Просто, понятно дело, в качестве логина используется ИП клиента.

Share this post


Link to post
Share on other sites
4 часа назад, VolanD666 сказал:

Брас это не только ПППоЕ. И какой это л2 свич у вас умеет функционал подобный ISG? Как в вашей архитектуре реализуется политика, когда нужно до одних ресурсов отрезать 10 мбит, а для остальных 50?

Про хПОН вы конечно все классно пишите. Но он был придуман не для города, а для поселков. А то что какое-какой оператор (не будем его называть) используют эту технологию в городе- это проблемы его абонентов.

Тема с белыми ИПами совсем странная, допустим мне не нужен белый ИП, что тогда?

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

И у меня тут случилась догадка, у вас что, микротики на доступе стоят?

Берём любой популярный свич доступа, например dlink des-3200 (есть полные аналоги от eltex, snr, cisco, edge-core и т.п., различия только на уровне синтаксиса команд, функционал одинаковый). Какой функционал вы берёте от ISG? Я правильно понял - ААА и полисинг? Как это реализовать в свиче доступа, разложим по порядку.

1. ААА. Авторизация абонента выполняется по запросу радиуса в базу биллинга, когда радиус получает от dhcp-relay реквесты на dhcp. Если у абонента нету денег или он заблокирован, ему отдаётся серый ip, для которого роутинг в абонентском влане выстроен с заворотом http-трафика на локальный сайт "заплати денег". Если абоненту разрешён доступ в Интернет, ему по dhcp отдаётся "нормальный" ip с маршрутизацией на внешний мир. Блокировать потуги абонента заспуфить MAC/IP легко с помощью IMPB. Как сделать аккаунтинг, который dhcp не умеет априори? Да очень просто - раз в минуту (или реже) опрашивать по snmp на свиче доступа таблицу привязок IMPB. Есть в таблице связка для mac-ip-port абонента - сессия жива, нет связки - сессия завершилась. Нужен трафик по сессии? - снимайте по snmp счётчики трафика на порту пока сессия жива.

2. Полисинг. Любой свич умеет банальный rate-limit на порту, выставляется по snmp влёт.

3. Что там ещё остаётся из реально полезного у ISG? Сервисы? Ну так раздавайте абону при dhcp-авторизации такие ip, к которым привязаны необходимые наборы сервисов. C IPTV вообще просто - оно полностью отдельно управляется для абона через ISM + igmp-authentication.

 

И на кой Вам приспичило абону делить ресурсы по скорости доступа (куда-то 10М, а куда-то 50М)? Извините, но это либо рудименты "нулевых" (MSK-IX/UA-IX бесплатно, "мир" за деньги), либо сильно попахивает нищебродством...

 

Коллеги! Я весьма уважаю девелоперов cisco, изобретающих мега-железяки. ISG - это здорово! Но это не религия, зачем на неё молиться? Вы всё равно доступ делаете на вполне навороченных свичах, хотя бы для того, чтобы отфильтровать мусор. Ибо, если абонентский мусор приедет в ядро, то никакая cisco вам уже не поможет. Ну так, а если доступ умеет делать всё, что необходимо, зачем же этим пренебрегать и тратить дополнительно весьма немалые средства на мега-железяки в ядро?

Edited by nemo_lynx

Share this post


Link to post
Share on other sites
4 часа назад, planhima сказал:

Подаете на порт абонента сервисную VLAN, сотрудник техподдержки просит абонента переключить кабель из порта WAN в порт LAN, сотрудник техподдержки получает доступ к устройству абонента получив IP адрес, настраивает его (если у вас техподдержка имеет доступ на оборудование). Я согласен с вами что лучше не использовать pppoe т.к. на всех абонентских устройствах по умолчанию установлена настройка получить ip автоматически. Сегмент не большой поэтому я так рассуждаю.

Волшебно! А в это время сосед этого абонента подключен к оператору, у которого IPoE/dhcp. Он просто достаёт из коробки ЛЮБОЙ девайс и в подходящий порт втыкает кабель оператора. И тут же получает доступ в Интернет. Разницу не замечаете? :)

Share this post


Link to post
Share on other sites
32 минуты назад, nemo_lynx сказал:

Как это реализовать в свиче доступа, разложим по порядку.

1. ААА. Авторизация абонента выполняется по запросу радиуса в базу биллинга, когда радиус получает от dhcp-relay реквесты на dhcp. Если у абонента нету денег или он заблокирован, ему отдаётся серый ip, для которого роутинг в абонентском влане выстроен с заворотом http-трафика на локальный сайт "заплати денег". Если абоненту разрешён доступ в Интернет, ему по dhcp отдаётся "нормальный" ip с маршрутизацией на внешний мир. Блокировать потуги абонента заспуфить MAC/IP легко с помощью IMPB. Как сделать аккаунтинг, который dhcp не умеет априори? Да очень просто - раз в минуту (или реже) опрашивать по snmp на свиче доступа таблицу привязок IMPB. Есть в таблице связка для mac-ip-port абонента - сессия жива, нет связки - сессия завершилась. Нужен трафик по сессии? - снимайте по snmp счётчики трафика на порту пока сессия жива.

2. Полисинг. Любой свич умеет банальный rate-limit на порту, выставляется по snmp влёт.

3. Что там ещё остаётся из реально полезного у ISG? Сервисы? Ну так раздавайте абону при dhcp-авторизации такие ip, к которым привязаны необходимые наборы сервисов. C IPTV вообще просто - оно полностью отдельно управляется для абона через ISM + igmp-authentication.

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

1. На нормальном BRAS не нужны никакие костыли с опросом SNMP, разнообразными релеями, постоянно глючащими снупингами и биндингами (а при мультивендорности это все превращается в мазохизм). Там просто l2connected, с которым можно делать что угодно.

2. Я бы не сказал, что любой свитч это умеет. Может быть пытается, с разной степенью успешности. На многих коммутаторах полисер адекватно работает только в одном направлении. На других коммутаторах полисер выставляется с каким-то шагом (часто — большим). И качеством полисера коммутаторы доступа обычно не отличаются.

3. Я так понял, что вариант раздавать белые IP даже не рассматривается (впрочем на IPoE/DHCP это нельзя делать нормально). Уже одно это является доводом против такой схемы.

Share this post


Link to post
Share on other sites
42 минуты назад, nemo_lynx сказал:

Берём любой популярный свич доступа, например dlink des-3200 (есть полные аналоги от eltex, snr, cisco, edge-core и т.п., различия только на уровне синтаксиса команд, функционал одинаковый). Какой функционал вы берёте от ISG? Я правильно понял - ААА и полисинг? Как это реализовать в свиче доступа, разложим по порядку.

1. ААА. Авторизация абонента выполняется по запросу радиуса в базу биллинга, когда радиус получает от dhcp-relay реквесты на dhcp. Если у абонента нету денег или он заблокирован, ему отдаётся серый ip, для которого роутинг в абонентском влане выстроен с заворотом http-трафика на локальный сайт "заплати денег". Если абоненту разрешён доступ в Интернет, ему по dhcp отдаётся "нормальный" ip с маршрутизацией на внешний мир. Блокировать потуги абонента заспуфить MAC/IP легко с помощью IMPB. Как сделать аккаунтинг, который dhcp не умеет априори? Да очень просто - раз в минуту (или реже) опрашивать по snmp на свиче доступа таблицу привязок IMPB. Есть в таблице связка для mac-ip-port абонента - сессия жива, нет связки - сессия завершилась. Нужен трафик по сессии? - снимайте по snmp счётчики трафика на порту пока сессия жива.

2. Полисинг. Любой свич умеет банальный rate-limit на порту, выставляется по snmp влёт.

3. Что там ещё остаётся из реально полезного у ISG? Сервисы? Ну так раздавайте абону при dhcp-авторизации такие ip, к которым привязаны необходимые наборы сервисов. C IPTV вообще просто - оно полностью отдельно управляется для абона через ISM + igmp-authentication.

 

И на кой Вам приспичило абону делить ресурсы по скорости доступа (куда-то 10М, а куда-то 50М)? Извините, но это либо рудименты "нулевых" (MSK-IX/UA-IX бесплатно, "мир" за деньги), либо сильно попахивает нищебродством...

 

Коллеги! Я весьма уважаю девелоперов cisco, изобретающих мега-железяки. ISG - это здорово! Но это не религия, зачем на неё молиться? Вы всё равно доступ делаете на вполне навороченных свичах, хотя бы для того, чтобы отфильтровать мусор. Ибо, если абонентский мусор приедет в ядро, то никакая cisco вам уже не поможет. Ну так, а если доступ умеет делать всё, что необходимо, зачем же этим пренебрегать и тратить дополнительно весьма немалые средства на мега-железяки в ядро?

 

Простите, если не секрет, что за провайдер?

Share this post


Link to post
Share on other sites
3 часа назад, alibek сказал:

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

1. На нормальном BRAS не нужны никакие костыли с опросом SNMP, разнообразными релеями, постоянно глючащими снупингами и биндингами (а при мультивендорности это все превращается в мазохизм). Там просто l2connected, с которым можно делать что угодно.

2. Я бы не сказал, что любой свитч это умеет. Может быть пытается, с разной степенью успешности. На многих коммутаторах полисер адекватно работает только в одном направлении. На других коммутаторах полисер выставляется с каким-то шагом (часто — большим). И качеством полисера коммутаторы доступа обычно не отличаются.

3. Я так понял, что вариант раздавать белые IP даже не рассматривается (впрочем на IPoE/DHCP это нельзя делать нормально). Уже одно это является доводом против такой схемы.

1. Не нужны релеи? Точно? Тогда каким образом абонент получит IP по dhcp? БРАС выдаст? На основании чего, как идентифицирует абонента? l2connected в ISG - это либо на основании выдаваемой по dhcp связке MAC/IP, либо просто появились на входе пакеты от незарегистрированного МАС. Но в любом случае, что-то должно же реализовывать для абонента dhcp и, очевидно, ещё и с opt.82. Так что без "разнообразных релеев" никак однако. Не нужны опросы snmp??? Совсем??? Вы вообще что ли не мониторите оборудование доступа?

2. Вы просто, видимо, давно не пробовали... Умеют, причём почти все и довольно точно. Времена меняются.

3. С чего такой вывод? Я в постах выше наоборот как бы ратовал за отказ от НАТа... И с чего вдруг IPoE/DHCP не может раздавать "белые" IP? Какая разница DHCP-серверу какие адреса раздавать? Что вынул ему радиус из фронт-таблицы биллинга, то и выдаёт. А как формируется эта фронт-таблица - уже дело самого биллинга.

 

3 часа назад, VolanD666 сказал:

Простите, если не секрет, что за провайдер?

Например, украинский Киевстар (долю рынка ШПД Украины сами нагуглите). В райцентре 50к населением есть только свичи доступа во многоэтажках и один Л3-пицца-свич в сайте сотовой базы (агрегация со всего города). Далее двумя линками 10Г трафик роутится в 2 ближайших областных центра. Полисинг на порту доступа. И никаких брасов.

Edited by nemo_lynx

Share this post


Link to post
Share on other sites

Т.е. у вас 50к абонентов и вы каждому выдаете по белому адресу? Дык вот куды ИПы то ушли...

Share this post


Link to post
Share on other sites

H-qos то ваш коммутатор доступа сделает? Смены адресов для блок / разблок это какой-то ад.

 

а трафик на зоны разбивать эт хорошо. До тех же кэшей незачем резать скорость.

Share this post


Link to post
Share on other sites
2 минуты назад, VolanD666 сказал:

Т.е. у вас 50к абонентов и вы каждому выдаете по белому адресу? Дык вот куды ИПы то ушли...

Та да :) . Ещё гляньте, сколько их Ростелек припас...

Share this post


Link to post
Share on other sites

1. Если говорить за PPPoE (да и вообще за PPP), то да, релеи не нужны. Если говорить за IPoE VPU, то да, тут релеи как таковые не нужны (поскольку сеть сегментирована до пользователя), хотя могут использоваться в разных реализациях. И snmp для ISG не нужен, ISG самодостаточен. У нас SNMP используется в мониторинге сети, но к оказанию сервисов никакого отношения не имеет.

 

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

 

3. С предложения назначать IP в зависимости от того, какие сервисы нужно предоставлять. В централизованной модели с BRAS я сервисы назначаю на сессию, а не на подсети, и сервисы могут комбинироваться.

Share this post


Link to post
Share on other sites
4 минуты назад, alibek сказал:

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

И главное как быть, если у юзера на одном линке: канал в инет (512кбит) и л2 какой-нить (100 мбит) и ИПтв. И главное пользователь очень не хочет сидеть голой жопой в инете и ему нафиг не сдался мой белый ИП (что ему, роутер предложить купить?).

Share this post


Link to post
Share on other sites

Ну какие-то коммутаторы умеют несколько очередей, QoS и сложные ACL. Но я бы не сказал, что такие массово используются на доступе. К тому же сильно сомневаюсь, что эти сложные правила можно будет задать через RADIUS, скорее всего нужно будет их делать через консоль или в лучшем случае SNMP.

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

 

Мы некоторое время назад в частных случаях на доступ ставили Mikrotik RB260GS. Сейчас меняем (слишком уж у них убогие буфера) на 8-портовые DGS-1100/ME или SNR-2985, тем не менее с десяток RB260 еще остались. Хотел бы я посмотреть, что они там наполисят. Когда я на стенде проверял, можно ли по ним подать L2VPN, то результаты были близки к рандомным.

Share this post


Link to post
Share on other sites

В нормальной сети свичи на доступе должны уметь только во вланы и snmp. Больше от них ничего не нужно.

.@alibek

Я что-то не понимаю, но откуда l2vpn на дешевых l2-коммутаторах?

Share this post


Link to post
Share on other sites

@planhima Да. Тазик уже заказан. Даже чуть мощнее. Про Tx Rx прерывания спасибо. В качестве операционки выбрал VyOS. Потестирую отпишусь)) Если что-то не устроит - куплю некроциску).

@nemo_lynx Люто плюсую к каждому твоему посту. Не вижу смысла в PPPoE в современном доступе от слова совсем. (Может не моего полёта мысль про PPPoE). Тратить деньги на брас ради сессий? Нам они **уй не нужны эти ваши сессии. Меня неинтересует сколько секунд провёл в сети абонент. А по остальным потребностям есть snmp. Почему вопрос стоял именно о бордере - потому что я буду в GPON. В частный сектор. Возможно ещё Wi-Fi. Многоэтажки где можно FTTB - не мой сегмент. Высокая конкуренция и гемморой в обслуживании. Говорю как сотрудник поддержки одной небезызвестной фирмы.

 

В тему разговора о белых IP. Ясное дело IPv4 дорого. Естественно у меня будет NAT. Но думаю купить блок IPv6 и раздавать абонентам. Кто пробовал? Грозит ли это абонентам какими-либо проблемами?

Share this post


Link to post
Share on other sites
2 минуты назад, Doctor_Dark сказал:

Тазик уже заказан. Даже чуть мощнее. Про Tx Rx прерывания спасибо. В качестве операционки выбрал VyOS. Потестирую отпишусь))

Ставьте два тазика для резервирования (bfd, vrrp, etc).

VyOS - хороший выбор. Вроде бы скрестили VyOS и ACCEL-PPP (но это не точно), так что теоретически и BNG можно поднять:
https://vyos.readthedocs.io/en/latest/services/ipoe-server.html

 

Share this post


Link to post
Share on other sites
В 10.10.2019 в 21:50, smelnik сказал:

В нормальной сети свичи на доступе должны уметь только во вланы и snmp. Больше от них ничего не нужно.

Спорам 'Smart Edge vs Dumb Edge' лет побольше, чем многим из участвующих. Иногда бывает выгоднее одно, иногда другое.

Share this post


Link to post
Share on other sites
9 часов назад, jffulcrum сказал:

Спорам 'Smart Edge vs Dumb Edge' лет побольше, чем многим из участвующих. Иногда бывает выгоднее одно, иногда другое.

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

Share this post


Link to post
Share on other sites
В 10.10.2019 в 21:26, nemo_lynx сказал:

Берём любой популярный свич доступа, например dlink des-3200 (есть полные аналоги от eltex, snr, cisco, edge-core и т.п., различия только на уровне синтаксиса команд, функционал одинаковый). Какой функционал вы берёте от ISG? Я правильно понял - ААА и полисинг? Как это реализовать в свиче доступа, разложим по порядку.

1. ААА. Авторизация абонента выполняется по запросу радиуса в базу биллинга, когда радиус получает от dhcp-relay реквесты на dhcp. Если у абонента нету денег или он заблокирован, ему отдаётся серый ip, для которого роутинг в абонентском влане выстроен с заворотом http-трафика на локальный сайт "заплати денег". Если абоненту разрешён доступ в Интернет, ему по dhcp отдаётся "нормальный" ip с маршрутизацией на внешний мир. Блокировать потуги абонента заспуфить MAC/IP легко с помощью IMPB. Как сделать аккаунтинг, который dhcp не умеет априори? Да очень просто - раз в минуту (или реже) опрашивать по snmp на свиче доступа таблицу привязок IMPB. Есть в таблице связка для mac-ip-port абонента - сессия жива, нет связки - сессия завершилась. Нужен трафик по сессии? - снимайте по snmp счётчики трафика на порту пока сессия жива.

2. Полисинг. Любой свич умеет банальный rate-limit на порту, выставляется по snmp влёт.

3. Что там ещё остаётся из реально полезного у ISG? Сервисы? Ну так раздавайте абону при dhcp-авторизации такие ip, к которым привязаны необходимые наборы сервисов. C IPTV вообще просто - оно полностью отдельно управляется для абона через ISM + igmp-authentication.

 

И на кой Вам приспичило абону делить ресурсы по скорости доступа (куда-то 10М, а куда-то 50М)? Извините, но это либо рудименты "нулевых" (MSK-IX/UA-IX бесплатно, "мир" за деньги), либо сильно попахивает нищебродством...

 

Коллеги! Я весьма уважаю девелоперов cisco, изобретающих мега-железяки. ISG - это здорово! Но это не религия, зачем на неё молиться? Вы всё равно доступ делаете на вполне навороченных свичах, хотя бы для того, чтобы отфильтровать мусор. Ибо, если абонентский мусор приедет в ядро, то никакая cisco вам уже не поможет. Ну так, а если доступ умеет делать всё, что необходимо, зачем же этим пренебрегать и тратить дополнительно весьма немалые средства на мега-железяки в ядро?

 

Вы прослушали краткий курс "как НЕ НАДО ДЕЛАТЬ если не хочешь выстрелить себе в ногу".

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