Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

(не поддерживается на данный момент, добавлено в конец ToDo) Засунуть WAN в EOIP (протянуть L2 WAN)

Доброго дня!
В новых прошивках появилась поддержка протокола Eoip, совместимого с
Микротик.

В данный момент есть Микротик, работающий в следующей конфигурации:

/interface bridge
add name=bridgeEOIP
/interface pptp-client
add connect-to=12.34.56.78 name=pptp-out1 password=PASS user=NAME
/interface eoip
add name=eoip remote-address=172.16.0.1 tunnel-id=101
/interface bridge port
add bridge=bridgeEOIP interface=ether1
add bridge=bridgeEOIP interface=eoip
/ip dhcp-client
add interface=bridgeEOIP

Суть конфига проста: на порту ether1 есть Vlan с интернетом, dhcp и телевидением по мультикаст.

С другого конца vpn нужно получить IP из этого vlan для доступа к внутренним сервисам и телевидению.

Для этого использован EoIP.

Можно ли подобное реализовать на snr-cpe-w4n? Либо другими протоколами, получить ip из этого vlan на удаленном сервере?

Дык снимите тэг до засовывания в EOIP. Я не силён в конфигах микротика, потому точнее не скажу. В остальном проблем не вижу. Какой транспорт будет внизу IPOE/PPTP/L2TP/PPPOE.

Но я бы не стал бы заниматься фигнёй и не стал бы тянуть L2 вовсе ради этого. Тем более гарантировать работу нормального такого бутерброда ещё и с мультикастом, нуууу...

А проблема решается проще, лучше и без бутербродов.

Ставим на обе стороны железки под Wive, настраиваем на первом UDPXY + L2TP server. На втором L2TP клиент == радуемся ТВ и интернету с первого.

Нет никакой нужны тянуть L2 ради IPTV, его можно просто завернуть в HTTP на первом девайсе. И даже без туннеля отдать вообще. Инет завернуть в L2TP.

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

Если микротик научился udpxy то можно и его оставить.

 

Трафик и так приходит нетегированный. Снимать тэг нигде не надо.

Использование UProxy отпадает - т.к. на том конце ТВ-приставки, которые должны получить IP из влана и отдать свой MAC напрямую порталу, для регистрации и работы. С надежностью проблем не возникало, все работает как часы в текущем варианте.

 

АПД: вопрос по сути - в повторении текущего конфига на НЕмикротик устройстве. Т.е. сможет ли cpe-w4n с одного WAN порта и забирать трафик и отдавать в туннель?

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

Я не дам гарантий что этот бутерброд будет работать. Учитывая, что реализация EOIP в wive это по сути реверс протокола и даже 100% совместимости гарантировать нельзя.

В теории проблем кроме возможных трабс с фрагментацией не вижу.

Wive EOIP поднимает через DGW куда он завёрнут туда и польётся трафик. Хоть через PPTP хоть через что-то ещё. Если задача всего лишь поднять туннель EOIP внутри PPTP туннеля - всё должно работать. Просто настраиваем PTPP затем EOIP в роже и всё.

Пробуйте. Потом расскажете. Теоретических препятствий нет.

Цитата: scinex от 17/09/2018, 14:54

АПД: вопрос по сути - в повторении текущего конфига на НЕмикротик устройстве. Т.е. сможет ли cpe-w4n с одного WAN порта и забирать трафик и отдавать в туннель?

Ничего не понял.

Какую сторону то надо повторить? Серверную?  Т.е. на нём надо это дело всё в кучу собрать и засунуть в pptp+eoip ?

PPTP куда до провайдера?

Опять таки нагородить можно, но боюсь у проца W4N пупок развяжется бутерброд из туннелей на сколько-то приемлемой скорости обслужить.

 

В данный момент пробую. VPN поднимается. Но после добавления порта eth-wan в созданный тоннель - отваливается и впн и инет =(

 

Повторить всмысле вот это:

/interface bridge
add name=bridgeEOIP
/interface pptp-client
add connect-to=12.34.56.78 name=pptp-out1 password=PASS user=NAME
/interface eoip
add name=eoip remote-address=172.16.0.1 tunnel-id=101
/interface bridge port
add bridge=bridgeEOIP interface=ether1
add bridge=bridgeEOIP interface=eoip
/ip dhcp-client
add interface=bridgeEOIP

Ессно если в лоб его с WAN в бридж засунуть финт ушами не пройдёт.

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

Цитата: scinex от 17/09/2018, 15:03

Повторить всмысле вот это:

Почему вы считаете, что каждый должен знать синтаксис конфигов микротик? Мне вот они не упали. =) Потому что оно там по факту делает по конфигу микротика сказать не берусь.

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

Ессно если в лоб его с WAN в бридж засунуть финт ушами не пройдёт.

На RouterOS данный финт работает без вопросов.

Буду благодарен, если получится!

Почему вы считаете, что каждый должен знать синтаксис конфигов микротик? Мне вот они не упали. =)

Да ладно вам ;) Он же прост и читабелен, как веник....

Я рад за роутерОС, ничего что архитектура совсем другая? И как минимум при попытке ввернуть это в Wive теряем аппаратный оффлоад от слова целиком.

Ну и странно бы если бы "изобретение" в виде EOIP не работало бы у "изобретателей". =) У нас несколько иные задачи. Но посмотрим что можно сделать, однако не в ближайшем будущем точно. В туду поставил, на полях записал.

ничего что архитектура совсем другая?

MediaTek MT7620N - архитектура MIPS + linux

RouterOS - суть есть linux + большинство железок от Микротика работает на MIPS

Опять же смысл вводить проприетарную технологию в свои прошивки - при несовместимости ее с "изобретателем" ;)

Цитата: scinex от 17/09/2018, 15:21

ничего что архитектура совсем другая?

MediaTek MT7620N - архитектура MIPS + linux

RouterOS - суть есть linux + большинство железок от Микротика работает на MIPS

Я о архитектуре оси. Ну и роутерос это крайне сильно поколеченный Linux. Годы потратили ребята на это. Ещё и полон своих суперизобретений, так же проприретарен до мозга костей. Так что не аргумент от слова вообще.

Опять же смысл вводить проприетарную технологию в свои прошивки - при несовместимости ее с "изобретателем" ;)

Она совместима ровно на столько сколько требовалось для решения задачи на тот момент. Расширять её поддержку для работы во всевозможных позах не планировалось. Повторять всякую проприретарь ради непонятно чего не вижу смысла. Для этого есть оригинальное изобретение.

 

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: