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

ipoe + radius

привет!

 

возможно ли вообще сделать в микротике аналог ipoe через авторизацию по радиусу? как опция82?

или там возможен какой-то свой костыль?

 

задача есть билинг utm5.3-003 нужно авторизовывать абонентов по радиусу но через dhcp\ipoe

Edited by Artom_12

Share this post


Link to post
Share on other sites

Вроде УТМ может по ссш на железки заходить?

Share this post


Link to post
Share on other sites

ну это + еще костыль который будет сколько-то обрабатываться, а средствами штатного radius клиента? слышал что можно толи как хотспот толи как dhcp через радиус передавать данные опции.82

Edited by Artom_12

Share this post


Link to post
Share on other sites

А как связана авторизация и dhcp с опцией82 ? У вас клиент не может руками адреса прописать? Тогда там какой-нить DAI нужен, чтобы не пускать его в Инет, пока он адресацию не получит. + Вам точно не нужно вешать какие-нить политики и т.п. ? Может какой-нить pppoe замутить?

Share this post


Link to post
Share on other sites

@Artom_12 полноценного IPoE в микротике нету, можно собрать из ходспота, но как писали выше если клиент ручками пропишет IP адрес и т.д. у него будет работать. 

 

Если очень хочется, как вариант скрипты + влан на клиента должно работать. Я когда рассматривал IPoE у себя отказался оставил PPPoE. 

Share this post


Link to post
Share on other sites

Чтобы клиент не прописал руками ип надо на интерфейсе поставить arp: reply-only а в dhcp-server установить галочку Add ARP For Leases

Option82 в радиус запросе от микротиковского dhcp сервера есть, аккаунтинга нет, т.е. трафик не считает.

Edited by vlin

Share this post


Link to post
Share on other sites

На микротике настраиваете DHCP сервер на работу с радиусом (никакой хотспот тут не нужен, один человек лет 10 назад про это написал, так все и продолжают продвигать подобные идеи), ставите как писали добавление ARP после выдачи адреса. Это спасет от установки адресов вручную. Но тут надо знать мак клиента, что бы выдать ему нужный адрес. Трафик можно считать через нетфлоу.

 

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

Share this post


Link to post
Share on other sites

Как так? Ведь vlan это устаревшие технологии.

Share this post


Link to post
Share on other sites
2 hours ago, Saab95 said:

На микротике настраиваете DHCP сервер на работу с радиусом (никакой хотспот тут не нужен, один человек лет 10 назад про это написал, так все и продолжают продвигать подобные идеи), ставите как писали добавление ARP после выдачи адреса. Это спасет от установки адресов вручную. Но тут надо знать мак клиента, что бы выдать ему нужный адрес. Трафик можно считать через нетфлоу.

 

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

есть статья про влан на абонента? хотелось бы прочесть

Edited by Artom_12

Share this post


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

есть статья про влан на абонента? хотелось бы прочесть

/interface vlan
add arp=reply-only interface=bridge_vlan name=vlan_2 vlan-id=2
add arp=reply-only interface=bridge_vlan name=vlan_3 vlan-id=3
/ip pool
add name=dhcp_pool_2 ranges=10.11.12.2
add name=dhcp_pool_3 ranges=10.11.12.3
/ip dhcp-server
add add-arp=yes address-pool=dhcp_pool_2 disabled=no interface=vlan_2 lease-time=5m name=dhcp_2
add add-arp=yes address-pool=dhcp_pool_3 disabled=no interface=vlan_3 lease-time=5m name=dhcp_3
/ip address
add address=10.11.12.1 interface=vlan_2 network=10.11.12.2
add address=10.11.12.1 interface=vlan_3 network=10.11.12.3
/ip dhcp-server network
add address=10.11.12.0/24 dns-server=172.17.0.2,172.17.0.3 gateway=10.11.12.1

/system scheduler
add name=vlans on-event=":foreach i in=[/interface vlan find] do={/interface vlan disable \$i}\r\
    \n\r\
    \n:foreach i in=[/interface vlan find] do={/interface vlan enable \$i}\r\
    \n" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-time=startup

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

Share this post


Link to post
Share on other sites

по этой схеме при 2000 абонентов надо иметь 2000 dhcp серверов?

Share this post


Link to post
Share on other sites

@Artom_12  всего сутки потребовалось, чтобы ты понял.

 

З.ы. а ещё, а ещё при перезагрузке ip адрес подымется раньше, чем интерфейс(влан) нужно ещё скрипт

Share this post


Link to post
Share on other sites
1 hour ago, pingz said:

@Artom_12  всего сутки потребовалось, чтобы ты понял.

 

З.ы. а ещё, а ещё при перезагрузке ip адрес подымется раньше, чем интерфейс(влан) нужно ещё скрипт

я надеялся что тут можно сделать чтото похожее на accel-ppp который через radius может получать данные:

ip абонента

ip свича с коротого должен работать абонент

порт с которого он должен работать

скорость

 

я и говорю - все прелести опции82...

 

Share this post


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

я и говорю - все прелести опции82...

И зачем все это? Вы предполагаете стягивать весь мусор с сети в центр? Развитие на будущие 5-10 лет как видите?

 

Куда уж проще схема влан на абонента - есть только номер влана и все, более никаких привязок в биллинге не требуется. В схеме с опцией там IP свича, порт, а если порт поменяли или там свич другой, или объединили 2 малопортовых коммутатора в один многопортовый. Прямо так интересно постоянно куда-то лазать и что-то править? Со временем перейдете на L3 транспорт, а вланы запустите поверх mpls и сеть можно масштабировать сколько угодно, без всяких там QinQ.

 

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

Share this post


Link to post
Share on other sites

@Artom_12  ок я понял спасибо за беседу. Оставляю вас Саббом.

Share this post


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

И зачем все это? Вы предполагаете стягивать весь мусор с сети в центр? Развитие на будущие 5-10 лет как видите?

 

Куда уж проще схема влан на абонента - есть только номер влана и все, более никаких привязок в биллинге не требуется. В схеме с опцией там IP свича, порт, а если порт поменяли или там свич другой, или объединили 2 малопортовых коммутатора в один многопортовый. Прямо так интересно постоянно куда-то лазать и что-то править? Со временем перейдете на L3 транспорт, а вланы запустите поверх mpls и сеть можно масштабировать сколько угодно, без всяких там QinQ.

 

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

Как он перейдет на mpls если у них микротик?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Зачем такие сложности, если можно терминировать влан на доступе? Тут конечно в дело вступает L3VPN, но его на микротике нет. Какой смысл растягивать L2 сегмент, чтобы клиент своей петлей положил вам пол сети? Я понимаю когда клиенту нужен L2VPN, тогда да. MPLS ядро это конечно прекрасно, можно навешивать разные услуги легко и надолго, но опять же, причем тут микротик?

Share this post


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

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

Крутая архитектура. Особенно, если в ней много микротиков.

Edited by TheUser

Share this post


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

Зачем такие сложности, если можно терминировать влан на доступе? Тут конечно в дело вступает L3VPN, но его на микротике нет. Какой смысл растягивать L2 сегмент, чтобы клиент своей петлей положил вам пол сети? Я понимаю когда клиенту нужен L2VPN, тогда да. MPLS ядро это конечно прекрасно, можно навешивать разные услуги легко и надолго, но опять же, причем тут микротик?

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

 

Микротик тут при том, что коммутатор с EoMPLS стоит от 150 тыс.р., а CCR1009 стоит 30 тыс.

Share this post


Link to post
Share on other sites
7 hours ago, Saab95 said:

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

я думал от этого спасает

loop detected

и

traffic segmentation

нет?)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
В 28.03.2019 в 16:40, Saab95 сказал:

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

 

Микротик тут при том, что коммутатор с EoMPLS стоит от 150 тыс.р., а CCR1009 стоит 30 тыс.

Давайте пруфы! Чтоб поднять pw нам потребуется.... ну например любой поддерживающий PE роутер и коммутатор, me 3750 должна уметь с 2х портов, да много разных вариаций и не за 150к. И никаких плясок, один раз сделать. Микротик сохо железо, ставить его в транспортную сеть на такие места, ну это как бы гиморой себе наживать. У нас они тоже есть, достаточно не мало, но для каждое своя задача и микротик далеко не швейцарский нож;)

Edited by Zerozed

Share this post


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

ну например любой поддерживающий PE роутер и коммутатор, me 3750 должна уметь с 2х портов, да много разных вариаций и не за 150к.

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

Share this post


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

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

Вы знаете, что Дэу нексия, которую до сих пор выпускают в Узбекистане это опель кадет, который выпускали в Германии лет 35 назад. Ну вы поняли аналогию... 

на скорости порта? Микротик? Вы это серьезно....

 

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