forum.opennet.ru - "IP SLA - определение потерь пакетов" (6)

"IP SLA - определение потерь пакетов"

Форум Маршрутизаторы CISCO и др. оборудование. (Мониторинг, статистика, SNMP)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"IP SLA - определение потерь пакетов"	+/–
Сообщение от mik73 (ok) on 12-Апр-18, 23:55
Дано: есть канал (IP-tunnel) на котором могут возникать потери пакетов в самом разном количестве, от случайных единичных до полной пропажи в течение длительного времени. Задача: средствами маршрутизатора Cisco определить наличие потерь пакетов выше заданного. Для этого использую IP SLA. Тест icmp-echo не годится, т.к. периодически посылается один пакет и тот может случайно пройти даже в ситуации, когда потери в канале есть (например 50% пактов теряются, а тестовыйзатесался среди 50% прошедших - и про ухудшение канала мы не узнали). Поэтому выбран тест icmp-jitter который может посылать заданное количество пакетов. вот так: ip sla 1 icmp-jitter 10.250.249.165 source-ip 10.250.249.166 num-packets 50 threshold 30 timeout 200 frequency 10 ip sla schedule 1 life forever start-time now т.е. раз в 10 секунд посылаем 50 пакетов с макс таймаутом 200 мс (реальный таймаут на канале в районе 100-120 мс, но до 200 - не криминал) и задаем макс. средний джиттер 30 мс (это годится). но сам по себе такой тест выдает признак ошибки (operation return code: Timeout) только если ни один из посленных пакетов не дойдет. Если дошел хотя бы один, то считается, что все хорошо (operation return code: OK). А надо отловить ситуацию, когда пропали несколько пакетов(в пределе - 1) из отправленных 50-ти. Поэтому попробовал добавить реакцию и на таймаут и и на packetLoss (поскольку надо отслеживать и частчиную и полную потерю пакетов). вот так: ip sla reaction-configuration 1 react timeout threshold-type immediate action-type trapOnly ip sla reaction-configuration 1 react packetLoss threshold-value 50 1 threshold-type immediate action-type trapOnly ip sla logging traps насколько я понимаю, если в результате теста получили timeout (ни один пакет не дошел) или имеем сколько-то (от 1 до 50 - задал по максимуму) потерянных пакетов, то должны генерироваться трапы и выдаваться события на консоль. однако, выходит не так если все пакеты потеряны, то реакция и сообщение на консоль есть: CISCO# sh ip sla stat 1 IPSLAs Latest Operation Statistics IPSLA operation id: 1 Type of operation: icmp-jitter Latest RTT: NoConnection/Busy/Timeout Latest operation start time: 15:38:07 UTC Thu Apr 12 2018 Latest operation return code: Timeout RTT Values: Number Of RTT: 0 RTT Min/Avg/Max: 0/0/0 milliseconds Latency one-way time: Number of Latency one-way Samples: 0 Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds Jitter Time: Number of SD Jitter Samples: 0 Number of DS Jitter Samples: 0 Source to Destination Jitter Min/Avg/Max: 0/0/0 milliseconds Destination to Source Jitter Min/Avg/Max: 0/0/0 milliseconds Packet Late Arrival: 0 Out Of Sequence: 0 Source to Destination: 0 Destination to Source 0 In both Directions: 0 Packet Skipped: 0 Packet Unprocessed: 0 Packet Loss: 0 Loss Periods Number: 0 Loss Period Length Min/Max: 0/0 Inter Loss Period Length Min/Max: 0/0 Number of successes: 148 Number of failures: 7 Operation time to live: Forever на консоли при этом: Apr 12 15:36:38.223: %RTT-4-OPER_TIMEOUT: condition occurred, entry number = 1 Apr 12 15:36:38.239: %RTT-3-IPSLATHRESHOLD: IP SLAs(1): Threshold Occurred for timeout когда канал восстанавливается: Apr 12 15:36:58.111: %RTT-4-OPER_TIMEOUT: condition cleared, entry number = 1 Apr 12 15:36:58.131: %RTT-3-IPSLATHRESHOLD: IP SLAs(1): Threshold Cleared for timeout а когда есть частичная потеря пакетов, то в статистике SLA ее видно, а событие не возникает: CISCO# sh ip sla stat 1 IPSLAs Latest Operation Statistics IPSLA operation id: 1 Type of operation: icmp-jitter Latest RTT: 112 milliseconds Latest operation start time: 15:30:17 UTC Thu Apr 12 2018 Latest operation return code: OK RTT Values: Number Of RTT: 19 RTT Min/Avg/Max: 112/112/113 milliseconds Latency one-way time: Number of Latency one-way Samples: 0 Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds Jitter Time: Number of SD Jitter Samples: 18 Number of DS Jitter Samples: 18 Source to Destination Jitter Min/Avg/Max: 0/0/0 milliseconds Destination to Source Jitter Min/Avg/Max: 0/1/1 milliseconds Packet Late Arrival: 0 Out Of Sequence: 0 Source to Destination: 0 Destination to Source 0 In both Directions: 0 Packet Skipped: 0 Packet Unprocessed: 0 Packet Loss: 31 Loss Periods Number: 1 Loss Period Length Min/Max: 31/31 Inter Loss Period Length Min/Max: 19/19 Number of successes: 105 Number of failures: 3 Operation time to live: Forever на консоли сообщений нет, в логах тоже. Собственно, вопрос - что сделано не так и как заставить реагировать SLA не только на полное падение канала (событие timeout) но и наличие скольки-то потерянных при тесте пакетов? P.S. в найденной на просторах Инета документации Cisco написано, что параметр packetLoss в тесте icmp-jitter использовать можно. P.P.S. И может быть возможно решить задачу без SLA (но средствами Cisco)? Я пытался копать в сторону EEM, но что-то ничего не вытанцовывается. Найденный в Интете пример скрещивания sla с EEM (через snmp oid, который должен бы давать кол-во прошедших пакетов) тоже не сработал.
Ответить \| Правка \| Cообщить модератору

Оглавление

IP SLA - определение потерь пакетов, eek, 08:46 , 13-Апр-18, (1)
IP SLA - определение потерь пакетов, AlexDv, 13:32 , 13-Апр-18, (2)

IP SLA - определение потерь пакетов, mik73, 14:31 , 13-Апр-18, (3)

IP SLA - определение потерь пакетов, AlexDv, 16:52 , 13-Апр-18, (4)

IP SLA - определение потерь пакетов, mik73, 12:20 , 14-Апр-18, (5)
IP SLA - определение потерь пакетов, yur, 12:53 , 14-Апр-18, (6)

Сообщения по теме [Сортировка по времени | RSS]

1. "IP SLA - определение потерь пакетов" +/–

Сообщение от eek (ok) on 13-Апр-18, 08:46

Почитайте про PfR. Для сетей с малым количеством узлов оно конечно будет избыточно, но возможно решит ваш вопрос.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "IP SLA - определение потерь пакетов" +/–

Сообщение от AlexDv (??) on 13-Апр-18, 13:32

> Дано: есть канал (IP-tunnel) на котором могут возникать потери пакетов в самом
> разном количестве, от случайных единичных до полной пропажи в течение длительного
> времени.
> Задача: средствами маршрутизатора Cisco определить наличие потерь пакетов выше заданного.
[skipped]
Скрипт на TCL. Пусть хоть постоянно крутится.
Но! Как это скажется на загрузке процессора и памяти неизвестно.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "IP SLA - определение потерь пакетов" +/–

Сообщение от mik73 (ok) on 13-Апр-18, 14:31

>> Дано: есть канал (IP-tunnel) на котором могут возникать потери пакетов...
>> Задача: средствами маршрутизатора Cisco определить наличие потерь пакетов выше заданного.
> Скрипт на TCL. Пусть хоть постоянно крутится.
> Но! Как это скажется на загрузке процессора и памяти неизвестно.
И еще требует вникания в TCL. Как дать из скрипта команду ping - понятно, а вот не просто глазами посмотреть результат, а вернуть результат в скрипт, посмотреть скриптом кол-во потерь и на основании этого принять решение и инициировать дальнейшие действия (изменение маршрута) - это для меня уже за гранью добра и зла.
Вроде, есть штатное средство - SLA - и то, что надо, в принципе выдает, но заставить работать как хочется не получается.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "IP SLA - определение потерь пакетов" +/–

Сообщение от AlexDv (??) on 13-Апр-18, 16:52

>[оверквотинг удален]
>>> Задача: средствами маршрутизатора Cisco определить наличие потерь пакетов выше заданного.
>> Скрипт на TCL. Пусть хоть постоянно крутится.
>> Но! Как это скажется на загрузке процессора и памяти неизвестно.
> И еще требует вникания в TCL. Как дать из скрипта команду ping
> - понятно, а вот не просто глазами посмотреть результат, а вернуть
> результат в скрипт, посмотреть скриптом кол-во потерь и на основании этого
> принять решение и инициировать дальнейшие действия (изменение маршрута) - это для
> меня уже за гранью добра и зла.
> Вроде, есть штатное средство - SLA - и то, что надо, в
> принципе выдает, но заставить работать как хочется не получается.
Можно так, потом EEM ловить сообщения в логе.

proc init {} {
set ip_source 1.1.1.1
set ip_dest   2.2.2.2
set loss_limit 99
set search_expr {(\d+)(?:\spercent)}
set r ""
set s_rate 0
    set status [exec "ping $ip_dest source $ip_source repeat 1000"]
    regexp  $search_expr  $status r s_rate
    if { $s_rate < $loss_limit} {
        writelog "Все пропало!!!"
        }
}
proc writelog {logstring} {
    set syslog [open "syslog:" w+]
    puts $syslog $logstring
    close $syslog
}
eval init

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "IP SLA - определение потерь пакетов" +/–

Сообщение от mik73 (ok) on 14-Апр-18, 12:20

> Дано: есть канал (IP-tunnel) на котором могут возникать потери...
> Задача: средствами маршрутизатора Cisco определить наличие потерь пакетов выше заданного.
> Для этого использую IP SLA.
[skipped]
> ip sla reaction-configuration 1 react packetLoss threshold-value 50 1 threshold-type immediate
[skipped]
> Собственно, вопрос - что сделано не так и как заставить реагировать SLA на наличие
> скольки-то потерянных при тесте пакетов?
[skipped]
Отвечаю сам себе:
threshold-value 50 1 означает, что реакция будет возникать, если потеряно меньше одного ИЛИ больше 50 пакетов. Поскольку посылаю всего 50 пакетов - то никогда.
Если написать threshold-value 1 1, то при двух и более потерянных пакетах в логе наблюдается горка сообщений.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "IP SLA - определение потерь пакетов" +/–

Сообщение от yur (??) on 14-Апр-18, 12:53

> ip sla reaction-configuration 1 react packetLoss threshold-value 50 1 threshold-type immediate
> action-type trapOnly
> ip sla logging traps
> насколько я понимаю, если в результате теста получили timeout (ни один пакет
> не дошел) или имеем сколько-то (от 1 до 50 - задал
> по максимуму) потерянных пакетов, то должны генерироваться трапы и выдаваться события
> на консоль.
Вы неправильно понимаете. Как это устроено - нарисовано здесь: https://www.cisco.com/c/dam/en/us/td/i/200001-300000/200001-...
У вас rising threshold равен 50, falling - 1. Так события и генерируются.
Прочитайте Configuring Proactive Threshold Monitoring for IP SLAs Operations - https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/conf....

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "IP SLA - определение потерь пакетов"	+/–
Сообщение от eek (ok) on 13-Апр-18, 08:46
Почитайте про PfR. Для сетей с малым количеством узлов оно конечно будет избыточно, но возможно решит ваш вопрос.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору

2. "IP SLA - определение потерь пакетов"	+/–
Сообщение от AlexDv (??) on 13-Апр-18, 13:32
> Дано: есть канал (IP-tunnel) на котором могут возникать потери пакетов в самом > разном количестве, от случайных единичных до полной пропажи в течение длительного > времени. > Задача: средствами маршрутизатора Cisco определить наличие потерь пакетов выше заданного. [skipped] Скрипт на TCL. Пусть хоть постоянно крутится. Но! Как это скажется на загрузке процессора и памяти неизвестно.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	3. "IP SLA - определение потерь пакетов"	+/–
	Сообщение от mik73 (ok) on 13-Апр-18, 14:31
	>> Дано: есть канал (IP-tunnel) на котором могут возникать потери пакетов... >> Задача: средствами маршрутизатора Cisco определить наличие потерь пакетов выше заданного. > Скрипт на TCL. Пусть хоть постоянно крутится. > Но! Как это скажется на загрузке процессора и памяти неизвестно. И еще требует вникания в TCL. Как дать из скрипта команду ping - понятно, а вот не просто глазами посмотреть результат, а вернуть результат в скрипт, посмотреть скриптом кол-во потерь и на основании этого принять решение и инициировать дальнейшие действия (изменение маршрута) - это для меня уже за гранью добра и зла. Вроде, есть штатное средство - SLA - и то, что надо, в принципе выдает, но заставить работать как хочется не получается.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "IP SLA - определение потерь пакетов"	+/–
	Сообщение от AlexDv (??) on 13-Апр-18, 16:52
	>[оверквотинг удален] >>> Задача: средствами маршрутизатора Cisco определить наличие потерь пакетов выше заданного. >> Скрипт на TCL. Пусть хоть постоянно крутится. >> Но! Как это скажется на загрузке процессора и памяти неизвестно. > И еще требует вникания в TCL. Как дать из скрипта команду ping > - понятно, а вот не просто глазами посмотреть результат, а вернуть > результат в скрипт, посмотреть скриптом кол-во потерь и на основании этого > принять решение и инициировать дальнейшие действия (изменение маршрута) - это для > меня уже за гранью добра и зла. > Вроде, есть штатное средство - SLA - и то, что надо, в > принципе выдает, но заставить работать как хочется не получается. Можно так, потом EEM ловить сообщения в логе. proc init {} { set ip_source 1.1.1.1 set ip_dest 2.2.2.2 set loss_limit 99 set search_expr {(\d+)(?:\spercent)} set r "" set s_rate 0 set status [exec "ping $ip_dest source $ip_source repeat 1000"] regexp $search_expr $status r s_rate if { $s_rate < $loss_limit} { writelog "Все пропало!!!" } } proc writelog {logstring} { set syslog [open "syslog:" w+] puts $syslog $logstring close $syslog } eval init
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору

5. "IP SLA - определение потерь пакетов"	+/–
Сообщение от mik73 (ok) on 14-Апр-18, 12:20
> Дано: есть канал (IP-tunnel) на котором могут возникать потери... > Задача: средствами маршрутизатора Cisco определить наличие потерь пакетов выше заданного. > Для этого использую IP SLA. [skipped] > ip sla reaction-configuration 1 react packetLoss threshold-value 50 1 threshold-type immediate [skipped] > Собственно, вопрос - что сделано не так и как заставить реагировать SLA на наличие > скольки-то потерянных при тесте пакетов? [skipped] Отвечаю сам себе: threshold-value 50 1 означает, что реакция будет возникать, если потеряно меньше одного ИЛИ больше 50 пакетов. Поскольку посылаю всего 50 пакетов - то никогда. Если написать threshold-value 1 1, то при двух и более потерянных пакетах в логе наблюдается горка сообщений.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору

6. "IP SLA - определение потерь пакетов"	+/–
Сообщение от yur (??) on 14-Апр-18, 12:53
> ip sla reaction-configuration 1 react packetLoss threshold-value 50 1 threshold-type immediate > action-type trapOnly > ip sla logging traps > насколько я понимаю, если в результате теста получили timeout (ни один пакет > не дошел) или имеем сколько-то (от 1 до 50 - задал > по максимуму) потерянных пакетов, то должны генерироваться трапы и выдаваться события > на консоль. Вы неправильно понимаете. Как это устроено - нарисовано здесь: https://www.cisco.com/c/dam/en/us/td/i/200001-300000/200001-... У вас rising threshold равен 50, falling - 1. Так события и генерируются. Прочитайте Configuring Proactive Threshold Monitoring for IP SLAs Operations - https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/conf....
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору