Пользователи в удаленных офисах выходят в Интернет через оборудование находящееся в ЦО. Подключаются через Easy VPN Remote. Чтобы пользователей удаленных офисов закинуть на роутер, занимающейся раздачей интернета был использован роутмап
route-map RouteToInet permit 10
match ip address 9
set ip default next-hop 192.8.101.1
access-list 9 permit 192.8.0.0 0.0.255.255
При падении основного канала связи, кошка удаленного офиса через некоторое время пытается подключиться к другому ip easy vpn server-а. На циске ЦО наблюдается следующее:
vpn-rt#sho ip route list 9
S    192.8.106.0/24 [1/0] via 10.11.8.215
...
S    192.8.116.0/24 [1/0] via 10.11.8.224 <- основной канал жив, все работает
Симулируем падение основного канала, и смотрим:
S    192.8.116.0/24 [1/0] via 109.188.64.XXX <- создался новый маршрут, но данные не идут
                    [1/0] via 10.11.8.224  <- остатки от старого
Данные не идут, но все, а только те что ХОДИЛИ в момент падения основного канала. Если обратиться к новому компу (ip) то все ходит.
Проходит время, какое точно не замерял, но примерно от 0,5 до 1 часа. И данные начинают ходить как ни в чем не бывало. При этом строчка от старого маршрута пропадает.
Нужно сократить время ожидания до минимального. Где что подкрутить?

• route-map кэш и timeout,Gbyte, 15:57 , 31-Мрт-10
  • route-map кэш и timeout,sash555, 16:15 , 31-Мрт-10
    • route-map кэш и timeout,Gbyte, 18:54 , 31-Мрт-10
      • route-map кэш и timeout,Sash555, 21:19 , 31-Мрт-10
        • route-map кэш и timeout,Gbyte, 22:22 , 31-Мрт-10

задержку скорее всего формирует cef.

Лучше не городить огород, попробовать для начала решить вопрос на уровне дизайна.

Можешь схему изобразить с каналами, адресами и маршрутами, лучше в графическом виде и выложить где-нить в сети?

>задержку скорее всего формирует cef.
>
>Лучше не городить огород, попробовать для начала решить вопрос на уровне дизайна.
>
>
>Можешь схему изобразить с каналами, адресами и маршрутами, лучше в графическом виде
>и выложить где-нить в сети?

Сейчас требуется быстрое решение, но предложения/советы по дизайну приветствуются. В любом случае заранее спасибо за ответы
Картинка с топологией (примерная, лишнее скрыто)

http://img165.imagevenue.com/img.php?image=37113_cisco_122_4...

почитай №3 в http://www.anticisco.ru/index.php?sn=pub

многое похоже, особенно тебе трекинг нужен.

>почитай №3 в http://www.anticisco.ru/index.php?sn=pub
>многое похоже, особенно тебе трекинг нужен.

Прочитал, за ссылку спасибо, но мне сейчас это совершенно не интересно, у меня нет задачи переключаться между провайдерами в данный момент. Мне нужно понять какой алгоритм заставляет жить запись маршрута, использующего мой аксес-лист. И как это время жизни уменьшить, либо как отключить этот алгоритм...

>>почитай №3 в http://www.anticisco.ru/index.php?sn=pub
>>многое похоже, особенно тебе трекинг нужен.
>
>Прочитал, за ссылку спасибо, но мне сейчас это совершенно не интересно, у
>меня нет задачи переключаться между провайдерами в данный момент. Мне нужно
>понять какой алгоритм заставляет жить запись маршрута, использующего мой аксес-лист. И
>как это время жизни уменьшить, либо как отключить этот алгоритм...

А я тебе о чем? - используй силу Люк! (читай трэкинг статических маршрутов).

у меня тоже куча 3750 имеет по два аплинка и статику на каждого, так вот если вдруг один линк отвалился, то на лупбэк коммутатора не зацепится, так как статический маршрут остается в таблице маршрутизации.

я выхожу из положения так:
1. у нас поднят eigrp
2. по eigrp я ананосирую на коммутаторы дефолтный маршрут, а статику уничтожаю

получается как только линк упал - маршрут из таблицы пропал и все отлично!

у тебя же динамической маршрутизации нет, тогда придется трэкать что-то и по этому условию добавлять/убирать маршрут...

можешь сам убетится - во время пропадания канала сделай #sho ip route static и сам все поймешь.