[QWE]

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

[adron2]

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

[ilyak]

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

[QWE]

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

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

[ilyak]

http://wiki.mikrotik.com/wiki/Manual:BCP_bridging_(PPP_tunnel_bridging)

Вместо PPTP может быть любой xPPP (SSTP, L2TP etc)

И версия RouterOS должна быть или 5.26, или страше 6.8

[Saab95]

http://wiki.mikrotik...tunnel_bridging)

Вместо PPTP может быть любой xPPP (SSTP, L2TP etc)

И версия RouterOS должна быть или 5.26, или страше 6.8

 

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

 

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

[QWE]

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

[ilyak]

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

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

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

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

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

[QWE]

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

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

 

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

[ilyak]

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

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

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

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

[QWE]

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

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

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

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

 

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

[adron2]

http://wiki.mikrotik...tunnel_bridging)

Вместо PPTP может быть любой xPPP (SSTP, L2TP etc)

И версия RouterOS должна быть или 5.26, или страше 6.8

 

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

 

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

 

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

Он что уже как линуксовый умеет буфер по приему делать для этих целей?

[ilyak]

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

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

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

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

Edited March 27, 2014 by ilyak

[Saab95]

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

[QWE]

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

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

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

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

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

[adron2]

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

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

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

 

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

[QWE]

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

[Saab95]

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

[QWE]

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

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

[Saab95]

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

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

 

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

[ilyak]

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

 

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

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

[fiskunt]

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

Привет.

У меня такая же схема работы пары точек с белыми адресами, но возникла одна проблемка. Скорость не поднимается выше 5 Мбит/с и чаще висит в районе 3 Мбит/с. BCP вообще ведет себя как злая теща (канал между CCR1016 и RB951) и похоже в данном случае проблема на стороне сервера (CCR1016). Короче страдаю ужасно уже месяц.

Схема такая: CCR1016 в качестве VPN сервера и пул белых адресов к нему в придачу. Два клиента сосут белые адреса через VPN (сейчас это L2TP и EoIP). Один из них к тому же сидит через 4G свисток (но это не сказалось на разнице между ними).

[nuclearcat]

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

 

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

[Saab95]

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

[fiskunt]

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

 

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