https://slinkov.ru/openforum/vsluhforumID6/23638.html есть 3 циски 1800 серии независимые между собой. на них настроено резервирование ISP через sla и track. конфиг такой <br><br>track 1 ip sla 1 reachability<br>!<br>track 2 ip sla 2 reachability<br><br>ip route 0.0.0.0 0.0.0.0 2.2.2.2 track 1<br>ip route 0.0.0.0 0.0.0.0 3.3.3.3 254<br><br><br>ip nat inside source route-map ISP1 interface FastEthernet0/0 overload<br>ip nat inside source route-map ISP2 interface FastEthernet0/1 overload<br><br><br>ip sla 1<br> icmp-echo 8.8.8.8 source-interface FastEthernet0/0<br> frequency 10<br>ip sla schedule 1 life forever start-time now<br>ip sla 2<br> icmp-echo 8.8.8.8 source-interface FastEthernet0/1<br> frequency 10<br>ip sla schedule 2 life forever start-time now<br><br><br>route-map ISP2 permit 10<br> match ip address 110<br> match interface FastEthernet0/1<br>!<br>route-map ISP1 permit 10<br> match ip address 110<br> match interface FastEthernet0/0<br><br>схема работает день/два. После чего циска решает что основной канал упал и переходит на резервный. при этом это происходит на всех трех цисках с завидной периодичностью. при этом https://slinkov.ru/openforum/vsluhforumID6/23638.html#4 Sat, 28 Apr 2012 08:55:28 GMT &gt;[оверквотинг удален]<br>&gt; переходит на резервный. при этом это происходит на всех трех цисках <br>&gt; с завидной периодичностью. при этом ни рестарт трека, ни перезагрузка не <br>&gt; позволяют вернуться на основной канал. помогает только прописывание маршрута ip route <br>&gt; 0.0.0.0 0.0.0.0 2.2.2.2 После того как вводишь эту строчку Track1 поднимается <br>&gt; в UP. Потом этот маршрут удаляю и циска опять какое то <br>&gt; время работает на ISP1.<br>&gt; проблем с оператором связи не наблюдается в момент перехода Track1 в Down, <br>&gt; т.к. оборудование находящееся на "соседнем" публичном IP работает отлично.<br>&gt; подскажите в чем может быть проблема. Пробовали менять гугловский DNS (8.8.8.8) на <br>&gt; другие ресурсы - ситуация не меняется.<br><br>а почему бы вам неиспользовать GLBP или HSRP? будет возможность балансировки траффика. ipsla если они независимы друг от друга.<br> https://slinkov.ru/openforum/vsluhforumID6/23638.html#3 Wed, 21 Mar 2012 10:19:43 GMT удалить track 2 и ip sla 2<br><br>ip route 0.0.0.0 0.0.0.0 2.2.2.2 10 track 1 <br>ip route 0.0.0.0 0.0.0.0 3.3.3.3 20<br>(может и не имеет отношения к проблеме, но я обычно такие метрики пишу)<br><br>так же бывает полезно что-то вроде<br>track 1 ip sla 1 reachability<br> delay down 25 up 25<br><br>и еще<br>ip route 8.8.8.8 255.255.255.255 2.2.2.2 permanent<br><br> https://slinkov.ru/openforum/vsluhforumID6/23638.html#2 Tue, 20 Mar 2012 16:57:10 GMT &gt;<br>&gt; Poprobuite track blizhaeishego hopa, GW, v vashem sluchae 2.2.2.2 <br>&gt; nabludalis pohozhie problemi pri bolshom TTR <br><br>В этом случае все работает хорошо. Но смысла в мониторинге нет, т.к. при падении ISP1 гейтвей 2.2.2.2 остается доступным.<br><br> https://slinkov.ru/openforum/vsluhforumID6/23638.html#1 Tue, 20 Mar 2012 15:46:03 GMT &gt;[оверквотинг удален]<br>&gt; переходит на резервный. при этом это происходит на всех трех цисках <br>&gt; с завидной периодичностью. при этом ни рестарт трека, ни перезагрузка не <br>&gt; позволяют вернуться на основной канал. помогает только прописывание маршрута ip route <br>&gt; 0.0.0.0 0.0.0.0 2.2.2.2 После того как вводишь эту строчку Track1 поднимается <br>&gt; в UP. Потом этот маршрут удаляю и циска опять какое то <br>&gt; время работает на ISP1.<br>&gt; проблем с оператором связи не наблюдается в момент перехода Track1 в Down, <br>&gt; т.к. оборудование находящееся на "соседнем" публичном IP работает отлично.<br>&gt; подскажите в чем может быть проблема. Пробовали менять гугловский DNS (8.8.8.8) на <br>&gt; другие ресурсы - ситуация не меняется.<br><br>Poprobuite track blizhaeishego hopa, GW, v vashem sluchae 2.2.2.2<br>nabludalis pohozhie problemi pri bolshom TTR<br><br>