Качество услуги

[casperrr]

Есть услуга L3 VPN от Ростелекома. Канал резервный, не под нагрузкой. В один прекрасный момент начал срабатывать ip sla трекер, мониторящий интерконнектовский адрес на стороне провайдера. Дальнейшие изыскания показали 1-3% потерь на последней миле. Дали заявку. Заявку закрыли, сказав что проблема не подтвердилась. При этом потери существенно уменьшились (подкрутили поди чего, но не признались). Но не пропали свосем.

 

Статистика Ping для xx.xx.xx.xx:

Пакетов: отправлено = 305221, получено = 304891, потеряно = 330

(0% потерь)

Приблизительное время приема-передачи в мс:

Минимальное = 4мсек, Максимальное = 124 мсек, Среднее = 11 мсек

 

Если посмотреть по распределению во времени - то эти 330 пакетов распределены примерно равномерно. Нет промежутка, когда они шли бы "скопом", а потом отсутствовали. В процентом отношении это примерно 0.1%

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

Итого. "Возмутительно" или "вариант нормы, не придирайтесь"?

[dignity]

нормально, в целом... Тем паче, что это SNMP. Можно попробовать сделать проверку через туда-обратно, указав удаленный IP маршрутизатором NextHop, чтобы он был транзитом, а не назначением.

[casperrr]

нормально, в целом... Тем паче, что это SNMP. Можно попробовать сделать проверку через туда-обратно, указав удаленный IP маршрутизатором NextHop, чтобы он был транзитом, а не назначением.

А где тут SNMP?

Пинг на удаленный ип через данный канал имеет ту же статистику. По основному каналу потери нулевые.

[casperrr]

нормально, в целом... Тем паче, что это SNMP. Можно попробовать сделать проверку через туда-обратно, указав удаленный IP маршрутизатором NextHop, чтобы он был транзитом, а не назначением.

 

Есть и другое мнение.

 

http://habrahabr.ru/company/selectel/blog/159193/#comment_5616451

"Такие вещи в первую очередь проверяются. Я предпочитаю пустить UDP флуд средствами ostinato и попутно тыщу пингов с роутера, маркированных EF. Пока хоть один дропается — имею мозги провайдеру."

 

Тут конечно речь о проверке QoS. Но у меня-то канал вообще не загружен. Пустой. Делаю вывод, что где-то у провайдера перегрузка.

[dignity]

Тьфу... icmp, заговорился)

[casperrr]

Тьфу... icmp, заговорился)

 

Если вы имели в виду ту фишку, что ицмп может обрабатываться процессором общего назначения, который типа загружен и поэтому пинг плохой, а с каналом при этом все ок - то как объяснить плохой пинг на конечные адреса в удаленных сетях?

[dignity]

Кроме того, у вас же прописано sla в договоре? Там и rtt и % должен быть указан.

[casperrr]

Кроме того, у вас же прописано sla в договоре? Там и rtt и % должен быть указан.

rtt не нашел.

% есть - 99.7%

Это 26 часов в год. Но одно дело когда за год есть две-три крупные аварии, когда канала нет вообще и другое - когда потери, критичные для рилтайм трафика, например. В проценты формально уложились, а проблема-то есть.

[agr]

% есть - 99.7%

 

этим скорее всего указано время доступности канала, а не процент "непотерь".

 

10^-3 - это большой процент для услуги юрлицу, терзайте техподдержку дальше. Можете также дать нагрузку на канал, например iperf'ом, потери могут при этом возрасти, тогда еще более аргументированно будете общаться с ТП.

[dignity]

Sla выполняется, претензии неактуальны. Составьте нормально sla или ищите ноомального оператора

[casperrr]

% есть - 99.7%

 

этим скорее всего указано время доступности канала, а не процент "непотерь".

 

10^-3 - это большой процент для услуги юрлицу, терзайте техподдержку дальше. Можете также дать нагрузку на канал, например iperf'ом, потери могут при этом возрасти, тогда еще более аргументированно будете общаться с ТП.

 

Конечно это коэф. доступности, а не уровень потерь. Про них не нашел. Терзаю.

[dmvy]

Не пингуйте роутеры. Ставьте unix, на котором нет ограничений на icmp ответы. На роутерах всегда есть policer в сторону control-plane. Можно ещё mtr запустить - он даст немного объективные картину.

[casperrr]

Не пингуйте роутеры. Ставьте 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. Или защиты нет, или она как-то уж слишком мягко настроена.

К тому же при всем фэн-шуе такого подхода (с защитой) пакеты с форварда на контрол могут вдруг проваливаться совершенно неожиданно и в силу самых непредсказуемых причин. Иногда защита выходит боком. Глядишь, оно бы и прожевало (и это бы было хорошо), да сам зарезал.