QWE Posted March 18, 2014 (edited) · Report post Абонентский микротик (АМ) цепляется к центральному микротику (ЦМ) по pptp. Поверх pptp соединения бегает EoIP туннель в туннель сбриджеваны интерфейсы с двух сторон. На pptp сервере выставлено значение Max MTU: 1150,Max MRU: 1150 . В настройках EoIP туннеля задано значение 1500. Делаю пинг с сервера linux со стороны ЦМ ping -s 1472 -M do (с установленным DF) через AМ на IP адрес абонента, т.е. трафик идет через туннель. Пакеты размером 1500 байт замечательно уходят и возвращаются. Вопрос как же тогда работает MTU для pptp туннеля? Или алгоритмы EoIP туннеля его в принципе не замечают? и перед отправкой пакета в pptp туннель пакет все равно фрагментируется? Edited March 18, 2014 by QWE Share this post Link to post Share on other sites
adron2 Posted March 18, 2014 · Report post вот вы и ответили на свой вопрос...(перед отправкой пакета в pptp туннель пакет все равно фрагментируется) Share this post Link to post Share on other sites
ilyak Posted March 26, 2014 · Report post Замечу еще, что гнать eoip через pptp как минимум странно, при наличии BCP. Share this post Link to post Share on other sites
QWE Posted March 26, 2014 · Report post Замечу еще, что гнать eoip через pptp как минимум странно, при наличии BCP. ЧТо то стразу не разобрался, но попробую. СУщность EOIP (канальный уровень сначала завернуть в IP, а затем обернуть в ppp пакеты) избыточна для данного случая согласен. Share this post Link to post Share on other sites
ilyak Posted March 26, 2014 · Report post http://wiki.mikrotik.com/wiki/Manual:BCP_bridging_(PPP_tunnel_bridging) Вместо PPTP может быть любой xPPP (SSTP, L2TP etc) И версия RouterOS должна быть или 5.26, или страше 6.8 Share this post Link to post Share on other sites
Saab95 Posted March 26, 2014 · Report post http://wiki.mikrotik...tunnel_bridging) Вместо PPTP может быть любой xPPP (SSTP, L2TP etc) И версия RouterOS должна быть или 5.26, или страше 6.8 А адрес для управления роутером где будет? Тоже в бридже окажется? Самая правильная схема это PPP + EoIP туннель поверх, т.к. позволяет передавать данные через любые каналы, даже те, где нарушается очередность следования пакетов. Share this post Link to post Share on other sites
QWE Posted March 26, 2014 (edited) · Report post http://wiki.mikrotik...tunnel_bridging) Вместо PPTP может быть любой xPPP (SSTP, L2TP etc) И версия RouterOS должна быть или 5.26, или страше 6.8 А адрес для управления роутером где будет? Тоже в бридже окажется? Самая правильная схема это PPP + EoIP туннель поверх, т.к. позволяет передавать данные через любые каналы, даже те, где нарушается очередность следования пакетов. Где нарушается очередность следования пакетов, по таким каналам TCP точно работать не будет, возникнет ошибка TCP - out of order, и произойдет повторная передача. А какая разница где окажется IP управления роутером? Все равно он доступен будет только после коннекта pptp клиента. Если IP будет доступен в бридже в котором ходит и абонентский трафик (в том же самом широковещательном домене) - ну и что? EOIP over PPTP я заметил странно себя ведет - возникает проблема с прохождением пакетов определенного размера, причем не на всех коннектах. т.е. есть такое что до 1471 байта (Ping c ключом -s) пакеты пролетают без проблем, 1472 байта ходят с потерями, более 1472 все снова латеает. Edited March 26, 2014 by QWE Share this post Link to post Share on other sites
ilyak Posted March 26, 2014 · Report post А адрес для управления роутером где будет? Тоже в бридже окажется? Так куда настроишь, там и окажется. Бриджей может быть больше одного )) Вообще на BCP MAC-телнет отрабатывает вполне хорошо. Самая правильная схема это PPP + EoIP туннель поверх, т.к. позволяет передавать данные через любые каналы, даже те, где нарушается очередность следования пакетов. Пофиксено в 6.8. Сегодня в Питере на MUM, Янис очень подробно про это говорил. Apple оказалась критична к последовательности PPTP пакетов, пришлось переписывать. Share this post Link to post Share on other sites
QWE Posted March 26, 2014 · Report post Самая правильная схема это PPP + EoIP туннель поверх, т.к. позволяет передавать данные через любые каналы, даже те, где нарушается очередность следования пакетов. Пофиксено в 6.8. Сегодня в Питере на MUM, Янис очень подробно про это говорил. Apple оказалась критична к последовательности PPTP пакетов, пришлось переписывать. А поподробнее можно, что за бага связанная с последовательностью PPTP пакетов? Share this post Link to post Share on other sites
ilyak Posted March 26, 2014 · Report post Бага связана была с тем, что из-за мультикоре на CCR, пришлось переписать PPP. В итоге из-за возможной обработки пакетов несколькими ядрами, пакеты на выходе могли быть не в той последовательности, что на входе. MS и Linux это переживали нормально, а Apple не пережил. Вообще много про CCR интересного рассказал. С точки зрения конфигурирования этой железки с учетом его особенностей. Share this post Link to post Share on other sites
QWE Posted March 27, 2014 · Report post Бага связана была с тем, что из-за мультикоре на CCR, пришлось переписать PPP. В итоге из-за возможной обработки пакетов несколькими ядрами, пакеты на выходе могли быть не в той последовательности, что на входе. MS и Linux это переживали нормально, а Apple не пережил. Вообще много про CCR интересного рассказал. С точки зрения конфигурирования этой железки с учетом его особенностей. получается что для 1100АН2 эта проблема не имеет отношения... Share this post Link to post Share on other sites
adron2 Posted March 27, 2014 · Report post http://wiki.mikrotik...tunnel_bridging) Вместо PPTP может быть любой xPPP (SSTP, L2TP etc) И версия RouterOS должна быть или 5.26, или страше 6.8 А адрес для управления роутером где будет? Тоже в бридже окажется? Самая правильная схема это PPP + EoIP туннель поверх, т.к. позволяет передавать данные через любые каналы, даже те, где нарушается очередность следования пакетов. И каким образом микротиковский PPP будет восстанавливать правильную последовательность пакетов? Он что уже как линуксовый умеет буфер по приему делать для этих целей? Share this post Link to post Share on other sites
ilyak Posted March 27, 2014 (edited) · Report post И каким образом микротиковский PPP будет восстанавливать правильную последовательность пакетов? Вот за кадром осталось. Но Янис говорил, что PPP ПОЛНОСТЬЮ переписан. От Linux там ничего не осталось. получается что для 1100АН2 эта проблема не имеет отношения... Может и иметь. 1100AHx2 тоже не одноядерный. Но тут мы уходим в дебри архитектуры, микрокода процессоров и прочей радости. Edited March 27, 2014 by ilyak Share this post Link to post Share on other sites
Saab95 Posted March 27, 2014 · Report post Где нарушается очередность следования пакетов, по таким каналам TCP точно работать не будет, возникнет ошибка TCP - out of order, и произойдет повторная передача. Если вы передадите отслеживание очередности протоколам более высокого уровня, а не микротику, то влиять ни на что она не будет. А какая разница где окажется IP управления роутером? Все равно он доступен будет только после коннекта pptp клиента. Если IP будет доступен в бридже в котором ходит и абонентский трафик (в том же самом широковещательном домене) - ну и что? Например вам нужно трафик абонентов передать по L2, в случае EoIP можно микротик полностью изолировать от него не производя никаких настроек, в случае BCP это сделать намного сложнее, кроме всего, если там будет какой-то флуд и т.п., то уже сразу после подключения, он пойдет в сеть, а EoIP можно и отключить. EOIP over PPTP я заметил странно себя ведет - возникает проблема с прохождением пакетов определенного размера, причем не на всех коннектах. т.е. есть такое что до 1471 байта (Ping c ключом -s) пакеты пролетают без проблем, 1472 байта ходят с потерями, более 1472 все снова латеает. Такое бывает когда у операторов в инете большие пакеты не проходят. На PPTP обычно ставят МТУ = 1300. Так куда настроишь, там и окажется. Бриджей может быть больше одного )) Вообще на BCP MAC-телнет отрабатывает вполне хорошо. И зачем такое? Например если вся сеть работает в OSPF, и тут где-то потребовалось пробросить L2 - просто кидаете EoIP поверх сети и готово. И каким образом микротиковский PPP будет восстанавливать правильную последовательность пакетов? Он что уже как линуксовый умеет буфер по приему делать для этих целей? Ему это и не надо. Например если сделать EoIP по внешним адресам, и там нарушена очередность пакетов - будут проблемы. Если сделать туннель PPP, а поверх него EoIP - никаких проблем не возникает. Если вы сделаете BCP, то будет такая же проблема, что и при EoIP через белые адреса напрямую. Share this post Link to post Share on other sites
QWE Posted March 27, 2014 · Report post И каким образом микротиковский PPP будет восстанавливать правильную последовательность пакетов? Вот за кадром осталось. Но Янис говорил, что PPP ПОЛНОСТЬЮ переписан. От Linux там ничего не осталось. получается что для 1100АН2 эта проблема не имеет отношения... Может и иметь. 1100AHx2 тоже не одноядерный. Но тут мы уходим в дебри архитектуры, микрокода процессоров и прочей радости. Поставил с двух сторон однопроцессорные железки, проблема с прохождением через EoIP over PPTP разного размера ping-ов остается. дело видимо не в числе ядер Share this post Link to post Share on other sites
adron2 Posted March 27, 2014 · Report post Например если сделать EoIP по внешним адресам, и там нарушена очередность пакетов - будут проблемы. Если сделать туннель PPP, а поверх него EoIP - никаких проблем не возникает. Если вы сделаете BCP, то будет такая же проблема, что и при EoIP через белые адреса напрямую. Почему при "туннель PPP, а поверх него EoIP" проблем не возникает? Кто в этой связке организует буфер по приему и восстанавливает очередность? Share this post Link to post Share on other sites
QWE Posted March 27, 2014 (edited) · Report post EOIP over PPTP я заметил странно себя ведет - возникает проблема с прохождением пакетов определенного размера, причем не на всех коннектах. Т.е. есть такое что до 1471 байта (Ping c ключом -s) пакеты пролетают без проблем, 1472 байта ходят с потерями, более 1472 все снова латеает. Такое бывает когда у операторов в инете большие пакеты не проходят. На PPTP обычно ставят МТУ = 1300. Перебровал значения MTU и MRU от 550 до 1300 пофигу, потери И самое хреновое непонятяно как это работает. танцы с бубном. поменял проверил - проблема есть Если есть проблема с прохождением больших пакетов у оператора, то теоретически установив MTU и MRU у PPTP сервера в минимальное значение проблема должна была решиться, но нифига. МОжет как то заваязано с MRRU ? Может порекомендуете версию софта для EoIP over PPTP? Или попробовать EoIP over L2TP? Edited March 27, 2014 by QWE Share this post Link to post Share on other sites
Saab95 Posted March 27, 2014 · Report post Надо туннель L2TP и поверх него EoIP, у меня работает на 5.26, 6rc14 и 6.10 без проблем. Share this post Link to post Share on other sites
QWE Posted March 27, 2014 · Report post а L2TP из за NAT нормально работает? что то в локалке нормлаьно коннектиться а из за НАТа нет. Share this post Link to post Share on other sites
Saab95 Posted March 27, 2014 · Report post а L2TP из за NAT нормально работает? что то в локалке нормлаьно коннектиться а из за НАТа нет. Если НАТ нормальный, то и работает нормально. Например через микротиковский НАТ проходит без проблем L2TP. Share this post Link to post Share on other sites
ilyak Posted March 28, 2014 · Report post Вообще не понимаю что все на EoIP молятся. Если с одной из сторон адрес динамический - ИМХО, логично поднимать xPPP (pptp, sstp, l2tp) и BCP Если адреса с обоих сторон выделенные - MPLS жрет существенно меньше ресурсов и имеет меньший оверхед. Share this post Link to post Share on other sites
fiskunt Posted September 16, 2015 · Report post Надо туннель L2TP и поверх него EoIP, у меня работает на 5.26, 6rc14 и 6.10 без проблем. Привет. У меня такая же схема работы пары точек с белыми адресами, но возникла одна проблемка. Скорость не поднимается выше 5 Мбит/с и чаще висит в районе 3 Мбит/с. BCP вообще ведет себя как злая теща (канал между CCR1016 и RB951) и похоже в данном случае проблема на стороне сервера (CCR1016). Короче страдаю ужасно уже месяц. Схема такая: CCR1016 в качестве VPN сервера и пул белых адресов к нему в придачу. Два клиента сосут белые адреса через VPN (сейчас это L2TP и EoIP). Один из них к тому же сидит через 4G свисток (но это не сказалось на разнице между ними). Share this post Link to post Share on other sites
nuclearcat Posted September 18, 2015 · Report post Почему при "туннель PPP, а поверх него EoIP" проблем не возникает? Кто в этой связке организует буфер по приему и восстанавливает очередность? Привычная технология Saab-а, если он не понял вопрос, предлагает поставить еще один микротик и запустить тоннель поверх тоннеля. Share this post Link to post Share on other sites
Saab95 Posted September 18, 2015 · Report post Если с одной из сторон адрес динамический - ИМХО, логично поднимать xPPP (pptp, sstp, l2tp) и BCP BCP нельзя использовать, т.к. данные идут в одном потоке с управлением, от этого все корни всех проблем. Если адреса с обоих сторон выделенные - MPLS жрет существенно меньше ресурсов и имеет меньший оверхед. MPLS имеет проблемы с MTU. Вообще не понимаю что все на EoIP молятся. Потому что он всегда работает и с ним нет никаких проблем. Привычная технология Saab-а, если он не понял вопрос, предлагает поставить еще один микротик и запустить тоннель поверх тоннеля. Так работает же? Share this post Link to post Share on other sites
fiskunt Posted September 19, 2015 · Report post Так работает же? Как через жопу, но работает Share this post Link to post Share on other sites
