0.-nastroika.md
1 # Настройка 2 3 Без лишних слов, сразу к настройке. Для начала, нам нужно сказать, что мы хотим мониторить. Создаем объект мониторинга, назначаем ему номер: 4 5 ```text 6 R4(config)#ip sla 1 7 ``` 8 9 Так-с, что мы тут можем мониторить? 10 11 > R4\(config-ip-sla\)\#? 12 > IP SLAs entry configuration commands: 13 > dhcp DHCP Operation 14 > dns DNS Query Operation 15 > exit Exit Operation Configuration 16 > frame-relay Frame-relay Operation 17 > ftp FTP Operation 18 > http HTTP Operation 19 > icmp-echo ICMP Echo Operation 20 > icmp-jitter ICMP Jitter Operation 21 > mpls MPLS Operation 22 > path-echo Path Discovered ICMP Echo Operation 23 > path-jitter Path Discovered ICMP Jitter Operation 24 > slm SLM Operation 25 > tcp-connect TCP Connect Operation 26 > udp-echo UDP Echo Operation 27 > udp-jitter UDP Jitter Operation 28 > voip Voice Over IP Operation 29 > 30 > Нужно сказать, что синтаксис команд, относящихся к IP SLA, претерпел некоторые изменения: начиная с IOS 12.4\(4\)T он такой, как в статье, до этого некоторые команды писались по другому. Например, вместо ip sla 1 было rtr 1 или вместо ip sla responder – rtr responder 31 32 Как видите, список внушительный, поэтому останавливаться не будем, для интересующихся есть подробная [статья](http://www.cisco.com/en/US/technologies/tk648/tk362/tk920/technologies_white_paper09186a00802d5efe_ps6602_Products_White_Paper.html) на циско.ком. 33 34 Обычно, работу IP SLA рассматривают на простейшем примере _icmp-echo_. То есть, в случае, если мы можем пинговать тот конец линии, трафик идет по ней, если не можем – по другой. Но мы пойдем путем чуть посложнее. Итак, нас интересуют характеристики канала, важные для голосового трафика, например, джиттер. Конкретнее, _udp-jitter_, поэтому пишем 35 36 ```text 37 R4(config-ip-sla)#udp-jitter 192.168.200.1 55555 38 ``` 39 40 В этой команде после указания вида проверки \(_udp-jitter_\) идет ip адрес, куда будут отсылаться пробы \(т.е. меряем от нас до _192.168.200.1_ – это лупбек на R1\) и порт \(от балды _55555_\). Затем можно настроить частоту проверок \(по умолчанию 60 секунд\): 41 42 ```text 43 R4(config-ip-sla-jitter)#frequency 10 44 ``` 45 46 и предельное значение, при превышении которого объект ip sla 1 рапортует о недоступности: 47 48 ```text 49 R4(config-ip-sla-jitter)#threshold 10 50 ``` 51 52 Некоторые виды измерений в IP SLA требуют наличия “на той стороне” так называемого “ответчика” \(responder\), некоторые \(например, FTP, HTTP, DHCP, DNS\) нет. Наш _udp-jitter_ требует, поэтому, прежде чем запускать измерения, нужно подготовить R1: 53 54 ```text 55 R1(config)#ip sla responder 56 ``` 57 58 Теперь нам нужно запустить сбор статистики. Командуем 59 60 ```text 61 R4(config)#ip sla schedule 1 start-time now life forever 62 ``` 63 64 Т.е. запускаем объект мониторинга 1 прямо сейчас и до конца дней. 65 66 > Мы не можем менять параметры объекта, если запущен сбор статистики. Т.е. чтобы поменять, например, частоту проб, нам нужно сначала выключить сбор информации с него: **no ip sla schedule 1** 67 68 Теперь уже можем посмотреть, что у нас там собирается: 69 70 > R4\#sh ip sla statistics 1 71 > 72 > Round Trip Time \(RTT\) for Index 1 73 > Latest RTT: 36 milliseconds 74 > Latest operation start time: \*00:39:01.531 UTC Fri Mar 1 2002 75 > Latest operation return code: OK 76 > RTT Values: 77 > Number Of RTT: 10 RTT Min/Avg/Max: 19/36/52 milliseconds 78 > Latency one-way time: 79 > Number of Latency one-way Samples: 0 80 > Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds 81 > Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds 82 > Jitter Time: 83 > Number of SD Jitter Samples: 9 84 > Number of DS Jitter Samples: 9 85 > Source to Destination Jitter Min/Avg/Max: 0/5/20 milliseconds 86 > Destination to Source Jitter Min/Avg/Max: 0/16/28 milliseconds 87 > Packet Loss Values: 88 > Loss Source to Destination: 0 Loss Destination to Source: 0 89 > Out Of Sequence: 0 Tail Drop: 0 90 > Packet Late Arrival: 0 Packet Skipped: 0 91 > Voice Score Values: 92 > Calculated Planning Impairment Factor \(ICPIF\): 0 93 > Mean Opinion Score \(MOS\): 0 94 > Number of successes: 12 95 > Number of failures: 0 96 > Operation time to live: Forever 97 98 а также что мы там наконфигурировали 99 100 > R4\#sh ip sla conf 101 > IP SLAs Infrastructure Engine-II 102 > Entry number: 1 103 > Owner: 104 > Tag: 105 > Type of operation to perform: udp-jitter 106 > Target address/Source address: 192.168.200.1/0.0.0.0 107 > Target port/Source port: 55555/0 108 > Request size \(ARR data portion\): 32 109 > Operation timeout \(milliseconds\): 5000 110 > Packet Interval \(milliseconds\)/Number of packets: 20/10 111 > Type Of Service parameters: 0x0 112 > Verify data: No 113 > Vrf Name: 114 > Control Packets: enabled 115 > Schedule: 116 > Operation frequency \(seconds\): 10 \(not considered if randomly scheduled\) 117 > Next Scheduled Start Time: Pending trigger 118 > Group Scheduled: FALSE 119 > Randomly Scheduled: FALSE 120 > Life \(seconds\): 3600 121 > Entry Ageout \(seconds\): never 122 > Recurring \(Starting Everyday\): FALSE 123 > Status of entry \(SNMP RowStatus\): Active 124 > Threshold \(milliseconds\): 10 125 > Distribution Statistics: 126 > Number of statistic hours kept: 2 127 > Number of statistic distribution buckets kept: 1 128 > Statistic distribution interval \(milliseconds\): 4294967295 129 > Enhanced History: 130 131 Теперь настраиваем так называемый _track_ \(неправильный, но понятный перевод “отслеживатель”\). Именно к его состоянию привязываются впоследствии действия в роут-мапе. В track можно выставить задержку переключения между состояниями, что позволяет решить проблему, когда у нас по одной неудачной пробе меняется маршрутизация, а по следующей, уже удачной, меняется обратно. Указываем номер track и к какому номеру объекта ip sla мы его подключаем \(rtr 1\): 132 133 ```text 134 R4(config)#track 1 rtr 1 135 ``` 136 137 Настраиваем задержку: 138 139 ```text 140 R4(config-track)#delay up 10 down 15 141 ``` 142 143 Это означает: если объект мониторинга упал и не поднялся в течение 15 секунд, переводим track в состояние **down**. Если объект был в состоянии down, но поднялся и находится в поднятом состоянии хотя бы 10 секунд, переводим track в состояние **up**. 144 Следующим действием нам нужно привязать track к нашей роут-мапе. Напомню, стандартный путь от R5 к R1 идет через R2, но у нас имеется роут-мапа _BACK_, переназначающая стандартное положение вещей в случае, если источник R5: 145 146 > R4\#sh run \| sec route-map 147 > ip policy route-map BACK 148 > route-map BACK permit 10 149 > match ip address 100 150 > set ip next-hop 192.168.3.3 151 152 Если мы привяжем наш мониторинг к этой мапе, заменив команду **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. 153 154 Как это работает: роутер видит, что пакет подпадает под условия match, но потом не сразу делает set, как в предыдущем примере с PBR, а промежуточным действием проверяет сначала состояние трека 1, а затем, если он поднят \(up\), уже делается set, если нет – переходит к следующей строчке роут-мапы. 155 156 Для того, чтобы наша мапа заработала, как надо, нам нужно как-то инвертировать значение трека, т.е. когда джиттер большой, наш трек должен быть UP, и наоборот. В этом нам поможет такая штука, как track list. В IP SLA существует возможность объединять в треке список других треков \(которые, по сути, выдают на выходе 1 или 0\) и производить над ними логические операции OR или AND, а результатом этих операций будет состояние этого трека. Кроме этого, мы можем применить логическое отрицание к состоянию трека. Создаем трек-лист: 157 158 ```text 159 R4(config)#track 2 list boolean or 160 ``` 161 162 Единственным в этом “списке” будет логическое отрицание значения трека 1: 163 164 ```text 165 R4(config-track)#object 1 not 166 ``` 167 168 Теперь привязываем роут-мап к этому треку 169 170 ```text 171 R4(config)#route-map BACK 172 R4(config-route-map)#no set ip next-hop 192.168.3.3 173 R4(config-route-map)#set ip next-hop verify-availability 192.168.3.3 10 tr 2 174 ``` 175 176 Цифра 10 после адреса некстхопа – это его порядковый номер \(sequence number\). Мы можем, к примеру, использовать его так: 177 178 ```text 179 route-map BACK permit 10 180 match ip address 100 181 set ip next-hop verify-availability 192.168.3.3 10 track 1 182 set ip next-hop verify-availability 192.168.2.2 20 track 2 183 ``` 184 185 Тут такая логика: выбираем трафик, подпадающий под ACL 100, затем идет промежуточная проверка track 1, если он up, ставим пакету некстхоп 192.168.3.3, если down, переходим к следующему порядковому номеру \(20 в данном случае\), опять же промежуточно проверяем состояние трека \(уже другого, 2\), в зависимости от результата, ставим некстхоп 192.168.2.2 или отправляем с миром \(маршрутизироваться на общих основаниях\). 186 187 Давайте теперь немножко словами порассуждаем, что же мы такое накрутили: итак, измерения джиттера у нас идут от источника R4 к респондеру R1 по маршруту через R2. Максимальное допустимое значение джиттера на этом маршруте у нас – 10. В случае, если джиттер превышает это значение и держится на этом уровне 15 секунд, мы переключаем трафик, генерируемый R5, на маршрут через R3. Если джиттер падает ниже 10 и держится там минимум 10 секунд, пускаем трафик от R5 по стандартному маршруту. Попробуйте для закрепления материала найти, в каких командах задаются все эти значения. 188 189 Итак, мы достигли цели: теперь, в случае ухудшения качества основного канала \(ну, по крайней мере, значений udp-джиттера\), мы переходим на резервный. Но что, если и там тоже _не очень_? Может, попробуем с помощью IP SLA решить и эту проблему? 190 191 Попробуем выстроить логику того, что мы хотим сделать. Мы хотим перед переключением на резервный канал проверять, как у нас обстоит дело с джиттером на нем. Для этого нам нужно завести дополнительный объект мониторинга, который будет считать джиттер на пути R4-R3-R1, пусть это будет 2. Сделаем его аналогичным первому, с теми же значениями. Условием переключения на резервный канал тогда будет: объект 1 down **И** объект 2 up. Чтобы измерять джиттер не по основному каналу, придется пойти на хитрость: сделать loopback-интерфейсы на R1 и R4, прописать статические маршруты через R3 туда-обратно, и использовать эти адреса для объекта SLA 2. 192 193 ```text 194 R1(config)#int lo1 195 R1(config-if)#ip add 192.168.30.1 255.255.255.0 196 R1(config-if)#exit 197 R1(config)#ip route 192.168.31.0 255.255.255.0 192.168.1.3 198 199 R3(config)#ip route 192.168.30.0 255.255.255.0 192.168.1.1 200 R3(config)#ip route 192.168.31.0 255.255.255.0 192.168.3.4 201 202 R4(config)#int lo0 203 R4(config-if)#ip add 192.168.31.4 255.255.255.0 204 R4(config-ip-sla-jitter)#exit 205 R4(config)#ip sla 2 206 R4(config-ip-sla)#udp-jitter 192.168.30.1 55555 source-ip 192.168.31.4 207 R4(config-ip-sla-jitter)#threshold 10 208 R4(config-ip-sla-jitter)#frequency 10 209 R4(config-ip-sla-jitter)#exit 210 R4(config)#ip route 192.168.30.0 255.255.255.0 192.168.3.3 211 R4(config)#ip sla schedule 2 start-time now life forever 212 R4(config)#track 3 rtr 2 213 ``` 214 215 Теперь меняем условие трека 2, к которому привязана роут-мапа: 216 217 ```text 218 R4(config)#track 2 list boolean and 219 R4(config-track)#object 1 not 220 R4(config-track)#object 3 221 ``` 222 223 Вуаля, теперь трафик R5->R1 переключается на запасной маршрут только в том случае, если джиттер основного канала больше 10 и, в это же время, джиттер запасного меньше 10. В случае, если высокий джиттер наблюдается на обоих каналах, трафик идет по основному и молча страдает. 224 225 Состояние трека можно привязать также к статическому маршруту: например, мы можем командой 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 в сети или измерять какие-нибудь важные характеристики качества связи с ним\). В случае, если связанный трек падает, маршрут убирается из таблицы маршрутизации. 226 227 Также будет полезным упомянуть, что информацию, получаемую через IP SLA, можно вытащить через SNMP, чтобы потом можно было ее хранить и анализировать где-нибудь в вашей системе мониторинга. Можно даже настроить [SNMP-traps.](http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsthresh.html#wp1043830) 228