Уважаемые форумчане

Хотелось бы задать вопрос, с которым столкнулся при замене старой Cisco 2811 (ios 12) на новую 2921 (ios 15). Я столкнулся с некоторыми странностями при работе с туннелями. Раньше я этого не замечал, т.к. кругом были циски на старом иосе 12.
Предварительно поискал в гугле, и на opennet, но подобного ничего не нашел :(

Сначала предыстория и небольшое исследование.
Проблема вот в чем: создаем два туннеля на 2х сторонах Центр (R1) и Филиал (R2) по 2-м независимым линиям (2 провайдера VPN). Для маршрутизации используется eigrp. Если вдруг физически линия одного провайдера падает, то мы, находясь в центре и пингуя IP туннеля в филиале видим это и можем сделать некоторые выводы (например, сразу перекинуть VoIP на резервный канал, и не ждать пока отвалится соседство).
Теперь, когда ios 15 в центре и ios 12 остались в филиалах это перестало работать. Внезапно по второму каналу через eigrp ко мне "прилетает" маршрут во "вторую", неработающую туннельную подсеть, и пинги не пропадают!

Например, создаем в центре на 2921 (ios 15.5(1)T) туннель в "никуда" (т.е. он не должен подняться, второй стороны нет):

interface Tunnel10
 description Test
 bandwidth 1024
 ip address 10.1.4.1 255.255.255.252
 ip mtu 1400
 ip authentication mode eigrp 100 md5
 ip authentication key-chain eigrp 100 [SECRET]
 ip tcp adjust-mss 1360
 delay 1000
 tunnel source 192.168.15.104
 tunnel destination 192.168.15.105
 tunnel path-mtu-discovery
 tunnel protection ipsec profile [CRYPTO_PROFILE]
end

Смотрим, что об этом туннеле думает наша циска:

R1#sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
Tunnel10                   10.1.4.1        YES manual up                    down

Статус туннеля - up, работает, все нормально с ним. Протокол - down, не работает, логично - т.к. второй стороны нет.
Спросим также, знает ли она в данный момент о маршрутах в подсеть туннеля:

R1#sh ip route 10.1.4.0 255.255.255.252
% Subnet not in table

Теперь создадим такой же туннель в никуда на филиальной циске (877, ios 12.4(15)T7)

interface Tunnel10
 description Test
 bandwidth 1024
 ip address 10.1.4.1 255.255.255.252
 ip mtu 1400
 ip authentication mode eigrp 100 md5
 ip authentication key-chain eigrp 100 [SECRET]
 ip tcp adjust-mss 1360
 delay 1000
 tunnel source 192.168.15.104
 tunnel destination 192.168.15.105
 tunnel path-mtu-discovery
 tunnel protection ipsec profile [CRYPTO_PROFILE]
end

Смотрим, что об этом туннеле думает наша циска:

R2#sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
Tunnel10                   10.1.4.1        YES manual up                    up

Опа! Как так?! Почему протокол в up'е? У нас же второй стороны нет!
Дальше по маршрутизации:

R2#sh ip route 10.1.4.0 255.255.255.252
Routing entry for 10.1.4.0/30
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Tunnel10
      Route metric is 0, traffic share count is 1

Собственно вот такой же, как в примере, connected маршрут мне сейчас и прилетает по второму, работающему туннелю.
Получается, когда раньше физический канал "падал", соседство eigrp также отваливалось, НО туннельная сеть считалась продолжала считаться "работающей", т.к. она connected. Пинги по ней не ходили, и логика работы у треков не страдала (пинг пропал, переключаем next-hop). Теперь старые циски мне портят это поведение.

Вопрос: Как вернуть старое поведение?
Решения вижу 2:
1. Каким-либо образом заставить новую циску при "неработающем" туннеле, все равно считать её подсеть connected .
2. Заставить старые циски на старом иосе выключать протокол туннеля, когда он реально не работает.
3. Другое решение, по проверке работоспособности туннеля которое вы можете предложить.
Заранее спасибо!