[VolanD666]

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

[alibek]

11 минут назад, VolanD666 сказал:

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

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

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

[Bushi]

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

[VolanD666]

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

[Стич]

55 минут назад, VolanD666 сказал:

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

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

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

Изменено 10 октября, 2019 пользователем Стич

[VolanD666]

4 минуты назад, Стич сказал:

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

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

Изменено 10 октября, 2019 пользователем VolanD666

[Стич]

5 минут назад, VolanD666 сказал:

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

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

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

 

[VolanD666]

Только что, Стич сказал:

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

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

 

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

[nemo_lynx]

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 вам уже не поможет. Ну так, а если доступ умеет делать всё, что необходимо, зачем же этим пренебрегать и тратить дополнительно весьма немалые средства на мега-железяки в ядро?

Изменено 10 октября, 2019 пользователем nemo_lynx

[nemo_lynx]

4 часа назад, planhima сказал:

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

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

[alibek]

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 это нельзя делать нормально). Уже одно это является доводом против такой схемы.

[VolanD666]

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 вам уже не поможет. Ну так, а если доступ умеет делать всё, что необходимо, зачем же этим пренебрегать и тратить дополнительно весьма немалые средства на мега-железяки в ядро?

 

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

[nemo_lynx]

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 ближайших областных центра. Полисинг на порту доступа. И никаких брасов.

Изменено 10 октября, 2019 пользователем nemo_lynx

[VolanD666]

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

[zhenya`]

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

 

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

[nemo_lynx]

2 минуты назад, VolanD666 сказал:

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

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

[alibek]

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

 

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

 

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

[VolanD666]

4 минуты назад, alibek сказал:

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

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

[alibek]

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

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

 

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

[smelnik]

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

.@alibek

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

[Doctor_Dark]

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

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

 

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

[Bushi]

2 минуты назад, Doctor_Dark сказал:

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

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

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

 

[jffulcrum]

В 10.10.2019 в 21:50, smelnik сказал:

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

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

[nemo_lynx]

9 часов назад, jffulcrum сказал:

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

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

[myst]

В 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 вам уже не поможет. Ну так, а если доступ умеет делать всё, что необходимо, зачем же этим пренебрегать и тратить дополнительно весьма немалые средства на мега-железяки в ядро?

 

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