avelosan Опубликовано 3 августа, 2011 · Жалоба Суть ситуации: некий провайдер предоставляет нам MPLS сеть для связи наших региональных офисов и центрального офиса в Москве между собой. Московский "хвост" - 20 Мбит/с, региональные - 2 Мбит/с. Всё более или менее работает за исключением одного регионального центра, из которого неудается выжать больше чем 300 кбит/с. Проводили тесты с помощью утилки iperf - тест на UDP даёт в первом приближении около 2 Мбит/с, а вот TCP в один поток - около 300 кбит/с. А в три потока - около 3х300 кбит/с. При этом еще и сильно скачет время ответа при пинге. Просто передача файла через FTP или HHTP - 300 кбит/с, не больше. Провайдер проводил тесты и PE-PE, и CE-CE - результаты соответствуют, 2 Мбит/с с отклонением не больше 15%. А мы на пользовательском трафике не в состоянии добиться нужной пропускной способности. Оборудование самое разное использовали - от ноутбуков с разными операционками до Polycom'ов для видеосвязи. Может быть у кого-то найдётся свежая мысль - куда копать-то? Что ещё можно проверить? Может ли быть, что провайдер режет скорость одного потока? Пока нам не удаётся убедить провайдера, что проблема с его стороны, хотя все требования по настройке оборудования на нашей стороне мы выполнили. Буду очень благодарен за подсказку, а то все мозги уже сломали, если честно.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 3 августа, 2011 · Жалоба И насколько скачет пинг? А если TCP Window прибить гвоздями и покрутить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
avelosan Опубликовано 3 августа, 2011 · Жалоба Скачет от 100 где-то до 600 ms.. Окно прибивали - а потом варьировали от 8 до 64 кбайт. Итог варьируется, но в пределах 270-310 кбит/с, что в любом случае не дотягивает до заявленного.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 3 августа, 2011 · Жалоба Попробуйте снять дамп траффика и посмотреть wireshark-ом. На ум приходят или потери или packet reordering. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
avelosan Опубликовано 3 августа, 2011 · Жалоба Спасибо за наводку, посмотрю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 3 августа, 2011 · Жалоба Проведите iperf udp тест на скорости 1мбит - ни один пакет не должен потеряться. Если будут потери, то на tcp-трафике будет маленькая скорость. В договоре только скорость обозначена или потери тоже? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 3 августа, 2011 · Жалоба Используйте туннельные протоколы, гарантирующие доставку пакетов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 3 августа, 2011 · Жалоба если у вас с обоих сторон cisco настройте sla тест и посмотрите будут ли потери. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SoulDivider Опубликовано 3 августа, 2011 · Жалоба Throughput = TCP Win/RTT. Уменьшайте задержку, если возможно, либо увеличивайте окно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vIv Опубликовано 3 августа, 2011 · Жалоба Используйте туннельные протоколы, гарантирующие доставку пакетов. TCP? 8-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostich Опубликовано 4 августа, 2011 · Жалоба vIv, openvpn over tcp ^) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Прохожий Опубликовано 4 августа, 2011 · Жалоба Проверьте соответствие установки режима дуплекса между оконечкой провайдера и своим оборудованием и далее по пути внутрь своей сети. Duplex mismath приводит именно к подобного рода эффектам, как-то такую козу полтора месяца не могли найти ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SSD Опубликовано 4 августа, 2011 · Жалоба Используйте туннельные протоколы, гарантирующие доставку пакетов. TCP? 8-) Нет, максбридж эдишн. :)) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 4 августа, 2011 · Жалоба Тогда уж openvpn over udp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SSD Опубликовано 4 августа, 2011 · Жалоба Тогда уж openvpn over udp Это не поможет, если у ТС сейчас такие результаты, с опенвпн еще хуже станет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShumBor Опубликовано 4 августа, 2011 · Жалоба Кстати да, как выше написал Прохожий, дуплекс с обоих сторон одинаковый? А то были косяки подобного рода, когда свитч в результате автоопределения на 10 мбитах ставил фул, а виндовс ставила 10 халф. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
avelosan Опубликовано 4 августа, 2011 · Жалоба s.lobanov, UDP iperf на 1 Мбит/с ошибок не дает. В договоре указаны и потери тоже - не более 0,5% пакетов. orlik, циски для sla теста, к сожалению, пока нет на региональном конце, но спасибо за мысль. SoulDivider, окно увеличивали, особой разницы не увидели, как я писал чуть выше. Прохожий, ShumBor, дуплекс проверили первым делом - 100/Full выставлено руками на обоих концах, хотя по первости, да, винда полудуплекс определила на московском конце. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 4 августа, 2011 · Жалоба Прохожий, ShumBor, дуплекс проверили первым делом - 100/Full выставлено руками на обоих концах, хотя по первости, да, винда полудуплекс определила на московском конце. Глупый вопрос. Вы дуплекс совместно с провайдером делали, т.е. в 4-х точках, или только у себя ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wonder Опубликовано 4 августа, 2011 · Жалоба пробуйте ещё увеличить окно . на пингах от 100мс увеличение до 128кб и выше реально помогало Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
avelosan Опубликовано 4 августа, 2011 · Жалоба rus-p, да совместно с провайдером, именно они и попросили выставить руками на наших концах 100/Full wonder, спасибо, попробуем.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 4 августа, 2011 · Жалоба iperf прогоняли по TCP в одну или обе стороны ? Если в одну, то в какую ? Те же вопросы по udp. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ANM2008 Опубликовано 4 августа, 2011 · Жалоба Нечто подобное было с линией на одного из наших клиентов около5 лет назад. После нескольких дней плясок с бубном проблему локализовали: не могли договориться медный порт нашего медиаконвертера и медный порт на пиксе абонента (модель пикса за давностью не помню). При этом пикс абонента показывал, что порт установился на 100/full, но это не соответствовало. Медиаконвертеры пробовали разные - планет, д-линк, китай-но-нэйм - картина не менялась. Решилось все, когда абонент между конвертером и пиксом воткнул доп. железку (точно не помню - или 2 порта 2950 задействовали, а также пробовали чуть ли не хабосвич неуправляемый). Проблема этим снялась. Еще из необъяснимого, на поиски чего времени угрохали много и мозг ломали - встречались железки, с которыми циска отказывалась работать через стандартный 4х-парный патчкорд, а работала только через патчкорд из 2х-парного кабеля или стандартный с выкушенными "ненужными" парами. При этом с другим оборудованием (не Cisco) эти железки работали без вопросов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
avelosan Опубликовано 4 августа, 2011 · Жалоба rus-p, iperf гоняли в одну сторону - серверная часть в Москве, клиентская - в регионе. И TCP, и UDP. ANM2008, был сначала медиаконвертер с московской стороны и свитч управляемый, к которому цеплялись разные ноутбуки, десктопы и прочее. Потом поставили мультиплексор вместо медиаконвертера. Ситуация не поменялась. Пока грешим на региональную последнюю милю.. Циски пока вообще не пробовали цеплять к этому каналу. Как только в регион приедет циска, попробуем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 4 августа, 2011 · Жалоба Скачет от 100 где-то до 600 ms.. а Вас такой разброс не смущает ? и что про джиттер в договоре ? при 600 или окно должно быть очень большим, или так и будет что 1 поток, что 10, скорость на 1 поток постоянная... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostich Опубликовано 4 августа, 2011 · Жалоба rus-p, да совместно с провайдером, именно они и попросили выставить руками на наших концах 100/Full попробуйте auto на своей стороне ткнуть :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...