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

Микротику пофиг на бит DF при отправке пакета в pptp туннель? микротик DF

Абонентский микротик (АМ) цепляется к центральному микротику (ЦМ) по 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 by QWE

Share this post


Link to post
Share on other sites

вот вы и ответили на свой вопрос...(перед отправкой пакета в pptp туннель пакет все равно фрагментируется)

Share this post


Link to post
Share on other sites

Замечу еще, что гнать eoip через pptp как минимум странно, при наличии BCP.

Share this post


Link to post
Share on other sites

Замечу еще, что гнать eoip через pptp как минимум странно, при наличии BCP.

ЧТо то стразу не разобрался, но попробую. СУщность EOIP (канальный уровень сначала завернуть в IP, а затем обернуть в ppp пакеты) избыточна для данного случая согласен.

Share this post


Link to post
Share on other sites

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

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 by QWE

Share this post


Link to post
Share on other sites

А адрес для управления роутером где будет? Тоже в бридже окажется?

Так куда настроишь, там и окажется. Бриджей может быть больше одного ))

Вообще на BCP MAC-телнет отрабатывает вполне хорошо.

Самая правильная схема это PPP + EoIP туннель поверх, т.к. позволяет передавать данные через любые каналы, даже те, где нарушается очередность следования пакетов.

Пофиксено в 6.8. Сегодня в Питере на MUM, Янис очень подробно про это говорил. Apple оказалась критична к последовательности PPTP пакетов, пришлось переписывать.

Share this post


Link to post
Share on other sites

Самая правильная схема это PPP + EoIP туннель поверх, т.к. позволяет передавать данные через любые каналы, даже те, где нарушается очередность следования пакетов.

Пофиксено в 6.8. Сегодня в Питере на MUM, Янис очень подробно про это говорил. Apple оказалась критична к последовательности PPTP пакетов, пришлось переписывать.

 

А поподробнее можно, что за бага связанная с последовательностью PPTP пакетов?

Share this post


Link to post
Share on other sites

Бага связана была с тем, что из-за мультикоре на CCR, пришлось переписать PPP.

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

MS и Linux это переживали нормально, а Apple не пережил.

Вообще много про CCR интересного рассказал. С точки зрения конфигурирования этой железки с учетом его особенностей.

Share this post


Link to post
Share on other sites

Бага связана была с тем, что из-за мультикоре на CCR, пришлось переписать PPP.

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

MS и Linux это переживали нормально, а Apple не пережил.

Вообще много про CCR интересного рассказал. С точки зрения конфигурирования этой железки с учетом его особенностей.

 

получается что для 1100АН2 эта проблема не имеет отношения...

Share this post


Link to post
Share on other sites

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

И каким образом микротиковский PPP будет восстанавливать правильную последовательность пакетов?

Вот за кадром осталось. Но Янис говорил, что PPP ПОЛНОСТЬЮ переписан. От Linux там ничего не осталось.

получается что для 1100АН2 эта проблема не имеет отношения...

Может и иметь. 1100AHx2 тоже не одноядерный. Но тут мы уходим в дебри архитектуры, микрокода процессоров и прочей радости.

Edited by ilyak

Share this post


Link to post
Share on other sites

Где нарушается очередность следования пакетов, по таким каналам 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

И каким образом микротиковский PPP будет восстанавливать правильную последовательность пакетов?

Вот за кадром осталось. Но Янис говорил, что PPP ПОЛНОСТЬЮ переписан. От Linux там ничего не осталось.

получается что для 1100АН2 эта проблема не имеет отношения...

Может и иметь. 1100AHx2 тоже не одноядерный. Но тут мы уходим в дебри архитектуры, микрокода процессоров и прочей радости.

Поставил с двух сторон однопроцессорные железки, проблема с прохождением через EoIP over PPTP разного размера ping-ов остается. дело видимо не в числе ядер

Share this post


Link to post
Share on other sites

Например если сделать EoIP по внешним адресам, и там нарушена очередность пакетов - будут проблемы.

Если сделать туннель PPP, а поверх него EoIP - никаких проблем не возникает.

Если вы сделаете BCP, то будет такая же проблема, что и при EoIP через белые адреса напрямую.

 

Почему при "туннель PPP, а поверх него EoIP" проблем не возникает? Кто в этой связке организует буфер по приему и восстанавливает очередность?

Share this post


Link to post
Share on other sites

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 by QWE

Share this post


Link to post
Share on other sites

Надо туннель L2TP и поверх него EoIP, у меня работает на 5.26, 6rc14 и 6.10 без проблем.

Share this post


Link to post
Share on other sites

а L2TP из за NAT нормально работает?

что то в локалке нормлаьно коннектиться а из за НАТа нет.

Share this post


Link to post
Share on other sites

а L2TP из за NAT нормально работает?

что то в локалке нормлаьно коннектиться а из за НАТа нет.

 

Если НАТ нормальный, то и работает нормально. Например через микротиковский НАТ проходит без проблем L2TP.

Share this post


Link to post
Share on other sites

Вообще не понимаю что все на EoIP молятся.

 

Если с одной из сторон адрес динамический - ИМХО, логично поднимать xPPP (pptp, sstp, l2tp) и BCP

Если адреса с обоих сторон выделенные - MPLS жрет существенно меньше ресурсов и имеет меньший оверхед.

Share this post


Link to post
Share on other sites

Надо туннель 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

Почему при "туннель PPP, а поверх него EoIP" проблем не возникает? Кто в этой связке организует буфер по приему и восстанавливает очередность?

 

Привычная технология Saab-а, если он не понял вопрос, предлагает поставить еще один микротик и запустить тоннель поверх тоннеля.

Share this post


Link to post
Share on other sites

Если с одной из сторон адрес динамический - ИМХО, логично поднимать xPPP (pptp, sstp, l2tp) и BCP

 

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

 

Если адреса с обоих сторон выделенные - MPLS жрет существенно меньше ресурсов и имеет меньший оверхед.

 

MPLS имеет проблемы с MTU.

 

Вообще не понимаю что все на EoIP молятся.

 

Потому что он всегда работает и с ним нет никаких проблем.

 

Привычная технология Saab-а, если он не понял вопрос, предлагает поставить еще один микротик и запустить тоннель поверх тоннеля.

 

Так работает же?

Share this post


Link to post
Share on other sites

Так работает же?

 

Как через жопу, но работает

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
Sign in to follow this