Картуччо Posted April 10, 2014 Posted April 10, 2014 Теоретический вопрос, не понятно в чём причина. Есть арендованная лямбда на 1 Гбит, есть L2VPN на такую же полосу. Задержки совершенно одинаковые. Потерь нет. При этом в малое количество TCP сессий лямбду удаётся прокачать намного сильнее без особых извращений. L2VPN же наоборот требует массу извращений вплоть до покупки сетевых компрессоров/акселераторов, иначе скорость передачи данных вообще никакая. В чём может быть причина такого поведения ? Понятно, что в случае VPN имеются свичи, маршрутизаторы, все они имеют буферы, но ведь задержки одинаковые в итоге. Вставить ник Quote
s.lobanov Posted April 10, 2014 Posted April 10, 2014 Какова задрежка между точками? Есть ли (хотя бы малые) потери в l2vpn? Если есть, то при большом размере окна эти потери мешают прокачать канал на малом кол-ве tcp-соединений Вставить ник Quote
Картуччо Posted April 10, 2014 Author Posted April 10, 2014 28 мс. Потерь вроде нет. В том то и дело, что L2VPN под одну задачу от 3 провайдеров брались. С одним было совсем хреново, с другими лучше, но до лямбды не дотягивают. Вставить ник Quote
orlik Posted April 11, 2014 Posted April 11, 2014 Какое ограничение на MTU на лямбде и на l2vpn ? Вставить ник Quote
Картуччо Posted April 11, 2014 Author Posted April 11, 2014 Используется 1500 в обоих случаях. 28 мс для 1500. Вставить ник Quote
stranger2904 Posted April 11, 2014 Posted April 11, 2014 Достаточно большой RTT, а можно в цифрах узнать сколько получается прокачать(лямбда, л2впн) и настройки iperf'a ? Вставить ник Quote
Картуччо Posted April 11, 2014 Author Posted April 11, 2014 АЙперф сам по себе не интересен. Проблема в репликаторе базы данных. Более подробно не могу, так как конечными системами другие занимаются. И от них жалобы, что лямбда супер, а впн всегда плохо. Хотя тисипи крутили, потоков качки насколько возможно расширили, и даже брали на тест, а может и купили акселератор от ривербед. Вставить ник Quote
SergeiK Posted April 11, 2014 Posted April 11, 2014 Как-то 28мс для лямбды - больно дофига. Или дальность соответствующая? Это ж тыщи км должны быть. Это реально так? И для репликаций БД мне кажется это много. Как и чем мерили задержку в обоих случаях? Я помню, коллега у меня решал проблему. Были жалобы от бизнеса, что скорость с площадки за многие тыщи км. 3кБ/сек, хотя канал ого-го, проблем не было, но задержка - да, 160мс. Но другие данные в сотни кБ и мБ/сек летали. Дамп трафика показал, что именно этот удаленный сервер почему-то ставил TCP окно в 6кБ, и после каждой порции пакетов клиента предлагал окно расширить. Их диалог занимал около секунды, где сервер отказывался, и очередные 3-4 пакета летели до следующих переговоров. Так что, было бы полезно снять дамп TCP сессии, в обоих случаях, и попробовать посмотреть, где и почему теряется скорость. Вставить ник Quote
Картуччо Posted April 11, 2014 Author Posted April 11, 2014 Дальность соответствует, 1500 км по прямой. Задержка измерялась запуском пингом с маршрутизаторов циско. Окно TCP конечно же тьюнили. Вставить ник Quote
adron2 Posted April 11, 2014 Posted April 11, 2014 (edited) возможно что у магистрала у которого вы арендуете L2VPN просто приоритет на icmp стоит по максимуму а на остальной тип трафика нет. Вот и получается что icmp тесты показывают отличный результат а tcp тормозит! Я такое видел когда наш украинский UA-IX на экстримах был перегружен. Приходилось изобретать icmp туннели так как gre/udp/tcp было с потерями. icmp же при этом потерь не давал! Edited April 11, 2014 by adron2 Вставить ник Quote
nnm Posted April 11, 2014 Posted April 11, 2014 Может быть при использовании L2 VPN reordering происходит? Вставить ник Quote
vlad11 Posted April 11, 2014 Posted April 11, 2014 Дальность соответствует, 1500 км по прямой. Задержка измерялась запуском пингом с маршрутизаторов циско. Окно TCP конечно же тьюнили. Без дампов траффика - это пустой разговор. посылайте данные в пакетах бОльшого размера и с бОльшим окном. А потом сравнивайте дампы траффика на входе и на выходе. Вставить ник Quote
s.lobanov Posted April 11, 2014 Posted April 11, 2014 +1 к проверке реордеринга. Я даже знаю одного крупного оператора(точнее, его филиал), который делает per-packet балансировку mpls-трафика. И когда я пытался убедить человека, который это реализовал, что так делать не надо, мне не получилось это сделать ибо "всё работает". Даже доводы про мультикаст не сработали, потому что приставки у них умные и буферизируют и пересобирают пакетики в нужном порядке Вставить ник Quote
Картуччо Posted April 11, 2014 Author Posted April 11, 2014 Если речь про Ростелеком, то да, ихнее L2VPN было хуже всех прочих вариантов :) Вставить ник Quote
Saab95 Posted April 12, 2014 Posted April 12, 2014 А если попросить L3VPN и самостоятельно паковать трафик в L2? С такой задачей справится любой микротик без проблем. Вставить ник Quote
Картуччо Posted April 12, 2014 Author Posted April 12, 2014 :) Ну как же, тема без микротика это не тема. На днях ещё раз пустили трафик по L2VPN, вроде раскачалось до ожидаемых уровней, админы/субдшники пока сняли свои претензии к сети. Вставить ник Quote
adron2 Posted April 12, 2014 Posted April 12, 2014 А если попросить L3VPN и самостоятельно паковать трафик в L2? С такой задачей справится любой микротик без проблем. Ну и как микротик решит проблему с packet reordering? неужели хоть один из туннелей поддерживаемых микротиком научился делать буфер по приему чтобы восстановить последовательность пакетов. Вставить ник Quote
Abram Posted April 12, 2014 Posted April 12, 2014 Ну и как микротик решит проблему с packet reordering? неужели хоть один из туннелей поддерживаемых микротиком научился делать буфер по приему чтобы восстановить последовательность пакетов. Микротик как блютуз - с ним всё лучше. Вставить ник Quote
Saab95 Posted April 12, 2014 Posted April 12, 2014 Ну и как микротик решит проблему с packet reordering? неужели хоть один из туннелей поддерживаемых микротиком научился делать буфер по приему чтобы восстановить последовательность пакетов. У микротика можно устанавливать буфер любого типа и любого размера. Вставить ник Quote
s.lobanov Posted April 12, 2014 Posted April 12, 2014 Saab95 Размер буфера это одно. А будет ли он пересобирать в нужном порядке? Проще говоре, есть ли в каком-либо тунеле микротика нумерация пакетов? (ну и используется ли она?) Если есть, то жду пруфа в виде ссылки на оф.документацию или дамп Вставить ник Quote
Saab95 Posted April 12, 2014 Posted April 12, 2014 Микротик умеет SSTP, это туннель по TCP, соответственно очередность пакетов нарушаться не будет. Вставить ник Quote
adron2 Posted April 12, 2014 Posted April 12, 2014 ага. вот только sstp со своим tcp все так же будет страдать от нарушения последовательности пакетов! еще варианты есть? Вставить ник Quote
s.lobanov Posted April 12, 2014 Posted April 12, 2014 Микротик умеет SSTP, это туннель по TCP, соответственно очередность пакетов нарушаться не будет. tcp поверх кривого канала будет вносить задержки и тормоза. собственно автор топика сам гоняет tcp поверх l2vpn и добавление ещё одного tcp только ухудшит ситуацию. Если бы речь шла про какой-нибудь snmp трафик, которого мало, задержка не сильно критична, а потери и реордер крайне не желательны, то было бы смысл городить tcp-тунель Вставить ник Quote
nnm Posted April 13, 2014 Posted April 13, 2014 (edited) :) Ну как же, тема без микротика это не тема. На днях ещё раз пустили трафик по L2VPN, вроде раскачалось до ожидаемых уровней, админы/субдшники пока сняли свои претензии к сети. Скажите пожалуйста, а по какой причине Вы строите эту конструкцию поверх L2VPN/лямбды? Есть ведь L3 VPN. Или Вы как-то хитро инкапсулируете трафик и поверх этого L2 VPN/лямбды летит что-то хитрое отличное от IP? Edited April 13, 2014 by nnm Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.