Обновление ip «затыкает» соседний аплинк

[stiff]

Включил логи — попробую поймать, когда основной канал встанет.

Затык происходит во время обновления адреса, полученного по дхцп.
Схема — два аплинка. Основной аплинк дает 1 ip — на него все снатится.
Резервный дает несколько ip поэтому на 1 снатится, а другие пробрасываются в нужный влан.

[stiff]

Вот лог:

Mar/27/2012 23:22:20 route,debug,calc Begin calculation
Mar/27/2012 23:22:20 route,debug,calc Select route
Mar/27/2012 23:22:20 route,debug,calc dst-address=0.0.0.0/0
Mar/27/2012 23:22:20 route,debug,calc attributes
Mar/27/2012 23:22:20 route,debug,calc protocol=DYNAMIC
Mar/27/2012 23:22:20 route,debug,calc distance=10
Mar/27/2012 23:22:20 route,debug,calc scope=30
Mar/27/2012 23:22:20 route,debug,calc target-scope=10
Mar/27/2012 23:22:20 route,debug,calc next-hop= address=xxx.242.112.1
Mar/27/2012 23:22:20 route,debug,calc vrf-iface (12)=bridge-uplink2
Mar/27/2012 23:22:20 route,debug,calc origin-type=DYNAMIC
Mar/27/2012 23:22:20 route,debug,calc End calculation
Mar/27/2012 23:22:20 route,debug Begin redistribution
Mar/27/2012 23:22:20 route,debug Accept update 0.0.0.0/0
Mar/27/2012 23:22:20 route,debug Commit prefix 0.0.0.0/0
Mar/27/2012 23:22:20 route,debug End redistribution
Mar/27/2012 23:22:29 route,debug,calc Begin calculation
Mar/27/2012 23:22:29 route,debug,calc Select route
Mar/27/2012 23:22:29 route,debug,calc dst-address=0.0.0.0/0
Mar/27/2012 23:22:29 route,debug,calc attributes
Mar/27/2012 23:22:29 route,debug,calc protocol=STATIC
Mar/27/2012 23:22:29 route,debug,calc distance=1
Mar/27/2012 23:22:29 route,debug,calc scope=30
Mar/27/2012 23:22:29 route,debug,calc target-scope=10
Mar/27/2012 23:22:29 route,debug,calc next-hop= address=xx.78.178.129
Mar/27/2012 23:22:29 route,debug,calc need-gateway-check=2
Mar/27/2012 23:22:29 route,debug,calc comment=
Mar/27/2012 23:22:29 route,debug,calc origin-type=STATIC
Mar/27/2012 23:22:29 route,debug,calc End calculation
Mar/27/2012 23:22:29 route,debug Begin redistribution
Mar/27/2012 23:22:29 route,debug Accept update 0.0.0.0/0
Mar/27/2012 23:22:29 route,debug Commit prefix 0.0.0.0/0
Mar/27/2012 23:22:29 route,debug End redistribution

Вот как раз в это время и происходит «затык».

И прямо сразу за ним еще один:

Mar/27/2012 23:26:30 route,debug,calc Begin calculation
Mar/27/2012 23:26:30 route,debug,calc Select route
Mar/27/2012 23:26:30 route,debug,calc dst-address=0.0.0.0/0
Mar/27/2012 23:26:30 route,debug,calc attributes
Mar/27/2012 23:26:30 route,debug,calc protocol=DYNAMIC
Mar/27/2012 23:26:30 route,debug,calc distance=10
Mar/27/2012 23:26:30 route,debug,calc scope=30
Mar/27/2012 23:26:30 route,debug,calc target-scope=10
Mar/27/2012 23:26:30 route,debug,calc next-hop= address=xx.242.112.1
Mar/27/2012 23:26:30 route,debug,calc vrf-iface (12)=bridge-uplink2
Mar/27/2012 23:26:30 route,debug,calc origin-type=DYNAMIC
Mar/27/2012 23:26:30 route,debug,calc End calculation
Mar/27/2012 23:26:30 route,debug Begin redistribution
Mar/27/2012 23:26:30 route,debug Accept update 0.0.0.0/0
Mar/27/2012 23:26:30 route,debug Commit prefix 0.0.0.0/0
Mar/27/2012 23:26:30 route,debug End redistribution

Первый «затык» связан, как я понимаю, с обновлением адреса по dhcp (в статусе как раз expries after около 59 минут было) а второй — непонятно.

[iSupport]

второй - на тот же интерфейс что и первый

Есть предложение Манглом метить правила и скриптом обрабатывать куда их посылать

То есть дистанция у роутов одинаковая и оба постоянно активны

а отсылка идет по параметру routing mark

[stiff]

второй - на тот же интерфейс что и первый

эту фразу не понял.

а отсылка идет по параметру routing mark

ну это же нужно когда два активных аплинка. Мне кажется, что routing mark не спасет от пересчета таблиц роутинга. Или я ошибаюсь?

На основном роуте у меня дистанция 1, на резервном — 10 мне достаточно, чтобы работал 1 аплинк.

Я пока вижу два решения:
1. каким-то образом запретить на клиентской стороне автообновление ip по дхцп (или сделать его хотя бы раз в день)
2. каким-нибудь скриптом добавлять роут, когда падает основной канал

[iSupport]

я говорил про второй затык - он при обсчете того же интерфейса, что и первый

Роутинг марк - это четкое указание куда слать