# Настройка Без лишних слов, сразу к настройке. Для начала, нам нужно сказать, что мы хотим мониторить. Создаем объект мониторинга, назначаем ему номер: ``` R4(config)#ip sla 1 ``` Так-с, что мы тут можем мониторить? > R4(config-ip-sla)#?\ > IP SLAs entry configuration commands:\ > dhcp DHCP Operation\ > dns DNS Query Operation\ > exit Exit Operation Configuration\ > frame-relay Frame-relay Operation\ > ftp FTP Operation\ > http HTTP Operation\ > icmp-echo ICMP Echo Operation\ > icmp-jitter ICMP Jitter Operation\ > mpls MPLS Operation\ > path-echo Path Discovered ICMP Echo Operation\ > path-jitter Path Discovered ICMP Jitter Operation\ > slm SLM Operation\ > tcp-connect TCP Connect Operation\ > udp-echo UDP Echo Operation\ > udp-jitter UDP Jitter Operation\ > voip Voice Over IP Operation > > Нужно сказать, что синтаксис команд, относящихся к IP SLA, претерпел некоторые изменения: начиная с IOS 12.4(4)T он такой, как в статье, до этого некоторые команды писались по другому. Например, вместо ip sla 1 было rtr 1 или вместо ip sla responder – rtr responder Как видите, список внушительный, поэтому останавливаться не будем, для интересующихся есть подробная [статья](http://www.cisco.com/en/US/technologies/tk648/tk362/tk920/technologies_white_paper09186a00802d5efe_ps6602_Products_White_Paper.html) на циско.ком. Обычно, работу IP SLA рассматривают на простейшем примере *icmp-echo*. То есть, в случае, если мы можем пинговать тот конец линии, трафик идет по ней, если не можем – по другой. Но мы пойдем путем чуть посложнее. Итак, нас интересуют характеристики канала, важные для голосового трафика, например, джиттер. Конкретнее, *udp-jitter*, поэтому пишем ``` R4(config-ip-sla)#udp-jitter 192.168.200.1 55555 ``` В этой команде после указания вида проверки (*udp-jitter*) идет ip адрес, куда будут отсылаться пробы (т.е. меряем от нас до *192.168.200.1* – это лупбек на R1) и порт (от балды *55555*). Затем можно настроить частоту проверок (по умолчанию 60 секунд): ``` R4(config-ip-sla-jitter)#frequency 10 ``` и предельное значение, при превышении которого объект ip sla 1 рапортует о недоступности: ``` R4(config-ip-sla-jitter)#threshold 10 ``` Некоторые виды измерений в IP SLA требуют наличия “на той стороне” так называемого “ответчика” (responder), некоторые (например, FTP, HTTP, DHCP, DNS) нет. Наш *udp-jitter* требует, поэтому, прежде чем запускать измерения, нужно подготовить R1: ``` R1(config)#ip sla responder ``` Теперь нам нужно запустить сбор статистики. Командуем ``` R4(config)#ip sla schedule 1 start-time now life forever ``` Т.е. запускаем объект мониторинга 1 прямо сейчас и до конца дней. > Мы не можем менять параметры объекта, если запущен сбор статистики. Т.е. чтобы поменять, например, частоту проб, нам нужно сначала выключить сбор информации с него: **no ip sla schedule 1** Теперь уже можем посмотреть, что у нас там собирается: > R4#sh ip sla statistics 1\ > \ > Round Trip Time (RTT) for Index 1\ > Latest RTT: 36 milliseconds\ > Latest operation start time: \*00:39:01.531 UTC Fri Mar 1 2002\ > Latest operation return code: OK\ > RTT Values:\ > Number Of RTT: 10 RTT Min/Avg/Max: 19/36/52 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: 9\ > Number of DS Jitter Samples: 9\ > Source to Destination Jitter Min/Avg/Max: 0/5/20 milliseconds\ > Destination to Source Jitter Min/Avg/Max: 0/16/28 milliseconds\ > Packet Loss Values:\ > Loss Source to Destination: 0 Loss Destination to Source: 0\ > Out Of Sequence: 0 Tail Drop: 0\ > Packet Late Arrival: 0 Packet Skipped: 0\ > Voice Score Values:\ > Calculated Planning Impairment Factor (ICPIF): 0\ > Mean Opinion Score (MOS): 0\ > Number of successes: 12\ > Number of failures: 0\ > Operation time to live: Forever а также что мы там наконфигурировали > R4#sh ip sla conf\ > IP SLAs Infrastructure Engine-II\ > Entry number: 1\ > Owner:\ > Tag:\ > Type of operation to perform: udp-jitter\ > Target address/Source address: 192.168.200.1/0.0.0.0\ > Target port/Source port: 55555/0\ > Request size (ARR data portion): 32\ > Operation timeout (milliseconds): 5000\ > Packet Interval (milliseconds)/Number of packets: 20/10\ > Type Of Service parameters: 0x0\ > Verify data: No\ > Vrf Name:\ > Control Packets: enabled\ > Schedule:\ > Operation frequency (seconds): 10 (not considered if randomly scheduled)\ > Next Scheduled Start Time: Pending trigger\ > Group Scheduled: FALSE\ > Randomly Scheduled: FALSE\ > Life (seconds): 3600\ > Entry Ageout (seconds): never\ > Recurring (Starting Everyday): FALSE\ > Status of entry (SNMP RowStatus): Active\ > Threshold (milliseconds): 10\ > Distribution Statistics:\ > Number of statistic hours kept: 2\ > Number of statistic distribution buckets kept: 1\ > Statistic distribution interval (milliseconds): 4294967295\ > Enhanced History: Теперь настраиваем так называемый *track* (неправильный, но понятный перевод “отслеживатель”). Именно к его состоянию привязываются впоследствии действия в роут-мапе. В track можно выставить задержку переключения между состояниями, что позволяет решить проблему, когда у нас по одной неудачной пробе меняется маршрутизация, а по следующей, уже удачной, меняется обратно. Указываем номер track и к какому номеру объекта ip sla мы его подключаем (rtr 1): ``` R4(config)#track 1 rtr 1 ``` Настраиваем задержку: ``` R4(config-track)#delay up 10 down 15 ``` Это означает: если объект мониторинга упал и не поднялся в течение 15 секунд, переводим track в состояние **down**. Если объект был в состоянии down, но поднялся и находится в поднятом состоянии хотя бы 10 секунд, переводим track в состояние **up**.\ Следующим действием нам нужно привязать track к нашей роут-мапе. Напомню, стандартный путь от R5 к R1 идет через R2, но у нас имеется роут-мапа *BACK*, переназначающая стандартное положение вещей в случае, если источник R5: > R4#sh run | sec route-map\ > ip policy route-map BACK\ > route-map BACK permit 10\ > match ip address 100\ > set ip next-hop 192.168.3.3 Если мы привяжем наш мониторинг к этой мапе, заменив команду **set ip next-hop 192.168.3.3** на **set ip next-hop** ***verify-availability*** **192.168.3.3** ***10 track 1***, получим обратный нужному эффект: в случае падения трека (из-за превышения показателя джиттера в sla 1), мапа не будет отрабатываться (все будет идти согласно таблице маршрутизации), и наоборот, в случае нормальных значений, трек будет up, и трафик будет идти через R3. Как это работает: роутер видит, что пакет подпадает под условия match, но потом не сразу делает set, как в предыдущем примере с PBR, а промежуточным действием проверяет сначала состояние трека 1, а затем, если он поднят (up), уже делается set, если нет – переходит к следующей строчке роут-мапы. Для того, чтобы наша мапа заработала, как надо, нам нужно как-то инвертировать значение трека, т.е. когда джиттер большой, наш трек должен быть UP, и наоборот. В этом нам поможет такая штука, как track list. В IP SLA существует возможность объединять в треке список других треков (которые, по сути, выдают на выходе 1 или 0) и производить над ними логические операции OR или AND, а результатом этих операций будет состояние этого трека. Кроме этого, мы можем применить логическое отрицание к состоянию трека. Создаем трек-лист: ``` R4(config)#track 2 list boolean or ``` Единственным в этом “списке” будет логическое отрицание значения трека 1: ``` R4(config-track)#object 1 not ``` Теперь привязываем роут-мап к этому треку ``` R4(config)#route-map BACK R4(config-route-map)#no set ip next-hop 192.168.3.3 R4(config-route-map)#set ip next-hop verify-availability 192.168.3.3 10 tr 2 ``` Цифра 10 после адреса некстхопа – это его порядковый номер (sequence number). Мы можем, к примеру, использовать его так: ``` route-map BACK permit 10 match ip address 100 set ip next-hop verify-availability 192.168.3.3 10 track 1 set ip next-hop verify-availability 192.168.2.2 20 track 2 ``` Тут такая логика: выбираем трафик, подпадающий под ACL 100, затем идет промежуточная проверка track 1, если он up, ставим пакету некстхоп 192.168.3.3, если down, переходим к следующему порядковому номеру (20 в данном случае), опять же промежуточно проверяем состояние трека (уже другого, 2), в зависимости от результата, ставим некстхоп 192.168.2.2 или отправляем с миром (маршрутизироваться на общих основаниях). Давайте теперь немножко словами порассуждаем, что же мы такое накрутили: итак, измерения джиттера у нас идут от источника R4 к респондеру R1 по маршруту через R2. Максимальное допустимое значение джиттера на этом маршруте у нас – 10. В случае, если джиттер превышает это значение и держится на этом уровне 15 секунд, мы переключаем трафик, генерируемый R5, на маршрут через R3. Если джиттер падает ниже 10 и держится там минимум 10 секунд, пускаем трафик от R5 по стандартному маршруту. Попробуйте для закрепления материала найти, в каких командах задаются все эти значения. Итак, мы достигли цели: теперь, в случае ухудшения качества основного канала (ну, по крайней мере, значений udp-джиттера), мы переходим на резервный. Но что, если и там тоже *не очень*? Может, попробуем с помощью IP SLA решить и эту проблему? Попробуем выстроить логику того, что мы хотим сделать. Мы хотим перед переключением на резервный канал проверять, как у нас обстоит дело с джиттером на нем. Для этого нам нужно завести дополнительный объект мониторинга, который будет считать джиттер на пути R4-R3-R1, пусть это будет 2. Сделаем его аналогичным первому, с теми же значениями. Условием переключения на резервный канал тогда будет: объект 1 down **И** объект 2 up. Чтобы измерять джиттер не по основному каналу, придется пойти на хитрость: сделать loopback-интерфейсы на R1 и R4, прописать статические маршруты через R3 туда-обратно, и использовать эти адреса для объекта SLA 2. ``` R1(config)#int lo1 R1(config-if)#ip add 192.168.30.1 255.255.255.0 R1(config-if)#exit R1(config)#ip route 192.168.31.0 255.255.255.0 192.168.1.3 R3(config)#ip route 192.168.30.0 255.255.255.0 192.168.1.1 R3(config)#ip route 192.168.31.0 255.255.255.0 192.168.3.4 R4(config)#int lo0 R4(config-if)#ip add 192.168.31.4 255.255.255.0 R4(config-ip-sla-jitter)#exit R4(config)#ip sla 2 R4(config-ip-sla)#udp-jitter 192.168.30.1 55555 source-ip 192.168.31.4 R4(config-ip-sla-jitter)#threshold 10 R4(config-ip-sla-jitter)#frequency 10 R4(config-ip-sla-jitter)#exit R4(config)#ip route 192.168.30.0 255.255.255.0 192.168.3.3 R4(config)#ip sla schedule 2 start-time now life forever R4(config)#track 3 rtr 2 ``` Теперь меняем условие трека 2, к которому привязана роут-мапа: ``` R4(config)#track 2 list boolean and R4(config-track)#object 1 not R4(config-track)#object 3 ``` Вуаля, теперь трафик R5->R1 переключается на запасной маршрут только в том случае, если джиттер основного канала больше 10 и, в это же время, джиттер запасного меньше 10. В случае, если высокий джиттер наблюдается на обоих каналах, трафик идет по основному и молча страдает. Состояние трека можно привязать также к статическому маршруту: например, мы можем командой ip route 0.0.0.0 0.0.0.0 192.168.1.1 **track 1** сделать шлюзом по умолчанию 192.168.1.1, который будет связан с треком 1 (который, в свою очередь, может проверять наличие этого самого 192.168.1.1 в сети или измерять какие-нибудь важные характеристики качества связи с ним). В случае, если связанный трек падает, маршрут убирается из таблицы маршрутизации. Также будет полезным упомянуть, что информацию, получаемую через IP SLA, можно вытащить через SNMP, чтобы потом можно было ее хранить и анализировать где-нибудь в вашей системе мониторинга. Можно даже настроить [SNMP-traps.](http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsthresh.html#wp1043830) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://linkmeup.gitbook.io/sdsm/8.-bgp-i-ip-sla/4.-ip-sla/0.-nastroika.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.