Потеря пакетов в точке UA-IX

Поддерживаю, та же проблема. И это беда не шуточная. Связь вроде есть - но её всё же Нет! Играть стало совсем невозможно! Тоже проверял Пингплоттером и WinMTR в том же месте потеря до 100% каждые +- 30 сек. Результаты выложу к вечеру.

Очень надеюсь что проблема не останется без внимания. Судя по всему она сама собой не рассосётся (за последний месяц ничего не изменилось же).

P.S.

Надеюсь На разумную реакцию техподдержки, а не простое игнорирование или вообще удаление темы ( ну дабы внешний вид форума не портила).

Точно такая же ситуация. Очень бесит. Надеюсь на дальнейшее решение этой проблемы.

Как и обещался, результаты моих скромных замеров - в студию. ( то что красное - то плохо)

|------------------------------------------------------------------------------------------|

| WinMTR statistics |

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |

|------------------------------------------------|------|------|------|------|------|------|

| 176.36.134.1 - 0 | 38 | 38 | 0 | 2 | 12 | 7 |

| 77.222.135.65 - 0 | 38 | 38 | 0 | 0 | 28 | 0 |

| ae22-454.k90.fra.datagroup.ua - 84 | 66 | 11 | 0 | 27 | 27 | 27 |

| te3-1.c101.f.de.plusline.net - 0 | 38 | 38 | 28 | 41 | 423 | 28 |

| te1-1.c321.f.de.plusline.net - 0 | 38 | 38 | 28 | 49 | 248 | 29 |

| 82.98.92.146 - 0 | 38 | 38 | 28 | 29 | 48 | 29 |

| gw-dist-pl-a.fhe3rz.net - 0 | 38 | 38 | 29 | 29 | 35 | 29 |

| www167.sedoparking.com - 0 | 38 | 38 | 28 | 28 | 29 | 29 |

|________________________________________________|______|______|______|______|______|______|

WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Так в чем проблема? В том, что промежуточный роутер Датагруп (80.91.160.158) не отвечает "ttl expired"? Так его основная задача - маршрутизировать транзитный трафик. Если На последнем хопе потерь нет - к промежуточным роутерам никаких претензий предъявлять нельзя. Так как на них может быть настроен icmp rate-limit/control plane policing/DDoS protection - куча подобных вещей, чтобы защитить CPU маршрутизатора от ненужного трафика.

Так давайте по всем сегментам будут потери, потому что задача всех остальных маршутизаторов похожа - "маршрутизировать транзитный трафик". Я не специалист по сетям передачи данных, констатирую факт, больше ни у одного из проверенных мной провайдеров похожих симптомов нет. И если специалист отвечает, что проблему решают, значит она существует.

Да, конечно. Но всё-таки ещё раз выскажу своё мнение. Основная функция любого оператора - тупая труба. И пока он передает транзитный трафик из точки A в точку B без проблем, он имеет полное право делать что его захочет с нетранзитным трафиком, который адресован его оборудованию.

Так как у любого оборудования есть аппаратные ограничения, а всякие icmp reqest/ttl expired/ip fragmentation обрабатываются программно - то обычно на маршрутизаторах и настраиваются всякие rate-limiits. Есть даже RFC на эту тему - RFC6192 (http://tools.ietf.org/html/rfc6192), где рекомендуется ограничивать подобный трафик.

Если есть потери на промежуточно роутере, но на НЕ на последнем хопе - да, это повод взять на заметку этот роутер. Возможно, на нём настроены сильно жёсткие ограничения или он действительно сильно загружен. Но пока конечный узел отвечает без потерь - сложно что-либо требовать от оператора. Так как он свои функции выполняет и передает транзитный трафик.

Ага, а потом время от времени они отключают эти "аппаратные ограничения" чтобы простые смертные, вроде меня, могли пару часов нормально погонять в контру?

К всеобщему сожалению это продлилось не долго.

Я конечно понимаю линию Вашей мысли, но как видим суть не в этом. Не думаю что кто то будет время от времени менять политику маршрутизации. Хотя я конечно не специалист, я простой обыватель который заметил проблему и стал искать хотя бы причину (если уж мне не хватает знаний для поиска решений). И как выяснилось проблему заметил не только я, но и все друзья, знакомые и соседи кто из них участвует в активных кибер соревнованиях.

И как Вы прекрасно понимаете у всех есть возможность сравнить с другими провайдерами и нигде подобного замечено НЕ было.

P.S.

Просто надеюсь что все эти "графики и замеры" хоть как то помогут специалистам найти и профиксить проблему.

В Ланете работают образованные умные люди, и я им полностью доверяю. До сих пор они нас не подводили, надеюсь что не оставят нас и сейчас.

Здравствуйте!

Держите нас, пожалуйста, в курсе. Есть ли какие-либо ориентиры по времени устранения проблемы? Что делают/ничего не делают? Почему наша тема не светится в "последние за месяц/неделю", прячете :) ?

Добрый день Алексей.

Ознакомились с вашим вопросом. Можем Вас заверить, что никаких проблем с нашей стороны нет, так же как и нет проблем со стороны вышестоящего провайдера. Мы не заинтересованы в ухудшении качества предоставления услуги, это не наш метод. Наоборот, мы постоянно следим за максимальной связностью с внешними сетями, и качеством передачи данных через них.

Заголовок темы кстати не совсем соответствует действительности, дело в том, что по вашим же тестам видно, что вы опрашиваете ресурс valve.com. Он никак не относится к зоне ua-ix, и трафик на данный ресурс идет прямо в зарубежный сегмент, через транспортный провайдер Datagroup.

По трассировкам маршрута. Данный метод диагностики позволяет узнать через какие узлы проходит трафик, перед тем как попасть в место назначения. При помощи данных утилит действительно можно косвенно оценивать маршрутизацию и заторы в прохождении трафика, но что бы о чем-то говорить необходимо уметь читать данные трассировки и понимать, что не все так просто как кажется.

На примере приведенных Вами графиков четко видно, что никаких проблем с прохождением трафика на конечный узел нет, нет ни потерь не резких скачков rtt. А то, что мы видим на рисунках, говорит лишь о том, что у одного из промежуточных роутеров транспортного провайдера выставлен низкий приоритет на icmp ответы, так как его основная задача это маршрутизировать трафик. Бить тревогу стоит только в том случае, если проблема тянется дальше, то есть дальше за хоп промежуточного маршрутизатора, на котором фиксируются потери вплоть до конечного узла.

Сегодня мы написали письмо сервис инженеру компании Датагруп, что бы выяснить какое ограничение выставлено на обработку icmp запросов данного промежуточного узла.

Предоставляем переписку на обозрение.

Вопрос

1. Добрый день.

   Lanet Network, AS39608, ip 77.222.135.66

   Есть вопрос по настройке ограничений на ваших маршрутизаторах. А именно, policer для ttl на ae22-454.k90.fra.datagroup.ua.

   15:17:33 osa@zinc[7]~>mtr -r -w -c 20 valve.com

   HOST: zinc.la.net.ua Loss% Snt Last Avg Best Wrst StDev

   1. core.la.net.ua 0.0% 20 1.9 4.6 0.2 16.7 5.1

   2. 77.222.135.65 0.0% 20 1.8 2.0 0.3 22.3 5.0

   3. ae22-454.k90.fra.datagroup.ua 90.0% 20 27.7 27.7 27.7 27.7 0.0

   4. ams-ix.nl.plusline.net 15.0% 20 172.5 79.7 41.4 244.1 72.0

   5. te1-1.c321.f.de.plusline.net 0.0% 20 35.6 35.6 35.3 35.8 0.1

   6. 82.98.92.146 0.0% 20 36.1 35.8 35.4 36.6 0.3

   7. gw-dist-pl-a.fhe3rz.net 0.0% 20 36.1 36.7 35.7 41.7 1.4

   8. www167.sedoparking.com 0.0% 20 35.7 35.6 35.2 36.1 0.2

   Наши абоненты, видя подобные потери в трассировке, начинают бить тревогу. Мы, конечно же, пытаемся им объяснить, что это в данном случае не показатель, и не повод для беспокойства. Но для порядка всё-таки хотелось бы уточнить какие ограничения настроены на ae22-454.k90.fra.datagroup.ua, что он так часто пропадает из трассировок?

   --

   Сергей Окунь

   Сетевой инженер

   ООО "Ланет Нетворк", AS39608

Ответ

1. Добрый день,

   Это дроп низко приоритетного трафика icmp предназначенного для самого роутера. Транзитного трафика не касается. Клиентам рекомендуйте смотреть на последний хоп.

   Точную цифру сказать вам не могу, похоже она не поддается настройке. Но приблизительно где-то 100-300 пакетов в секунду. Остальное - дроп.

   --

   Best regards,

   Evgeniy Aikashev

   IP network engineer

   PJSC DATAGROUP

------

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

Сейчас можем заверить всех, что на данный момент никаких очевидных проблем с нашей стороны нет.

Можно смело писать в поддержку Valve, и спрашивать их, почему тормозят игровые сервера. Можно ссылаться на данную тему, как ответ провайдера.

В любом случае, Ланет - спасибо за ответ!

Суть вкратце: настройки магистрального провайдера предполагают "дроп низко приоритетного трафика icmp предназначенного для самого роутера".

Т.е. так, как говорил Sergey Okun в предыдущих постах.

Субъективно, когда нет дропа (бывает и такое, правда очень редко) лагов нет. Я не специалист по транспортным протоколам, но дроп низко приоритетного трафика должен происходит постоянно (раз уж настройки такие), а не так "красиво", как у нас на графиках. Повторюсь, больше я не видел такого ни у одного провайдера. Да и у Ланета такое, только при выходе через Датагрупп. Пример:

И, в дополнение, Воля...

К чести Ланета, следует заметить, что прыжки пинга на Воле, мягко сказать, не радуют. Но потерь пакетов нет вообще. Может Датагрупп (после совместного проекта с Волей в части телевидения) сторонним провам так настраивает роутеры :))

Дроп низкоприоритетного icmp трафика, не обязательно может происходить постоянно, все зависит от количества сервисных пакетов, которые приходят на интерфейс роутера, то есть чем больше людей его опрашивают, тем больше вероятность, что он дойдет до лимита и будет дропать этот трафик. Снова же на сам канал это никак не влияет, если далее по трассировке потери не распространяются.

Пинг вообще не радует, задержка ответа 58ms против наших 29 ms уже о многом говорит.

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