(не поддерживается на данный момент, добавлено в конец ToDo) Засунуть WAN в EOIP (протянуть L2 WAN)
Цитата: scinex от 17/09/2018, 14:40Доброго дня!
В новых прошивках появилась поддержка протокола 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, совместимого с
Микротик.
В данный момент есть Микротик, работающий в следующей конфигурации:
/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 на удаленном сервере?
Цитата: sfstudio от 17/09/2018, 14:49Дык снимите тэг до засовывания в EOIP. Я не силён в конфигах микротика, потому точнее не скажу. В остальном проблем не вижу. Какой транспорт будет внизу IPOE/PPTP/L2TP/PPPOE.
Но я бы не стал бы заниматься фигнёй и не стал бы тянуть L2 вовсе ради этого. Тем более гарантировать работу нормального такого бутерброда ещё и с мультикастом, нуууу...
А проблема решается проще, лучше и без бутербродов.
Ставим на обе стороны железки под Wive, настраиваем на первом UDPXY + L2TP server. На втором L2TP клиент == радуемся ТВ и интернету с первого.
Нет никакой нужны тянуть L2 ради IPTV, его можно просто завернуть в HTTP на первом девайсе. И даже без туннеля отдать вообще. Инет завернуть в L2TP.
Это будет гораздо быстрее, правильнее, надёжнее и не будет иметь проблем с фрагментацией и прочим, плюс заворачивание в HTTP попутно решит проблемы рассыпаний при заторах между конечными точками т.к. у клиентов появиться возможность перезапросить потерянный кусок из буфера.
Если микротик научился udpxy то можно и его оставить.
Дык снимите тэг до засовывания в EOIP. Я не силён в конфигах микротика, потому точнее не скажу. В остальном проблем не вижу. Какой транспорт будет внизу IPOE/PPTP/L2TP/PPPOE.
Но я бы не стал бы заниматься фигнёй и не стал бы тянуть L2 вовсе ради этого. Тем более гарантировать работу нормального такого бутерброда ещё и с мультикастом, нуууу...
А проблема решается проще, лучше и без бутербродов.
Ставим на обе стороны железки под Wive, настраиваем на первом UDPXY + L2TP server. На втором L2TP клиент == радуемся ТВ и интернету с первого.
Нет никакой нужны тянуть L2 ради IPTV, его можно просто завернуть в HTTP на первом девайсе. И даже без туннеля отдать вообще. Инет завернуть в L2TP.
Это будет гораздо быстрее, правильнее, надёжнее и не будет иметь проблем с фрагментацией и прочим, плюс заворачивание в HTTP попутно решит проблемы рассыпаний при заторах между конечными точками т.к. у клиентов появиться возможность перезапросить потерянный кусок из буфера.
Если микротик научился udpxy то можно и его оставить.
Цитата: scinex от 17/09/2018, 14:54Трафик и так приходит нетегированный. Снимать тэг нигде не надо.
Использование UProxy отпадает - т.к. на том конце ТВ-приставки, которые должны получить IP из влана и отдать свой MAC напрямую порталу, для регистрации и работы. С надежностью проблем не возникало, все работает как часы в текущем варианте.
АПД: вопрос по сути - в повторении текущего конфига на НЕмикротик устройстве. Т.е. сможет ли cpe-w4n с одного WAN порта и забирать трафик и отдавать в туннель?
Трафик и так приходит нетегированный. Снимать тэг нигде не надо.
Использование UProxy отпадает - т.к. на том конце ТВ-приставки, которые должны получить IP из влана и отдать свой MAC напрямую порталу, для регистрации и работы. С надежностью проблем не возникало, все работает как часы в текущем варианте.
АПД: вопрос по сути - в повторении текущего конфига на НЕмикротик устройстве. Т.е. сможет ли cpe-w4n с одного WAN порта и забирать трафик и отдавать в туннель?
Цитата: sfstudio от 17/09/2018, 15:00Ну берите железку и пробуйте. Не получиться - приходите попробуем разобраться почему не получилось.
Я не дам гарантий что этот бутерброд будет работать. Учитывая, что реализация EOIP в wive это по сути реверс протокола и даже 100% совместимости гарантировать нельзя.
В теории проблем кроме возможных трабс с фрагментацией не вижу.
Wive EOIP поднимает через DGW куда он завёрнут туда и польётся трафик. Хоть через PPTP хоть через что-то ещё. Если задача всего лишь поднять туннель EOIP внутри PPTP туннеля - всё должно работать. Просто настраиваем PTPP затем EOIP в роже и всё.
Пробуйте. Потом расскажете. Теоретических препятствий нет.
Ну берите железку и пробуйте. Не получиться - приходите попробуем разобраться почему не получилось.
Я не дам гарантий что этот бутерброд будет работать. Учитывая, что реализация EOIP в wive это по сути реверс протокола и даже 100% совместимости гарантировать нельзя.
В теории проблем кроме возможных трабс с фрагментацией не вижу.
Wive EOIP поднимает через DGW куда он завёрнут туда и польётся трафик. Хоть через PPTP хоть через что-то ещё. Если задача всего лишь поднять туннель EOIP внутри PPTP туннеля - всё должно работать. Просто настраиваем PTPP затем EOIP в роже и всё.
Пробуйте. Потом расскажете. Теоретических препятствий нет.
Цитата: sfstudio от 17/09/2018, 15:02Цитата: scinex от 17/09/2018, 14:54АПД: вопрос по сути - в повторении текущего конфига на НЕмикротик устройстве. Т.е. сможет ли cpe-w4n с одного WAN порта и забирать трафик и отдавать в туннель?
Ничего не понял.
Какую сторону то надо повторить? Серверную? Т.е. на нём надо это дело всё в кучу собрать и засунуть в pptp+eoip ?
PPTP куда до провайдера?
Опять таки нагородить можно, но боюсь у проца W4N пупок развяжется бутерброд из туннелей на сколько-то приемлемой скорости обслужить.
Цитата: scinex от 17/09/2018, 14:54АПД: вопрос по сути - в повторении текущего конфига на НЕмикротик устройстве. Т.е. сможет ли cpe-w4n с одного WAN порта и забирать трафик и отдавать в туннель?
Ничего не понял.
Какую сторону то надо повторить? Серверную? Т.е. на нём надо это дело всё в кучу собрать и засунуть в pptp+eoip ?
PPTP куда до провайдера?
Опять таки нагородить можно, но боюсь у проца W4N пупок развяжется бутерброд из туннелей на сколько-то приемлемой скорости обслужить.
Цитата: scinex от 17/09/2018, 15:03В данный момент пробую. 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
В данный момент пробую. 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
Цитата: sfstudio от 17/09/2018, 15:07Ессно если в лоб его с WAN в бридж засунуть финт ушами не пройдёт.
Такая конфигурация в данный момент точно работать не будет. Я посмотрю на досуге, можно ли будет малой кровью добавить такой вариант, но скорее нет чем да.
Ессно если в лоб его с WAN в бридж засунуть финт ушами не пройдёт.
Такая конфигурация в данный момент точно работать не будет. Я посмотрю на досуге, можно ли будет малой кровью добавить такой вариант, но скорее нет чем да.
Цитата: sfstudio от 17/09/2018, 15:09Цитата: scinex от 17/09/2018, 15:03Повторить всмысле вот это:
Почему вы считаете, что каждый должен знать синтаксис конфигов микротик? Мне вот они не упали. =) Потому что оно там по факту делает по конфигу микротика сказать не берусь.
Для этого есть человеческий язык, которым можно описать и клиентскую и серверную стороны.
Цитата: scinex от 17/09/2018, 15:03Повторить всмысле вот это:
Почему вы считаете, что каждый должен знать синтаксис конфигов микротик? Мне вот они не упали. =) Потому что оно там по факту делает по конфигу микротика сказать не берусь.
Для этого есть человеческий язык, которым можно описать и клиентскую и серверную стороны.
Цитата: scinex от 17/09/2018, 15:09Ессно если в лоб его с WAN в бридж засунуть финт ушами не пройдёт.
На RouterOS данный финт работает без вопросов.
Буду благодарен, если получится!
Почему вы считаете, что каждый должен знать синтаксис конфигов микротик? Мне вот они не упали. =)
Да ладно вам ;) Он же прост и читабелен, как веник....
Ессно если в лоб его с WAN в бридж засунуть финт ушами не пройдёт.
На RouterOS данный финт работает без вопросов.
Буду благодарен, если получится!
Почему вы считаете, что каждый должен знать синтаксис конфигов микротик? Мне вот они не упали. =)
Да ладно вам ;) Он же прост и читабелен, как веник....
Цитата: sfstudio от 17/09/2018, 15:12Я рад за роутерОС, ничего что архитектура совсем другая? И как минимум при попытке ввернуть это в Wive теряем аппаратный оффлоад от слова целиком.
Ну и странно бы если бы "изобретение" в виде EOIP не работало бы у "изобретателей". =) У нас несколько иные задачи. Но посмотрим что можно сделать, однако не в ближайшем будущем точно. В туду поставил, на полях записал.
Я рад за роутерОС, ничего что архитектура совсем другая? И как минимум при попытке ввернуть это в Wive теряем аппаратный оффлоад от слова целиком.
Ну и странно бы если бы "изобретение" в виде EOIP не работало бы у "изобретателей". =) У нас несколько иные задачи. Но посмотрим что можно сделать, однако не в ближайшем будущем точно. В туду поставил, на полях записал.
Цитата: scinex от 17/09/2018, 15:21ничего что архитектура совсем другая?
MediaTek MT7620N - архитектура MIPS + linux
RouterOS - суть есть linux + большинство железок от Микротика работает на MIPS
Опять же смысл вводить проприетарную технологию в свои прошивки - при несовместимости ее с "изобретателем" ;)
ничего что архитектура совсем другая?
MediaTek MT7620N - архитектура MIPS + linux
RouterOS - суть есть linux + большинство железок от Микротика работает на MIPS
Опять же смысл вводить проприетарную технологию в свои прошивки - при несовместимости ее с "изобретателем" ;)
Цитата: sfstudio от 17/09/2018, 15:25Цитата: scinex от 17/09/2018, 15:21ничего что архитектура совсем другая?
MediaTek MT7620N - архитектура MIPS + linux
RouterOS - суть есть linux + большинство железок от Микротика работает на MIPS
Я о архитектуре оси. Ну и роутерос это крайне сильно поколеченный Linux. Годы потратили ребята на это. Ещё и полон своих суперизобретений, так же проприретарен до мозга костей. Так что не аргумент от слова вообще.
Опять же смысл вводить проприетарную технологию в свои прошивки - при несовместимости ее с "изобретателем" ;)
Она совместима ровно на столько сколько требовалось для решения задачи на тот момент. Расширять её поддержку для работы во всевозможных позах не планировалось. Повторять всякую проприретарь ради непонятно чего не вижу смысла. Для этого есть оригинальное изобретение.
Цитата: scinex от 17/09/2018, 15:21ничего что архитектура совсем другая?
MediaTek MT7620N - архитектура MIPS + linux
RouterOS - суть есть linux + большинство железок от Микротика работает на MIPS
Я о архитектуре оси. Ну и роутерос это крайне сильно поколеченный Linux. Годы потратили ребята на это. Ещё и полон своих суперизобретений, так же проприретарен до мозга костей. Так что не аргумент от слова вообще.
Опять же смысл вводить проприетарную технологию в свои прошивки - при несовместимости ее с "изобретателем" ;)
Она совместима ровно на столько сколько требовалось для решения задачи на тот момент. Расширять её поддержку для работы во всевозможных позах не планировалось. Повторять всякую проприретарь ради непонятно чего не вижу смысла. Для этого есть оригинальное изобретение.
