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

Лямбда vs L2VPN

Теоретический вопрос, не понятно в чём причина.

Есть арендованная лямбда на 1 Гбит, есть L2VPN на такую же полосу.

Задержки совершенно одинаковые. Потерь нет.

При этом в малое количество TCP сессий лямбду удаётся прокачать намного сильнее без особых извращений.

L2VPN же наоборот требует массу извращений вплоть до покупки сетевых компрессоров/акселераторов, иначе скорость передачи данных вообще никакая.

В чём может быть причина такого поведения ?

Понятно, что в случае VPN имеются свичи, маршрутизаторы, все они имеют буферы, но ведь задержки одинаковые в итоге.

Share this post


Link to post
Share on other sites

Какова задрежка между точками? Есть ли (хотя бы малые) потери в l2vpn? Если есть, то при большом размере окна эти потери мешают прокачать канал на малом кол-ве tcp-соединений

Share this post


Link to post
Share on other sites

28 мс. Потерь вроде нет.

В том то и дело, что L2VPN под одну задачу от 3 провайдеров брались.

С одним было совсем хреново, с другими лучше, но до лямбды не дотягивают.

Share this post


Link to post
Share on other sites

28 мс.

 

Это для больших пакетов?

Share this post


Link to post
Share on other sites

Какое ограничение на MTU на лямбде и на l2vpn ?

Share this post


Link to post
Share on other sites

Достаточно большой RTT, а можно в цифрах узнать сколько получается прокачать(лямбда, л2впн) и настройки iperf'a ?

Share this post


Link to post
Share on other sites

АЙперф сам по себе не интересен. Проблема в репликаторе базы данных.

Более подробно не могу, так как конечными системами другие занимаются.

И от них жалобы, что лямбда супер, а впн всегда плохо. Хотя тисипи крутили, потоков качки насколько возможно расширили,

и даже брали на тест, а может и купили акселератор от ривербед.

Share this post


Link to post
Share on other sites

Как-то 28мс для лямбды - больно дофига. Или дальность соответствующая? Это ж тыщи км должны быть. Это реально так? И для репликаций БД мне кажется это много.

Как и чем мерили задержку в обоих случаях?

 

Я помню, коллега у меня решал проблему.

Были жалобы от бизнеса, что скорость с площадки за многие тыщи км. 3кБ/сек, хотя канал ого-го, проблем не было, но задержка - да, 160мс. Но другие данные в сотни кБ и мБ/сек летали.

Дамп трафика показал, что именно этот удаленный сервер почему-то ставил TCP окно в 6кБ, и после каждой порции пакетов клиента предлагал окно расширить. Их диалог занимал около секунды, где сервер отказывался, и очередные 3-4 пакета летели до следующих переговоров.

 

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

Share this post


Link to post
Share on other sites

Дальность соответствует, 1500 км по прямой.

Задержка измерялась запуском пингом с маршрутизаторов циско.

Окно TCP конечно же тьюнили.

Share this post


Link to post
Share on other sites

возможно что у магистрала у которого вы арендуете L2VPN просто приоритет на icmp стоит по максимуму а на остальной тип трафика нет. Вот и получается что icmp тесты показывают отличный результат а tcp тормозит!

Я такое видел когда наш украинский UA-IX на экстримах был перегружен. Приходилось изобретать icmp туннели так как gre/udp/tcp было с потерями. icmp же при этом потерь не давал!

Edited by adron2

Share this post


Link to post
Share on other sites

Может быть при использовании L2 VPN reordering происходит?

Share this post


Link to post
Share on other sites

Дальность соответствует, 1500 км по прямой.

Задержка измерялась запуском пингом с маршрутизаторов циско.

Окно TCP конечно же тьюнили.

 

Без дампов траффика - это пустой разговор.

посылайте данные в пакетах бОльшого размера и с бОльшим окном.

А потом сравнивайте дампы траффика на входе и на выходе.

Share this post


Link to post
Share on other sites

+1 к проверке реордеринга. Я даже знаю одного крупного оператора(точнее, его филиал), который делает per-packet балансировку mpls-трафика. И когда я пытался убедить человека, который это реализовал, что так делать не надо, мне не получилось это сделать ибо "всё работает". Даже доводы про мультикаст не сработали, потому что приставки у них умные и буферизируют и пересобирают пакетики в нужном порядке

Share this post


Link to post
Share on other sites

А если попросить L3VPN и самостоятельно паковать трафик в L2? С такой задачей справится любой микротик без проблем.

Share this post


Link to post
Share on other sites

:)

Ну как же, тема без микротика это не тема.

На днях ещё раз пустили трафик по L2VPN, вроде раскачалось до ожидаемых уровней, админы/субдшники пока сняли свои претензии к сети.

Share this post


Link to post
Share on other sites

А если попросить L3VPN и самостоятельно паковать трафик в L2? С такой задачей справится любой микротик без проблем.

 

Ну и как микротик решит проблему с packet reordering? неужели хоть один из туннелей поддерживаемых микротиком научился делать буфер по приему чтобы восстановить последовательность пакетов.

Share this post


Link to post
Share on other sites

Ну и как микротик решит проблему с packet reordering? неужели хоть один из туннелей поддерживаемых микротиком научился делать буфер по приему чтобы восстановить последовательность пакетов.

Микротик как блютуз - с ним всё лучше.

Share this post


Link to post
Share on other sites

Ну и как микротик решит проблему с packet reordering? неужели хоть один из туннелей поддерживаемых микротиком научился делать буфер по приему чтобы восстановить последовательность пакетов.

 

У микротика можно устанавливать буфер любого типа и любого размера.

Share this post


Link to post
Share on other sites

Saab95

Размер буфера это одно. А будет ли он пересобирать в нужном порядке? Проще говоре, есть ли в каком-либо тунеле микротика нумерация пакетов? (ну и используется ли она?) Если есть, то жду пруфа в виде ссылки на оф.документацию или дамп

Share this post


Link to post
Share on other sites

Микротик умеет SSTP, это туннель по TCP, соответственно очередность пакетов нарушаться не будет.

Share this post


Link to post
Share on other sites

ага. вот только sstp со своим tcp все так же будет страдать от нарушения последовательности пакетов!

еще варианты есть?

Share this post


Link to post
Share on other sites

Микротик умеет SSTP, это туннель по TCP, соответственно очередность пакетов нарушаться не будет.

 

tcp поверх кривого канала будет вносить задержки и тормоза. собственно автор топика сам гоняет tcp поверх l2vpn и добавление ещё одного tcp только ухудшит ситуацию.

 

Если бы речь шла про какой-нибудь snmp трафик, которого мало, задержка не сильно критична, а потери и реордер крайне не желательны, то было бы смысл городить tcp-тунель

Share this post


Link to post
Share on other sites

:)

Ну как же, тема без микротика это не тема.

На днях ещё раз пустили трафик по L2VPN, вроде раскачалось до ожидаемых уровней, админы/субдшники пока сняли свои претензии к сети.

 

Скажите пожалуйста, а по какой причине Вы строите эту конструкцию поверх L2VPN/лямбды? Есть ведь L3 VPN. Или Вы как-то хитро инкапсулируете трафик и поверх этого L2 VPN/лямбды летит что-то хитрое отличное от IP?

Edited by nnm

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