есть 3 циски 1800 серии независимые между собой. на них настроено резервирование ISP через sla и track. конфиг такой

track 1 ip sla 1 reachability
!
track 2 ip sla 2 reachability

ip route 0.0.0.0 0.0.0.0 2.2.2.2 track 1
ip route 0.0.0.0 0.0.0.0 3.3.3.3 254

ip nat inside source route-map ISP1 interface FastEthernet0/0 overload
ip nat inside source route-map ISP2 interface FastEthernet0/1 overload

ip sla 1
icmp-echo 8.8.8.8 source-interface FastEthernet0/0
frequency 10
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 8.8.8.8 source-interface FastEthernet0/1
frequency 10
ip sla schedule 2 life forever start-time now

route-map ISP2 permit 10
match ip address 110
match interface FastEthernet0/1
!
route-map ISP1 permit 10
match ip address 110
match interface FastEthernet0/0

схема работает день/два. После чего циска решает что основной канал упал и переходит на резервный. при этом это происходит на всех трех цисках с завидной периодичностью. при этом ни рестарт трека, ни перезагрузка не позволяют вернуться на основной канал. помогает только прописывание маршрута ip route 0.0.0.0 0.0.0.0 2.2.2.2 После того как вводишь эту строчку Track1 поднимается в UP. Потом этот маршрут удаляю и циска опять какое то время работает на ISP1.

проблем с оператором связи не наблюдается в момент перехода Track1 в Down, т.к. оборудование находящееся на "соседнем" публичном IP работает отлично.

подскажите в чем может быть проблема. Пробовали менять гугловский DNS (8.8.8.8) на другие ресурсы - ситуация не меняется.

• ip sla +track,Serb, 19:46 , 20-Мрт-12
  • ip sla +track,irod, 20:57 , 20-Мрт-12
• ip sla +track,бен Бецалель, 14:19 , 21-Мрт-12
• ip sla +track,alekseyeng, 12:55 , 28-Апр-12

>[оверквотинг удален]
> переходит на резервный. при этом это происходит на всех трех цисках
> с завидной периодичностью. при этом ни рестарт трека, ни перезагрузка не
> позволяют вернуться на основной канал. помогает только прописывание маршрута ip route
> 0.0.0.0 0.0.0.0 2.2.2.2 После того как вводишь эту строчку Track1 поднимается
> в UP. Потом этот маршрут удаляю и циска опять какое то
> время работает на ISP1.
> проблем с оператором связи не наблюдается в момент перехода Track1 в Down,
> т.к. оборудование находящееся на "соседнем" публичном IP работает отлично.
> подскажите в чем может быть проблема. Пробовали менять гугловский DNS (8.8.8.8) на
> другие ресурсы - ситуация не меняется.

Poprobuite track blizhaeishego hopa, GW, v vashem sluchae 2.2.2.2
nabludalis pohozhie problemi pri bolshom TTR

>
> Poprobuite track blizhaeishego hopa, GW, v vashem sluchae 2.2.2.2
> nabludalis pohozhie problemi pri bolshom TTR

В этом случае все работает хорошо. Но смысла в мониторинге нет, т.к. при падении ISP1 гейтвей 2.2.2.2 остается доступным.

удалить track 2 и ip sla 2

ip route 0.0.0.0 0.0.0.0 2.2.2.2 10 track 1
ip route 0.0.0.0 0.0.0.0 3.3.3.3 20
(может и не имеет отношения к проблеме, но я обычно такие метрики пишу)

так же бывает полезно что-то вроде
track 1 ip sla 1 reachability
delay down 25 up 25

и еще
ip route 8.8.8.8 255.255.255.255 2.2.2.2 permanent

>[оверквотинг удален]
> переходит на резервный. при этом это происходит на всех трех цисках
> с завидной периодичностью. при этом ни рестарт трека, ни перезагрузка не
> позволяют вернуться на основной канал. помогает только прописывание маршрута ip route
> 0.0.0.0 0.0.0.0 2.2.2.2 После того как вводишь эту строчку Track1 поднимается
> в UP. Потом этот маршрут удаляю и циска опять какое то
> время работает на ISP1.
> проблем с оператором связи не наблюдается в момент перехода Track1 в Down,
> т.к. оборудование находящееся на "соседнем" публичном IP работает отлично.
> подскажите в чем может быть проблема. Пробовали менять гугловский DNS (8.8.8.8) на
> другие ресурсы - ситуация не меняется.

а почему бы вам неиспользовать GLBP или HSRP? будет возможность балансировки траффика.  ipsla если они независимы друг от друга.