The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]



"Отслеживание состояния track"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Маршрутизаторы CISCO и др. оборудование. (Мониторинг, статистика, SNMP)
Изначальное сообщение [ Отслеживать ]

"Отслеживание состояния track"  +/
Сообщение от mik73 (ok) on 28-Апр-18, 11:19 
На маршрутизаторе Cisco есть два статических маршрута с балансировкой трафика, по каждому с помощью IPS SLA отслеживается деградация канала (при потере пакетов больше заданного привязанный к маршруту  Track переводится в DOWN, меньше заданного - в Up).

ip cef
ip route 0.0.0.0 0.0.0.0 10.0.10.1 track 10
ip route 0.0.0.0 0.0.0.0 10.0.20.1 track 20

всё работает, всё бы хорошо, но получается слишком "жестко" - когда потери пакетов есть по обоим каналам, ложатся оба и связи нет совсем. Хочется сделать следующее:

Если возникают потери по первому каналу, то проверяем в каком состоянии track 20 (не положили ли уже второй маршрут), и если в Up, то переводим track 10 в Down - т.е. кладем маршрут, пусть весь трафик ходит по второму, где потерь нет. А вот если track 20 в Down (второй маршрут уже лежит), то оставляем track 10 в Up - пусть с хоть с потерями, но трафик продолжает ходить через первый маршрут. Ну и аналогично для track 2. Если же канал восстановился (ip sla дает приемлемое кол-во потерь), то соответствующий track должен сразу переходить в Up, независимо от состояния соседа.

Потратил некоторое время, пока нашел только возможность отслеживать (через EEM) событие "изменение в состоянии track" (переходы Up - Down). Но мне нужно не изменение, а текущее состояние трека (Up или Down). В апплетах EEM есть действие (action) track read, но где взять и куда можно применить результат этого действия - непонятно.

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Отслеживание состояния track"  +/
Сообщение от ShyLion (ok) on 28-Апр-18, 12:23 
Самое просто выбрать один из маршрутов как главный и добавить его без трекинга с большей админ-дистанцией, например 10

ip route 0.0.0.0 0.0.0.0 10.0.10.1 10

тогда если первые два упадут будет использоваться этот.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Отслеживание состояния track"  +/
Сообщение от mik73 (ok) on 28-Апр-18, 15:02 
> Самое просто выбрать один из маршрутов как главный и добавить его без
> трекинга с большей админ-дистанцией, например 10

Так можно, но не кажется надежным. Маршрут может деградировать вплоть до пропадания трафика,  и если выбранный в качестве "главного"  окажется на данный момент совсем лежащим, то выйдет только хуже.  

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "Отслеживание состояния track"  +/
Сообщение от ShyLion (ok) on 03-Май-18, 12:42 
>> Самое просто выбрать один из маршрутов как главный и добавить его без
>> трекинга с большей админ-дистанцией, например 10
> Так можно, но не кажется надежным. Маршрут может деградировать вплоть до пропадания
> трафика,  и если выбранный в качестве "главного"  окажется на
> данный момент совсем лежащим, то выйдет только хуже.

Как вы собрались определять степень "совсем лежащего" ?
Добавьте еще пару трекингов с менее критичными показателями и на них еще пару маршрутов с большей админ-дистанцией, в таком случае. Ну и в конце как я сказал, без трекинга.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

8. "Отслеживание состояния track"  +/
Сообщение от mik73 (ok) on 03-Май-18, 14:58 
>>> Самое просто выбрать один из маршрутов как главный и добавить его без
>>> трекинга с большей админ-дистанцией, например 10
>> Так можно, но не кажется надежным. Маршрут может деградировать вплоть до пропадания
>> трафика,  и если выбранный в качестве "главного"  окажется на
>> данный момент совсем лежащим, то выйдет только хуже.
> Как вы собрались определять степень "совсем лежащего" ?
> Добавьте еще пару трекингов с менее критичными показателями и на них еще
> пару маршрутов с большей админ-дистанцией, в таком случае. Ну и в
> конце как я сказал, без трекинга.

Определять степень лежачести как раз просто. Например, по различению событий "Threshold exceeded for packetLoss" и "Threshold Occurred for timeout" - работает с потерями или совсем лёг. Можно и доп. градации ввести (несколько тестов с разным Thresold для packet loss)- это всё можно улучшать до бесконечности.

Просто если в конце добавить один из двух существующих маршрут без трекинга - то где гарантия, что именно этот маршрут не окажется "самым лежащим" из двух, когда оба деградировали?
Вопрос был именно в чтении текущего состояния трека из EEM, чтобы на основе этого принимать решение - положить маршрут, на который пришел аларм, или не класть, потому что второй в данный момент уже положен? Или, может, положить этот, но при этом поднять второй (если наворачивать еще и "по степени лежачести").

В любом случае надо читать состояние маршрутов (то есть track'ов). Я просто не дошел до конструкции "action  if $_track_state eq ...". С ней всё просто. Дальше можно просто управлять track'ами на основе их состояния и пришедших алармов, лазить в cli не обязательно :-)


Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

3. "Отслеживание состояния track"  +/
Сообщение от yur (??) on 30-Апр-18, 10:08 
> Если возникают потери по первому каналу, то проверяем в каком состоянии track
> 20 (не положили ли уже второй маршрут), и если в Up,
> то переводим track 10 в Down - т.е. кладем маршрут, пусть
> весь трафик ходит по второму, где потерь нет. А вот если
> track 20 в Down (второй маршрут уже лежит), то оставляем track
> 10 в Up - пусть с хоть с потерями, но трафик
> продолжает ходить через первый маршрут. Ну и аналогично для track 2.
> Если же канал восстановился (ip sla дает приемлемое кол-во потерь), то
> соответствующий track должен сразу переходить в Up, независимо от состояния соседа.

Я в EEM сварщик ненастоящий, но мне кажется, что никто не мешает вам сделать как-то так:

event manager applet channel_10_down
event track 10 state down
action 010 track read 20
action 020 if $_track_state eq up
action 030 cli command "conf t"
action 040 ip route 0.0.0.0 0.0.0.0 10.0.10.2
action 050 no ip route 0.0.0.0 0.0.0.0 10.0.10.1
action 060 cli command "exit"
action 070 else
action 080 syslog msg "Vse propalo!!!!"
action 090 end

и аналогично для остальных ситуаций.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Отслеживание состояния track"  +/
Сообщение от mik73 (ok) on 30-Апр-18, 20:52 
> action 010 track read 20
> action 020 if $_track_state eq up

Спасибо!
Ровно этой конструкции мне и не хватало. Все-таки вы более настоящий сварщик, чем я :-)
Попробую после праздников, о результате отпишусь.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

7. "Отслеживание состояния track"  +/
Сообщение от mik73 (ok) on 03-Май-18, 14:42 
>> action 010 track read 20
>> action 020 if $_track_state eq up

Спасибо еще раз!
Всё получилось. Пришлось, правда, маленько поизвращаться для отслеживания различных ситуаций. Но работает.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

9. "Отслеживание состояния track"  +/
Сообщение от eek (ok) on 04-Май-18, 04:30 
>>> action 010 track read 20
>>> action 020 if $_track_state eq up
> Спасибо еще раз!
> Всё получилось. Пришлось, правда, маленько поизвращаться для отслеживания различных ситуаций.
> Но работает.

Хорошо, что у вас все получилось.

Если не затруднит сюда закиньте результат, для тех кто пойдет вашим путем.

Спасибо.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

10. "Отслеживание состояния track"  +/
Сообщение от mik73 (ok) on 04-Май-18, 17:20 
> Хорошо, что у вас все получилось.
> Если не затруднит сюда закиньте результат, для тех кто пойдет вашим путем.
> Спасибо.

в базовом варианте вот так (значения кол-ва отправляемых пакетов, частоты тестирования и приемлемых потерь, выбираются, естественно, под задачу):

track 10 stub-object #track для управления маршрутом 1
default-state up
!
track 20 stub-object #track для управления маршрутом 1    
default-state up


ip route 0.0.0.0 0.0.0.0 10.0.10.1 track 10 #маршрут 1
ip route 0.0.0.0 0.0.0.0 10.0.20.1 track 20 #маршрут 2


ip sla logging traps                 #пишем события sla в лог

ip sla 1                    #тест SLA для определения потерь пакетов на маршруте 1 (отправляяем 50 пакетов каждые 10 сек).
icmp-jitter 10.0.10.1 num-packets 50
frequency 10
ip sla schedule 1 life forever start-time now

ip sla 2                    #тест SLA для определения потерь пакетов на маршруте 2 (отправляяем 50 пакетов каждые 10 сек).
icmp-jitter 10.0.20.1 num-packets 50
frequency 10
ip sla schedule 2 life forever start-time now

ip sla reaction-configuration 1 react packetLoss threshold-value 1 2 threshold-type immediate action-type trapOnly #трапы "есть потери" если потеряно больше 2-х пакетов\
ip sla reaction-configuration 2 react packetLoss threshold-value 1 2 threshold-type immediate action-type trapOnly # и "нет потерь" если меньше 1-го (т.е. совсем нет)

ip sla enable reaction-alerts #отправляем события sla приложениям


event manager applet D10 # апплет, кладущий маршрут 1 когда есть потери
event syslog pattern "SLAs\(1\): Threshold exceeded for packetLoss"    #получили от sla 1 сообщение "есть потери" (экранировать скобки надо потому что метасимвол и иначе не распознается)
action D10.1 track read 20                            #проверили состояние маршрута 2 (track 20)
action D10.2 if $_track_state eq up                        #если маршрут 20 активен (track 20 в up)
action D10.3  track set 10 state down                        #то можно положить маршрут 1, кладём (переводим track 10 в down)
action D10.4 end

event manager applet U10 # апплет, поднимающий маршрут 1 когда потери исчезли                        
event syslog pattern "SLAs\(1\): Threshold below for packetLoss"    #получили от sla 1 сообщение "нет потерь"
action U10.2 track set 10 state up                        # поlняли маршрут 1 (перевели track 10 в Up)

#далее аналогичные апплеты для маршрута 2

дальше можно по аналогии наворачивать более сложные варианты путем создания доп. тестов и/или треков и проверки их состояния  - несколько градаций потери пакетов, событие "Timeout" (канал лежит совсем), проверка при поднятии канала (пропадании потерь), есть ли потери на соседнем и не положить ли теперь его... С этим еще играюсь.


Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

6. "Отслеживание состояния track"  +/
Сообщение от ShyLion (ok) on 03-Май-18, 12:42 
> action 040 ip route 0.0.0.0 0.0.0.0 10.0.10.2
> action 050 no ip route 0.0.0.0 0.0.0.0 10.0.10.1
> action 060 cli command "exit"

Костыли "mikrotik-way".

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема


  Закладки на сайте
  Проследить за страницей
Created 1996-2018 by Maxim Chirkov  
ДобавитьПоддержатьВебмастеруГИД  
Hosting by Ihor