https://opennet.dev/openforum/vsluhforumID6/2288.html Дано: есть канал (IP-tunnel) на котором могут возникать потери пакетов в самом разном количестве, от случайных единичных до полной пропажи в течение длительного времени.<br>Задача: средствами маршрутизатора Cisco определить наличие потерь пакетов выше заданного.<br><br>Для этого использую IP SLA.<br>Тест icmp-echo не годится, т.к. периодически посылается один пакет и тот может случайно пройти даже в ситуации, когда потери в канале есть (например 50% пактов теряются, а тестовыйзатесался среди 50% прошедших - и про ухудшение канала мы не узнали). Поэтому выбран тест icmp-jitter который может посылать заданное количество пакетов.<br>вот так:<br><br>ip sla 1<br>icmp-jitter 10.250.249.165 source-ip 10.250.249.166 num-packets 50<br>threshold 30<br>timeout 200<br>frequency 10<br>ip sla schedule 1 life forever start-time now<br><br>т.е. раз в 10 секунд посылаем 50 пакетов с макс таймаутом 200 мс (реальный таймаут на канале в районе 100-120 мс, но до 200 - не криминал) и задаем макс. средний джиттер 30 мс (это годится).<br><br>но сам по себе такой https://opennet.dev/openforum/vsluhforumID6/2288.html#6 Sat, 14 Apr 2018 09:53:43 GMT &gt; ip sla reaction-configuration 1 react packetLoss threshold-value 50 1 threshold-type immediate <br>&gt; action-type trapOnly <br>&gt; ip sla logging traps <br>&gt; насколько я понимаю, если в результате теста получили timeout (ни один пакет <br>&gt; не дошел) или имеем сколько-то (от 1 до 50 - задал <br>&gt; по максимуму) потерянных пакетов, то должны генерироваться трапы и выдаваться события <br>&gt; на консоль.<br><br>Вы неправильно понимаете. Как это устроено - нарисовано здесь: https://www.cisco.com/c/dam/en/us/td/i/200001-300000/200001-210000/207001-208000/207608.eps/_jcr_content/renditions/207608.jpg<br><br>У вас rising threshold равен 50, falling - 1. Так события и генерируются.<br><br>Прочитайте Configuring Proactive Threshold Monitoring for IP SLAs Operations - https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/configuration/15-mt/sla-15-mt-book/sla_threshold_mon-0.html.<br> https://opennet.dev/openforum/vsluhforumID6/2288.html#5 Sat, 14 Apr 2018 09:20:02 GMT &gt; Дано: есть канал (IP-tunnel) на котором могут возникать потери...<br>&gt; Задача: средствами маршрутизатора Cisco определить наличие потерь пакетов выше заданного. <br>&gt; Для этого использую IP SLA.<br><br>[skipped]<br><br>&gt; ip sla reaction-configuration 1 react packetLoss threshold-value 50 1 threshold-type immediate <br><br>[skipped]<br>&gt; Собственно, вопрос - что сделано не так и как заставить реагировать SLA на наличие <br>&gt; скольки-то потерянных при тесте пакетов?<br><br>[skipped]<br><br>Отвечаю сам себе:<br>threshold-value 50 1 означает, что реакция будет возникать, если потеряно меньше одного ИЛИ больше 50 пакетов. Поскольку посылаю всего 50 пакетов - то никогда.<br>Если написать threshold-value 1 1, то при двух и более потерянных пакетах в логе наблюдается горка сообщений. <br> https://opennet.dev/openforum/vsluhforumID6/2288.html#4 Fri, 13 Apr 2018 13:52:50 GMT &gt;[оверквотинг удален]<br>&gt;&gt;&gt; Задача: средствами маршрутизатора Cisco определить наличие потерь пакетов выше заданного.<br>&gt;&gt; Скрипт на TCL. Пусть хоть постоянно крутится.<br>&gt;&gt; Но! Как это скажется на загрузке процессора и памяти неизвестно.<br>&gt; И еще требует вникания в TCL. Как дать из скрипта команду ping <br>&gt; - понятно, а вот не просто глазами посмотреть результат, а вернуть <br>&gt; результат в скрипт, посмотреть скриптом кол-во потерь и на основании этого <br>&gt; принять решение и инициировать дальнейшие действия (изменение маршрута) - это для <br>&gt; меня уже за гранью добра и зла.<br>&gt; Вроде, есть штатное средство - SLA - и то, что надо, в <br>&gt; принципе выдает, но заставить работать как хочется не получается.<br><br>Можно так, потом EEM ловить сообщения в логе.<br><br>[code]<br>proc init {} {<br>set ip_source 1.1.1.1<br>set ip_dest 2.2.2.2<br>set loss_limit 99<br>set search_expr {(\d+)(?:\spercent)}<br>set r ""<br>set s_rate 0<br> set status [exec "ping $ip_dest source $ip_source repeat 1000"]<br> regexp $search_expr $status r s_rate<br> i https://opennet.dev/openforum/vsluhforumID6/2288.html#3 Fri, 13 Apr 2018 11:31:38 GMT &gt;&gt; Дано: есть канал (IP-tunnel) на котором могут возникать потери пакетов...<br>&gt;&gt; Задача: средствами маршрутизатора Cisco определить наличие потерь пакетов выше заданного.<br>&gt; Скрипт на TCL. Пусть хоть постоянно крутится.<br>&gt; Но! Как это скажется на загрузке процессора и памяти неизвестно.<br><br>И еще требует вникания в TCL. Как дать из скрипта команду ping - понятно, а вот не просто глазами посмотреть результат, а вернуть результат в скрипт, посмотреть скриптом кол-во потерь и на основании этого принять решение и инициировать дальнейшие действия (изменение маршрута) - это для меня уже за гранью добра и зла.<br><br>Вроде, есть штатное средство - SLA - и то, что надо, в принципе выдает, но заставить работать как хочется не получается.<br><br><br><br> https://opennet.dev/openforum/vsluhforumID6/2288.html#2 Fri, 13 Apr 2018 10:32:30 GMT &gt; Дано: есть канал (IP-tunnel) на котором могут возникать потери пакетов в самом <br>&gt; разном количестве, от случайных единичных до полной пропажи в течение длительного <br>&gt; времени.<br>&gt; Задача: средствами маршрутизатора Cisco определить наличие потерь пакетов выше заданного. <br><br>[skipped]<br><br>Скрипт на TCL. Пусть хоть постоянно крутится.<br>Но! Как это скажется на загрузке процессора и памяти неизвестно.<br> <br> https://opennet.dev/openforum/vsluhforumID6/2288.html#1 Fri, 13 Apr 2018 05:46:54 GMT Почитайте про PfR. Для сетей с малым количеством узлов оно конечно будет избыточно, но возможно решит ваш вопрос.<br>