forum.opennet.ru - "Отслеживание состояния track" (10)

"Отслеживание состояния 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ообщить модератору

Оглавление

Отслеживание состояния track, ShyLion, 12:23 , 28-Апр-18, (1)

Отслеживание состояния track, mik73, 15:02 , 28-Апр-18, (2)

Отслеживание состояния track, ShyLion, 12:42 , 03-Май-18, (5)

Отслеживание состояния track, mik73, 14:58 , 03-Май-18, (8)

Отслеживание состояния track, yur, 10:08 , 30-Апр-18, (3)

Отслеживание состояния track, mik73, 20:52 , 30-Апр-18, (4)

Отслеживание состояния track, mik73, 14:42 , 03-Май-18, (7)

Отслеживание состояния track, eek, 04:30 , 04-Май-18, (9)

Отслеживание состояния track, mik73, 17:20 , 04-Май-18, (10)

Отслеживание состояния track, ShyLion, 12:42 , 03-Май-18, (6)

Сообщения по теме [Сортировка по времени | 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-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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ообщить модератору