Новые ответы

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

mik73, 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, который должен бы давать кол-во прошедших пакетов) тоже не сработал.

Ответить | Сообщить модератору

IP SLA - определение потерь пакетов, eek, 08:46 , 13-Апр-18 (1)
Почитайте про PfR. Для сетей с малым количеством узлов оно конечно будет избыточно, но возможно решит ваш вопрос.
Ответить | Сообщить модератору
IP SLA - определение потерь пакетов, AlexDv, 13:32 , 13-Апр-18 (2)
> Дано: есть канал (IP-tunnel) на котором могут возникать потери пакетов в самом
> разном количестве, от случайных единичных до полной пропажи в течение длительного
> времени.
> Задача: средствами маршрутизатора Cisco определить наличие потерь пакетов выше заданного.
[skipped]
Скрипт на TCL. Пусть хоть постоянно крутится.
Но! Как это скажется на загрузке процессора и памяти неизвестно.

Ответить | Сообщить модератору

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

IP SLA - определение потерь пакетов, AlexDv, 16:52 , 13-Апр-18 (4)
>[оверквотинг удален]
>>> Задача: средствами маршрутизатора 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
```
Ответить | Сообщить модератору

IP SLA - определение потерь пакетов, mik73, 12:20 , 14-Апр-18 (5)
> Дано: есть канал (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, то при двух и более потерянных пакетах в логе наблюдается горка сообщений.
Ответить | Сообщить модератору
IP SLA - определение потерь пакетов, yur, 12:53 , 14-Апр-18 (6)
> 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....
Ответить | Сообщить модератору