https://opennet.dev/openforum/vsluhforumID6/2293.html На маршрутизаторе Cisco есть два статических маршрута с балансировкой трафика, по каждому с помощью IPS SLA отслеживается деградация канала (при потере пакетов больше заданного привязанный к маршруту Track переводится в DOWN, меньше заданного - в Up).<br><br>ip cef<br>ip route 0.0.0.0 0.0.0.0 10.0.10.1 track 10<br>ip route 0.0.0.0 0.0.0.0 10.0.20.1 track 20<br><br>всё работает, всё бы хорошо, но получается слишком "жестко" - когда потери пакетов есть по обоим каналам, ложатся оба и связи нет совсем. Хочется сделать следующее:<br><br>Если возникают потери по первому каналу, то проверяем в каком состоянии track 20 (не положили ли уже второй маршрут), и если в Up, то переводим track 10 в Down - т.е. кладем маршрут, пусть весь трафик ходит по второму, где потерь нет. А вот если track 20 в Down (второй маршрут уже лежит), то оставляем track 10 в Up - пусть с хоть с потерями, но трафик продолжает ходить через первый маршрут. Ну и аналогично для track 2. Если же канал восстановился (ip sla дает приемлемое кол-во потерь), то соотве https://opennet.dev/openforum/vsluhforumID6/2293.html#10 Fri, 04 May 2018 14:20:15 GMT &gt; Хорошо, что у вас все получилось.<br>&gt; Если не затруднит сюда закиньте результат, для тех кто пойдет вашим путем. <br>&gt; Спасибо.<br><br>в базовом варианте вот так (значения кол-ва отправляемых пакетов, частоты тестирования и приемлемых потерь, выбираются, естественно, под задачу):<br><br>track 10 stub-object #track для управления маршрутом 1<br> default-state up<br>!<br>track 20 stub-object #track для управления маршрутом 1<br> default-state up<br><br><br>ip route 0.0.0.0 0.0.0.0 10.0.10.1 track 10 #маршрут 1<br>ip route 0.0.0.0 0.0.0.0 10.0.20.1 track 20 #маршрут 2<br><br><br>ip sla logging traps #пишем события sla в лог<br><br>ip sla 1#тест SLA для определения потерь пакетов на маршруте 1 (отправляяем 50 пакетов каждые 10 сек).<br> icmp-jitter 10.0.10.1 num-packets 50<br> frequency 10<br>ip sla schedule 1 life forever start-time now<br><br>ip sla 2#тест SLA для определения потерь пакетов на маршруте 2 (отправляяем 50 пакетов каждые 10 сек).<br> icmp-jitter 10.0.20.1 num-packets 50<br> frequency 10<br>ip sla schedule 2 life forever start-time no https://opennet.dev/openforum/vsluhforumID6/2293.html#9 Fri, 04 May 2018 01:30:00 GMT &gt;&gt;&gt; action 010 track read 20 <br>&gt;&gt;&gt; action 020 if $_track_state eq up <br>&gt; Спасибо еще раз!<br>&gt; Всё получилось. Пришлось, правда, маленько поизвращаться для отслеживания различных ситуаций. <br>&gt; Но работает.<br><br>Хорошо, что у вас все получилось.<br><br>Если не затруднит сюда закиньте результат, для тех кто пойдет вашим путем.<br><br>Спасибо.<br> https://opennet.dev/openforum/vsluhforumID6/2293.html#8 Thu, 03 May 2018 11:58:15 GMT &gt;&gt;&gt; Самое просто выбрать один из маршрутов как главный и добавить его без <br>&gt;&gt;&gt; трекинга с большей админ-дистанцией, например 10 <br>&gt;&gt; Так можно, но не кажется надежным. Маршрут может деградировать вплоть до пропадания <br>&gt;&gt; трафика, и если выбранный в качестве "главного" окажется на <br>&gt;&gt; данный момент совсем лежащим, то выйдет только хуже.<br>&gt; Как вы собрались определять степень "совсем лежащего" ?<br>&gt; Добавьте еще пару трекингов с менее критичными показателями и на них еще <br>&gt; пару маршрутов с большей админ-дистанцией, в таком случае. Ну и в <br>&gt; конце как я сказал, без трекинга.<br><br>Определять степень лежачести как раз просто. Например, по различению событий "Threshold exceeded for packetLoss" и "Threshold Occurred for timeout" - работает с потерями или совсем лёг. Можно и доп. градации ввести (несколько тестов с разным Thresold для packet loss)- это всё можно улучшать до бесконечности.<br><br>Просто если в конце добавить один из двух существующих маршрут без трекинга - то где гарантия, что именно этот маршрут не о https://opennet.dev/openforum/vsluhforumID6/2293.html#7 Thu, 03 May 2018 11:42:46 GMT &gt;&gt; action 010 track read 20 <br>&gt;&gt; action 020 if $_track_state eq up <br><br>Спасибо еще раз!<br>Всё получилось. Пришлось, правда, маленько поизвращаться для отслеживания различных ситуаций. Но работает.<br><br><br><br> https://opennet.dev/openforum/vsluhforumID6/2293.html#6 Thu, 03 May 2018 09:42:45 GMT &gt; action 040 ip route 0.0.0.0 0.0.0.0 10.0.10.2 <br>&gt; action 050 no ip route 0.0.0.0 0.0.0.0 10.0.10.1 <br>&gt; action 060 cli command "exit" <br><br>Костыли "mikrotik-way".<br> https://opennet.dev/openforum/vsluhforumID6/2293.html#5 Thu, 03 May 2018 09:42:05 GMT &gt;&gt; Самое просто выбрать один из маршрутов как главный и добавить его без <br>&gt;&gt; трекинга с большей админ-дистанцией, например 10 <br>&gt; Так можно, но не кажется надежным. Маршрут может деградировать вплоть до пропадания <br>&gt; трафика, и если выбранный в качестве "главного" окажется на <br>&gt; данный момент совсем лежащим, то выйдет только хуже.<br><br>Как вы собрались определять степень "совсем лежащего" ?<br>Добавьте еще пару трекингов с менее критичными показателями и на них еще пару маршрутов с большей админ-дистанцией, в таком случае. Ну и в конце как я сказал, без трекинга.<br> https://opennet.dev/openforum/vsluhforumID6/2293.html#4 Mon, 30 Apr 2018 17:52:50 GMT &gt; action 010 track read 20 <br>&gt; action 020 if $_track_state eq up <br><br>Спасибо!<br>Ровно этой конструкции мне и не хватало. Все-таки вы более настоящий сварщик, чем я :-)<br>Попробую после праздников, о результате отпишусь.<br> https://opennet.dev/openforum/vsluhforumID6/2293.html#3 Mon, 30 Apr 2018 07:08:55 GMT &gt; Если возникают потери по первому каналу, то проверяем в каком состоянии track <br>&gt; 20 (не положили ли уже второй маршрут), и если в Up, <br>&gt; то переводим track 10 в Down - т.е. кладем маршрут, пусть <br>&gt; весь трафик ходит по второму, где потерь нет. А вот если <br>&gt; track 20 в Down (второй маршрут уже лежит), то оставляем track <br>&gt; 10 в Up - пусть с хоть с потерями, но трафик <br>&gt; продолжает ходить через первый маршрут. Ну и аналогично для track 2. <br>&gt; Если же канал восстановился (ip sla дает приемлемое кол-во потерь), то <br>&gt; соответствующий track должен сразу переходить в Up, независимо от состояния соседа. <br><br>Я в EEM сварщик ненастоящий, но мне кажется, что никто не мешает вам сделать как-то так:<br><br>event manager applet channel_10_down<br>event track 10 state down<br>action 010 track read 20<br>action 020 if $_track_state eq up<br>action 030 cli command "conf t"<br>action 040 ip route 0.0.0.0 0.0.0.0 10.0.10.2<br>action 050 no ip route 0.0.0.0 0.0.0.0 10.0.10.1<br>action 060 cli command "exit"<br>action 070 else<br>action 080 sy https://opennet.dev/openforum/vsluhforumID6/2293.html#2 Sat, 28 Apr 2018 12:02:29 GMT &gt; Самое просто выбрать один из маршрутов как главный и добавить его без <br>&gt; трекинга с большей админ-дистанцией, например 10 <br><br>Так можно, но не кажется надежным. Маршрут может деградировать вплоть до пропадания трафика, и если выбранный в качестве "главного" окажется на данный момент совсем лежащим, то выйдет только хуже. <br><br>