Перейти к содержимому
Калькуляторы

Не удается добиться заявленной пропускной способности в MPLS сети Нужна помощь свежей мыслью =)

Суть ситуации:

некий провайдер предоставляет нам MPLS сеть для связи наших региональных офисов и центрального офиса в Москве между собой. Московский "хвост" - 20 Мбит/с, региональные - 2 Мбит/с. Всё более или менее работает за исключением одного регионального центра, из которого неудается выжать больше чем 300 кбит/с.

Проводили тесты с помощью утилки iperf - тест на UDP даёт в первом приближении около 2 Мбит/с, а вот TCP в один поток - около 300 кбит/с. А в три потока - около 3х300 кбит/с. При этом еще и сильно скачет время ответа при пинге. Просто передача файла через FTP или HHTP - 300 кбит/с, не больше.

Провайдер проводил тесты и PE-PE, и CE-CE - результаты соответствуют, 2 Мбит/с с отклонением не больше 15%. А мы на пользовательском трафике не в состоянии добиться нужной пропускной способности. Оборудование самое разное использовали - от ноутбуков с разными операционками до Polycom'ов для видеосвязи.

Может быть у кого-то найдётся свежая мысль - куда копать-то? Что ещё можно проверить? Может ли быть, что провайдер режет скорость одного потока? Пока нам не удаётся убедить провайдера, что проблема с его стороны, хотя все требования по настройке оборудования на нашей стороне мы выполнили.

Буду очень благодарен за подсказку, а то все мозги уже сломали, если честно..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И насколько скачет пинг? А если TCP Window прибить гвоздями и покрутить?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Скачет от 100 где-то до 600 ms..

Окно прибивали - а потом варьировали от 8 до 64 кбайт. Итог варьируется, но в пределах 270-310 кбит/с, что в любом случае не дотягивает до заявленного..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Попробуйте снять дамп траффика и посмотреть wireshark-ом.

На ум приходят или потери или packet reordering.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проведите iperf udp тест на скорости 1мбит - ни один пакет не должен потеряться. Если будут потери, то на tcp-трафике будет маленькая скорость.

В договоре только скорость обозначена или потери тоже?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Используйте туннельные протоколы, гарантирующие доставку пакетов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если у вас с обоих сторон cisco настройте sla тест и посмотрите будут ли потери.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Throughput = TCP Win/RTT. Уменьшайте задержку, если возможно, либо увеличивайте окно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Используйте туннельные протоколы, гарантирующие доставку пакетов.

TCP? 8-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проверьте соответствие установки режима дуплекса между оконечкой провайдера и своим оборудованием и далее по пути внутрь своей сети. Duplex mismath приводит именно к подобного рода эффектам, как-то такую козу полтора месяца не могли найти ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Используйте туннельные протоколы, гарантирующие доставку пакетов.

TCP? 8-)

Нет, максбридж эдишн. :))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тогда уж openvpn over udp

Это не поможет, если у ТС сейчас такие результаты, с опенвпн еще хуже станет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати да, как выше написал Прохожий, дуплекс с обоих сторон одинаковый? А то были косяки подобного рода, когда свитч в результате автоопределения на 10 мбитах ставил фул,

а виндовс ставила 10 халф.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

s.lobanov, UDP iperf на 1 Мбит/с ошибок не дает. В договоре указаны и потери тоже - не более 0,5% пакетов.

 

orlik, циски для sla теста, к сожалению, пока нет на региональном конце, но спасибо за мысль.

 

SoulDivider, окно увеличивали, особой разницы не увидели, как я писал чуть выше.

 

Прохожий, ShumBor, дуплекс проверили первым делом - 100/Full выставлено руками на обоих концах, хотя по первости, да, винда полудуплекс определила на московском конце.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Прохожий, ShumBor, дуплекс проверили первым делом - 100/Full выставлено руками на обоих концах, хотя по первости, да, винда полудуплекс определила на московском конце.

 

Глупый вопрос. Вы дуплекс совместно с провайдером делали, т.е. в 4-х точках, или только у себя ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

пробуйте ещё увеличить окно .

на пингах от 100мс увеличение до 128кб и выше реально помогало

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

rus-p, да совместно с провайдером, именно они и попросили выставить руками на наших концах 100/Full

 

wonder, спасибо, попробуем..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

iperf прогоняли по TCP в одну или обе стороны ?

Если в одну, то в какую ?

Те же вопросы по udp.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нечто подобное было с линией на одного из наших клиентов около5 лет назад. После нескольких дней плясок с бубном проблему локализовали: не могли договориться медный порт нашего медиаконвертера и медный порт на пиксе абонента (модель пикса за давностью не помню). При этом пикс абонента показывал, что порт установился на 100/full, но это не соответствовало. Медиаконвертеры пробовали разные - планет, д-линк, китай-но-нэйм - картина не менялась. Решилось все, когда абонент между конвертером и пиксом воткнул доп. железку (точно не помню - или 2 порта 2950 задействовали, а также пробовали чуть ли не хабосвич неуправляемый). Проблема этим снялась.

Еще из необъяснимого, на поиски чего времени угрохали много и мозг ломали - встречались железки, с которыми циска отказывалась работать через стандартный 4х-парный патчкорд, а работала только через патчкорд из 2х-парного кабеля или стандартный с выкушенными "ненужными" парами. При этом с другим оборудованием (не Cisco) эти железки работали без вопросов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

rus-p, iperf гоняли в одну сторону - серверная часть в Москве, клиентская - в регионе. И TCP, и UDP.

ANM2008, был сначала медиаконвертер с московской стороны и свитч управляемый, к которому цеплялись разные ноутбуки, десктопы и прочее. Потом поставили мультиплексор вместо медиаконвертера. Ситуация не поменялась. Пока грешим на региональную последнюю милю.. Циски пока вообще не пробовали цеплять к этому каналу. Как только в регион приедет циска, попробуем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Скачет от 100 где-то до 600 ms..

 

 

а Вас такой разброс не смущает ? и что про джиттер в договоре ?

 

при 600 или окно должно быть очень большим, или так и будет что 1 поток, что 10, скорость на 1 поток постоянная...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

rus-p, да совместно с провайдером, именно они и попросили выставить руками на наших концах 100/Full

 

попробуйте auto на своей стороне ткнуть :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.