QWE Опубликовано 18 марта, 2014 (изменено) · Жалоба Абонентский микротик (АМ) цепляется к центральному микротику (ЦМ) по 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 туннель пакет все равно фрагментируется? Изменено 18 марта, 2014 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 18 марта, 2014 · Жалоба вот вы и ответили на свой вопрос...(перед отправкой пакета в pptp туннель пакет все равно фрагментируется) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ilyak Опубликовано 26 марта, 2014 · Жалоба Замечу еще, что гнать eoip через pptp как минимум странно, при наличии BCP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 26 марта, 2014 · Жалоба Замечу еще, что гнать eoip через pptp как минимум странно, при наличии BCP. ЧТо то стразу не разобрался, но попробую. СУщность EOIP (канальный уровень сначала завернуть в IP, а затем обернуть в ppp пакеты) избыточна для данного случая согласен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ilyak Опубликовано 26 марта, 2014 · Жалоба http://wiki.mikrotik.com/wiki/Manual:BCP_bridging_(PPP_tunnel_bridging) Вместо PPTP может быть любой xPPP (SSTP, L2TP etc) И версия RouterOS должна быть или 5.26, или страше 6.8 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 26 марта, 2014 · Жалоба http://wiki.mikrotik...tunnel_bridging) Вместо PPTP может быть любой xPPP (SSTP, L2TP etc) И версия RouterOS должна быть или 5.26, или страше 6.8 А адрес для управления роутером где будет? Тоже в бридже окажется? Самая правильная схема это PPP + EoIP туннель поверх, т.к. позволяет передавать данные через любые каналы, даже те, где нарушается очередность следования пакетов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 26 марта, 2014 (изменено) · Жалоба 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 все снова латеает. Изменено 26 марта, 2014 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ilyak Опубликовано 26 марта, 2014 · Жалоба А адрес для управления роутером где будет? Тоже в бридже окажется? Так куда настроишь, там и окажется. Бриджей может быть больше одного )) Вообще на BCP MAC-телнет отрабатывает вполне хорошо. Самая правильная схема это PPP + EoIP туннель поверх, т.к. позволяет передавать данные через любые каналы, даже те, где нарушается очередность следования пакетов. Пофиксено в 6.8. Сегодня в Питере на MUM, Янис очень подробно про это говорил. Apple оказалась критична к последовательности PPTP пакетов, пришлось переписывать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 26 марта, 2014 · Жалоба Самая правильная схема это PPP + EoIP туннель поверх, т.к. позволяет передавать данные через любые каналы, даже те, где нарушается очередность следования пакетов. Пофиксено в 6.8. Сегодня в Питере на MUM, Янис очень подробно про это говорил. Apple оказалась критична к последовательности PPTP пакетов, пришлось переписывать. А поподробнее можно, что за бага связанная с последовательностью PPTP пакетов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ilyak Опубликовано 26 марта, 2014 · Жалоба Бага связана была с тем, что из-за мультикоре на CCR, пришлось переписать PPP. В итоге из-за возможной обработки пакетов несколькими ядрами, пакеты на выходе могли быть не в той последовательности, что на входе. MS и Linux это переживали нормально, а Apple не пережил. Вообще много про CCR интересного рассказал. С точки зрения конфигурирования этой железки с учетом его особенностей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 27 марта, 2014 · Жалоба Бага связана была с тем, что из-за мультикоре на CCR, пришлось переписать PPP. В итоге из-за возможной обработки пакетов несколькими ядрами, пакеты на выходе могли быть не в той последовательности, что на входе. MS и Linux это переживали нормально, а Apple не пережил. Вообще много про CCR интересного рассказал. С точки зрения конфигурирования этой железки с учетом его особенностей. получается что для 1100АН2 эта проблема не имеет отношения... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 27 марта, 2014 · Жалоба http://wiki.mikrotik...tunnel_bridging) Вместо PPTP может быть любой xPPP (SSTP, L2TP etc) И версия RouterOS должна быть или 5.26, или страше 6.8 А адрес для управления роутером где будет? Тоже в бридже окажется? Самая правильная схема это PPP + EoIP туннель поверх, т.к. позволяет передавать данные через любые каналы, даже те, где нарушается очередность следования пакетов. И каким образом микротиковский PPP будет восстанавливать правильную последовательность пакетов? Он что уже как линуксовый умеет буфер по приему делать для этих целей? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ilyak Опубликовано 27 марта, 2014 (изменено) · Жалоба И каким образом микротиковский PPP будет восстанавливать правильную последовательность пакетов? Вот за кадром осталось. Но Янис говорил, что PPP ПОЛНОСТЬЮ переписан. От Linux там ничего не осталось. получается что для 1100АН2 эта проблема не имеет отношения... Может и иметь. 1100AHx2 тоже не одноядерный. Но тут мы уходим в дебри архитектуры, микрокода процессоров и прочей радости. Изменено 27 марта, 2014 пользователем ilyak Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 27 марта, 2014 · Жалоба Где нарушается очередность следования пакетов, по таким каналам 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 через белые адреса напрямую. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 27 марта, 2014 · Жалоба И каким образом микротиковский PPP будет восстанавливать правильную последовательность пакетов? Вот за кадром осталось. Но Янис говорил, что PPP ПОЛНОСТЬЮ переписан. От Linux там ничего не осталось. получается что для 1100АН2 эта проблема не имеет отношения... Может и иметь. 1100AHx2 тоже не одноядерный. Но тут мы уходим в дебри архитектуры, микрокода процессоров и прочей радости. Поставил с двух сторон однопроцессорные железки, проблема с прохождением через EoIP over PPTP разного размера ping-ов остается. дело видимо не в числе ядер Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 27 марта, 2014 · Жалоба Например если сделать EoIP по внешним адресам, и там нарушена очередность пакетов - будут проблемы. Если сделать туннель PPP, а поверх него EoIP - никаких проблем не возникает. Если вы сделаете BCP, то будет такая же проблема, что и при EoIP через белые адреса напрямую. Почему при "туннель PPP, а поверх него EoIP" проблем не возникает? Кто в этой связке организует буфер по приему и восстанавливает очередность? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 27 марта, 2014 (изменено) · Жалоба 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? Изменено 27 марта, 2014 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 27 марта, 2014 · Жалоба Надо туннель L2TP и поверх него EoIP, у меня работает на 5.26, 6rc14 и 6.10 без проблем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 27 марта, 2014 · Жалоба а L2TP из за NAT нормально работает? что то в локалке нормлаьно коннектиться а из за НАТа нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 27 марта, 2014 · Жалоба а L2TP из за NAT нормально работает? что то в локалке нормлаьно коннектиться а из за НАТа нет. Если НАТ нормальный, то и работает нормально. Например через микротиковский НАТ проходит без проблем L2TP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ilyak Опубликовано 28 марта, 2014 · Жалоба Вообще не понимаю что все на EoIP молятся. Если с одной из сторон адрес динамический - ИМХО, логично поднимать xPPP (pptp, sstp, l2tp) и BCP Если адреса с обоих сторон выделенные - MPLS жрет существенно меньше ресурсов и имеет меньший оверхед. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fiskunt Опубликовано 16 сентября, 2015 · Жалоба Надо туннель L2TP и поверх него EoIP, у меня работает на 5.26, 6rc14 и 6.10 без проблем. Привет. У меня такая же схема работы пары точек с белыми адресами, но возникла одна проблемка. Скорость не поднимается выше 5 Мбит/с и чаще висит в районе 3 Мбит/с. BCP вообще ведет себя как злая теща (канал между CCR1016 и RB951) и похоже в данном случае проблема на стороне сервера (CCR1016). Короче страдаю ужасно уже месяц. Схема такая: CCR1016 в качестве VPN сервера и пул белых адресов к нему в придачу. Два клиента сосут белые адреса через VPN (сейчас это L2TP и EoIP). Один из них к тому же сидит через 4G свисток (но это не сказалось на разнице между ними). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 18 сентября, 2015 · Жалоба Почему при "туннель PPP, а поверх него EoIP" проблем не возникает? Кто в этой связке организует буфер по приему и восстанавливает очередность? Привычная технология Saab-а, если он не понял вопрос, предлагает поставить еще один микротик и запустить тоннель поверх тоннеля. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 18 сентября, 2015 · Жалоба Если с одной из сторон адрес динамический - ИМХО, логично поднимать xPPP (pptp, sstp, l2tp) и BCP BCP нельзя использовать, т.к. данные идут в одном потоке с управлением, от этого все корни всех проблем. Если адреса с обоих сторон выделенные - MPLS жрет существенно меньше ресурсов и имеет меньший оверхед. MPLS имеет проблемы с MTU. Вообще не понимаю что все на EoIP молятся. Потому что он всегда работает и с ним нет никаких проблем. Привычная технология Saab-а, если он не понял вопрос, предлагает поставить еще один микротик и запустить тоннель поверх тоннеля. Так работает же? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fiskunt Опубликовано 19 сентября, 2015 · Жалоба Так работает же? Как через жопу, но работает Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...