mik73
Зарегистрирован: 13 апр 2018, 12:35 Сообщения: 5
|
Дано: есть канал на котором могут возникать потери пакетов в самом разном количестве, от случайных единичных до полной пропажи в течение длительного времени. Именно случайные потери, не связанные с загрузкой/пропускной способностью. Задача: средствами маршрутизатора Cisco определить наличие потерь пакетов выше заданного (например, больше 2-х из 50). В конечном итоге - чтобы принять рещение о переключении маршрута, если там есть потери.
пытаюсь использовать 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 мс и задаем макс. средний джиттер 30 мс (параметры такие, потмоу что такие).
но сам по себе такой тест выдает признак ошибки (operation return code: Timeout) только если ни один из посланных пакетов не дойдет. Если дошел хотя бы один, то считается, что все хорошо (operation return code: OK). А надо отловить ситуацию, когда пропали несколько пакетов из отправленных 50-ти. Поэтому попробовал добавить реакцию и на таймаут и и на packetLoss (поскольку надо отслеживать и частичную потерю пакетов и полное пропадание канала). Для теста icmp-jitter, согласно документации Cisco, 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 - т.е. реагировать на потерю даже одного пакета) , то должны генерироваться трапы и выдаваться события на консоль.
однако, выходит не так если все пакеты потеряны, то реакция на return code: Timeout выдается (при этом все RTT и Jitter по нолям):
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 return code:OK, наличие Packet Loss видно, а событие не возникает: 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 на наличие скольки-то потерянных при тесте пакетов?
|
mik73
Зарегистрирован: 13 апр 2018, 12:35 Сообщения: 5
|
Отвечаю на свой вопрос:
threshold-value 50 1 означает, что реакция будет возникать, если потеряно меньше одного ИЛИ больше 50 пакетов. Поскольку посылаю всего 50 пакетов - то никогда. если написать threshold-value 1 1, то при двух и более потерянных пакетах в логе наблюдается горка сообщений.
|