The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"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ообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | 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 | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру