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