casperrr Опубликовано 12 августа, 2013 · Жалоба Есть услуга L3 VPN от Ростелекома. Канал резервный, не под нагрузкой. В один прекрасный момент начал срабатывать ip sla трекер, мониторящий интерконнектовский адрес на стороне провайдера. Дальнейшие изыскания показали 1-3% потерь на последней миле. Дали заявку. Заявку закрыли, сказав что проблема не подтвердилась. При этом потери существенно уменьшились (подкрутили поди чего, но не признались). Но не пропали свосем. Статистика Ping для xx.xx.xx.xx: Пакетов: отправлено = 305221, получено = 304891, потеряно = 330 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 4мсек, Максимальное = 124 мсек, Среднее = 11 мсек Если посмотреть по распределению во времени - то эти 330 пакетов распределены примерно равномерно. Нет промежутка, когда они шли бы "скопом", а потом отсутствовали. В процентом отношении это примерно 0.1% Вопрос собственно не в желании поплакаться и пожурить мироеда, а чисто технический. Приведенные цифры - это нормально? Поднял договор, там об этом ни слова. Возможно, есть какое-то техническое приложение к договору, но у меня на руках нет. Итого. "Возмутительно" или "вариант нормы, не придирайтесь"? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 12 августа, 2013 · Жалоба нормально, в целом... Тем паче, что это SNMP. Можно попробовать сделать проверку через туда-обратно, указав удаленный IP маршрутизатором NextHop, чтобы он был транзитом, а не назначением. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
casperrr Опубликовано 12 августа, 2013 · Жалоба нормально, в целом... Тем паче, что это SNMP. Можно попробовать сделать проверку через туда-обратно, указав удаленный IP маршрутизатором NextHop, чтобы он был транзитом, а не назначением. А где тут SNMP? Пинг на удаленный ип через данный канал имеет ту же статистику. По основному каналу потери нулевые. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
casperrr Опубликовано 12 августа, 2013 · Жалоба нормально, в целом... Тем паче, что это SNMP. Можно попробовать сделать проверку через туда-обратно, указав удаленный IP маршрутизатором NextHop, чтобы он был транзитом, а не назначением. Есть и другое мнение. http://habrahabr.ru/company/selectel/blog/159193/#comment_5616451 "Такие вещи в первую очередь проверяются. Я предпочитаю пустить UDP флуд средствами ostinato и попутно тыщу пингов с роутера, маркированных EF. Пока хоть один дропается — имею мозги провайдеру." Тут конечно речь о проверке QoS. Но у меня-то канал вообще не загружен. Пустой. Делаю вывод, что где-то у провайдера перегрузка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 12 августа, 2013 · Жалоба Тьфу... icmp, заговорился) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
casperrr Опубликовано 12 августа, 2013 · Жалоба Тьфу... icmp, заговорился) Если вы имели в виду ту фишку, что ицмп может обрабатываться процессором общего назначения, который типа загружен и поэтому пинг плохой, а с каналом при этом все ок - то как объяснить плохой пинг на конечные адреса в удаленных сетях? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 12 августа, 2013 · Жалоба Кроме того, у вас же прописано sla в договоре? Там и rtt и % должен быть указан. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
casperrr Опубликовано 12 августа, 2013 · Жалоба Кроме того, у вас же прописано sla в договоре? Там и rtt и % должен быть указан. rtt не нашел. % есть - 99.7% Это 26 часов в год. Но одно дело когда за год есть две-три крупные аварии, когда канала нет вообще и другое - когда потери, критичные для рилтайм трафика, например. В проценты формально уложились, а проблема-то есть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 12 августа, 2013 · Жалоба % есть - 99.7% этим скорее всего указано время доступности канала, а не процент "непотерь". 10-3 - это большой процент для услуги юрлицу, терзайте техподдержку дальше. Можете также дать нагрузку на канал, например iperf'ом, потери могут при этом возрасти, тогда еще более аргументированно будете общаться с ТП. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 12 августа, 2013 · Жалоба Sla выполняется, претензии неактуальны. Составьте нормально sla или ищите ноомального оператора Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
casperrr Опубликовано 12 августа, 2013 · Жалоба % есть - 99.7% этим скорее всего указано время доступности канала, а не процент "непотерь". 10-3 - это большой процент для услуги юрлицу, терзайте техподдержку дальше. Можете также дать нагрузку на канал, например iperf'ом, потери могут при этом возрасти, тогда еще более аргументированно будете общаться с ТП. Конечно это коэф. доступности, а не уровень потерь. Про них не нашел. Терзаю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 12 августа, 2013 · Жалоба Не пингуйте роутеры. Ставьте unix, на котором нет ограничений на icmp ответы. На роутерах всегда есть policer в сторону control-plane. Можно ещё mtr запустить - он даст немного объективные картину. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
casperrr Опубликовано 12 августа, 2013 · Жалоба Не пингуйте роутеры. Ставьте unix, на котором нет ограничений на icmp ответы. На роутерах всегда есть policer в сторону control-plane. Можно ещё mtr запустить - он даст немного объективные картину. Я в целом соглашусь. Ицмп обрабатывается софтверно и это надо учитывать. Делать опрометчивые выводы на основе одного только теста пингом нельзя. Но в моем случае (в комментах) я указал, что такая же история с пингом на конечные хосты через данный канал. К тому же за почти три года никаких проблем с пингом роутера не было. На счет "на роутерах всегда..." - это, уж извините, тоже опрометчиво. Всегда - очень обязывающее слово, жесткое. Поверьте, что далеко не всегда. И я бы даже сказал - очень часто НЕ. Вот вам пример пинга на интерконнект основного канала (тоже крупный магистрал). ping xx.xx.xx.xx -f -c 5000 PING xx.xx.xx.xx (xx.xx.xx.xx) 56(84) bytes of data. --- xx.xx.xx.xx ping statistics --- 5000 packets transmitted, 5000 received, 0% packet loss, time 12899ms rtt min/avg/max/mdev = 0.000/4.469/229.054/18.193 ms, pipe 19, ipg/ewma 2.580/1.988 ms Ключ -f знаком? Хде признаки защищенного контрол-плана? Потери 0. Или защиты нет, или она как-то уж слишком мягко настроена. К тому же при всем фэн-шуе такого подхода (с защитой) пакеты с форварда на контрол могут вдруг проваливаться совершенно неожиданно и в силу самых непредсказуемых причин. Иногда защита выходит боком. Глядишь, оно бы и прожевало (и это бы было хорошо), да сам зарезал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...