> For the complete documentation index, see [llms.txt](https://linkmeup.gitbook.io/sdsm/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://linkmeup.gitbook.io/sdsm/8.-bgp-i-ip-sla/4.-ip-sla/0.-nastroika.md). # Настройка Без лишних слов, сразу к настройке. Для начала, нам нужно сказать, что мы хотим мониторить. Создаем объект мониторинга, назначаем ему номер: ``` 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)