Картуччо Опубликовано 10 апреля, 2014 · Жалоба Теоретический вопрос, не понятно в чём причина. Есть арендованная лямбда на 1 Гбит, есть L2VPN на такую же полосу. Задержки совершенно одинаковые. Потерь нет. При этом в малое количество TCP сессий лямбду удаётся прокачать намного сильнее без особых извращений. L2VPN же наоборот требует массу извращений вплоть до покупки сетевых компрессоров/акселераторов, иначе скорость передачи данных вообще никакая. В чём может быть причина такого поведения ? Понятно, что в случае VPN имеются свичи, маршрутизаторы, все они имеют буферы, но ведь задержки одинаковые в итоге. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 10 апреля, 2014 · Жалоба Какова задрежка между точками? Есть ли (хотя бы малые) потери в l2vpn? Если есть, то при большом размере окна эти потери мешают прокачать канал на малом кол-ве tcp-соединений Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Картуччо Опубликовано 10 апреля, 2014 · Жалоба 28 мс. Потерь вроде нет. В том то и дело, что L2VPN под одну задачу от 3 провайдеров брались. С одним было совсем хреново, с другими лучше, но до лямбды не дотягивают. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nnm Опубликовано 10 апреля, 2014 · Жалоба 28 мс. Это для больших пакетов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 11 апреля, 2014 · Жалоба Какое ограничение на MTU на лямбде и на l2vpn ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Картуччо Опубликовано 11 апреля, 2014 · Жалоба Используется 1500 в обоих случаях. 28 мс для 1500. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stranger2904 Опубликовано 11 апреля, 2014 · Жалоба Достаточно большой RTT, а можно в цифрах узнать сколько получается прокачать(лямбда, л2впн) и настройки iperf'a ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Картуччо Опубликовано 11 апреля, 2014 · Жалоба АЙперф сам по себе не интересен. Проблема в репликаторе базы данных. Более подробно не могу, так как конечными системами другие занимаются. И от них жалобы, что лямбда супер, а впн всегда плохо. Хотя тисипи крутили, потоков качки насколько возможно расширили, и даже брали на тест, а может и купили акселератор от ривербед. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 11 апреля, 2014 · Жалоба Как-то 28мс для лямбды - больно дофига. Или дальность соответствующая? Это ж тыщи км должны быть. Это реально так? И для репликаций БД мне кажется это много. Как и чем мерили задержку в обоих случаях? Я помню, коллега у меня решал проблему. Были жалобы от бизнеса, что скорость с площадки за многие тыщи км. 3кБ/сек, хотя канал ого-го, проблем не было, но задержка - да, 160мс. Но другие данные в сотни кБ и мБ/сек летали. Дамп трафика показал, что именно этот удаленный сервер почему-то ставил TCP окно в 6кБ, и после каждой порции пакетов клиента предлагал окно расширить. Их диалог занимал около секунды, где сервер отказывался, и очередные 3-4 пакета летели до следующих переговоров. Так что, было бы полезно снять дамп TCP сессии, в обоих случаях, и попробовать посмотреть, где и почему теряется скорость. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Картуччо Опубликовано 11 апреля, 2014 · Жалоба Дальность соответствует, 1500 км по прямой. Задержка измерялась запуском пингом с маршрутизаторов циско. Окно TCP конечно же тьюнили. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 11 апреля, 2014 (изменено) · Жалоба возможно что у магистрала у которого вы арендуете L2VPN просто приоритет на icmp стоит по максимуму а на остальной тип трафика нет. Вот и получается что icmp тесты показывают отличный результат а tcp тормозит! Я такое видел когда наш украинский UA-IX на экстримах был перегружен. Приходилось изобретать icmp туннели так как gre/udp/tcp было с потерями. icmp же при этом потерь не давал! Изменено 11 апреля, 2014 пользователем adron2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nnm Опубликовано 11 апреля, 2014 · Жалоба Может быть при использовании L2 VPN reordering происходит? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 11 апреля, 2014 · Жалоба Дальность соответствует, 1500 км по прямой. Задержка измерялась запуском пингом с маршрутизаторов циско. Окно TCP конечно же тьюнили. Без дампов траффика - это пустой разговор. посылайте данные в пакетах бОльшого размера и с бОльшим окном. А потом сравнивайте дампы траффика на входе и на выходе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 11 апреля, 2014 · Жалоба +1 к проверке реордеринга. Я даже знаю одного крупного оператора(точнее, его филиал), который делает per-packet балансировку mpls-трафика. И когда я пытался убедить человека, который это реализовал, что так делать не надо, мне не получилось это сделать ибо "всё работает". Даже доводы про мультикаст не сработали, потому что приставки у них умные и буферизируют и пересобирают пакетики в нужном порядке Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Картуччо Опубликовано 11 апреля, 2014 · Жалоба Если речь про Ростелеком, то да, ихнее L2VPN было хуже всех прочих вариантов :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 12 апреля, 2014 · Жалоба А если попросить L3VPN и самостоятельно паковать трафик в L2? С такой задачей справится любой микротик без проблем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Картуччо Опубликовано 12 апреля, 2014 · Жалоба :) Ну как же, тема без микротика это не тема. На днях ещё раз пустили трафик по L2VPN, вроде раскачалось до ожидаемых уровней, админы/субдшники пока сняли свои претензии к сети. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 12 апреля, 2014 · Жалоба А если попросить L3VPN и самостоятельно паковать трафик в L2? С такой задачей справится любой микротик без проблем. Ну и как микротик решит проблему с packet reordering? неужели хоть один из туннелей поддерживаемых микротиком научился делать буфер по приему чтобы восстановить последовательность пакетов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 12 апреля, 2014 · Жалоба Ну и как микротик решит проблему с packet reordering? неужели хоть один из туннелей поддерживаемых микротиком научился делать буфер по приему чтобы восстановить последовательность пакетов. Микротик как блютуз - с ним всё лучше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 12 апреля, 2014 · Жалоба Ну и как микротик решит проблему с packet reordering? неужели хоть один из туннелей поддерживаемых микротиком научился делать буфер по приему чтобы восстановить последовательность пакетов. У микротика можно устанавливать буфер любого типа и любого размера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 12 апреля, 2014 · Жалоба Saab95 Размер буфера это одно. А будет ли он пересобирать в нужном порядке? Проще говоре, есть ли в каком-либо тунеле микротика нумерация пакетов? (ну и используется ли она?) Если есть, то жду пруфа в виде ссылки на оф.документацию или дамп Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 12 апреля, 2014 · Жалоба Микротик умеет SSTP, это туннель по TCP, соответственно очередность пакетов нарушаться не будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 12 апреля, 2014 · Жалоба ага. вот только sstp со своим tcp все так же будет страдать от нарушения последовательности пакетов! еще варианты есть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 12 апреля, 2014 · Жалоба Микротик умеет SSTP, это туннель по TCP, соответственно очередность пакетов нарушаться не будет. tcp поверх кривого канала будет вносить задержки и тормоза. собственно автор топика сам гоняет tcp поверх l2vpn и добавление ещё одного tcp только ухудшит ситуацию. Если бы речь шла про какой-нибудь snmp трафик, которого мало, задержка не сильно критична, а потери и реордер крайне не желательны, то было бы смысл городить tcp-тунель Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nnm Опубликовано 13 апреля, 2014 (изменено) · Жалоба :) Ну как же, тема без микротика это не тема. На днях ещё раз пустили трафик по L2VPN, вроде раскачалось до ожидаемых уровней, админы/субдшники пока сняли свои претензии к сети. Скажите пожалуйста, а по какой причине Вы строите эту конструкцию поверх L2VPN/лямбды? Есть ведь L3 VPN. Или Вы как-то хитро инкапсулируете трафик и поверх этого L2 VPN/лямбды летит что-то хитрое отличное от IP? Изменено 13 апреля, 2014 пользователем nnm Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
