Отказоустойчивость Linux / Vyatta с GRE и OSPF / BGP

У меня странная проблема с аварийным переключением маршрутизации в сценарии: я пытаюсь выполнить аварийное переключение через ospf или bgp, в обоих случаях происходит одно и то же странное поведение с туннелями: для 192.7.0.0 TUN предоставляется маршрут по умолчанию на R1 - основной сайт (нам нужен весь трафик ).

        172.16.0.1(10.3.3.1)            10.3.3.0/30                      172.16.0.2(10.3.3.2)
        +-------------------------------->TUN0<--------------------------------------------+
        |                                                                                  |
        |                 +--------+                                                       |
        |                 |        |EXTIP1                                                 |
        |    +------------+  VPN1  +--------->IPSEC<------------+                          |
        |    |            |        |                            |                          |
        |    v            +--------+                            |                          |
       ++------+                                                |                          |
       |       |                                                |--------+        +--------++
LAN +--->|  R1   |                                                +        |            |         |
192.0.0.0/24       |                                          EXTIP3|  VPN7  +------->|  R7     <--+LAN
       ++------+                                                +        |        |         |192.7.0.0/24
        |    ^                                                  |--------+        +--------++
        |    |                                                  |                          |
        |    |                                                  |                          |
        |    |                                                  |                          |
        |    |            +--------+                            |                          |
        |    |            |        |                            |                          |
        |    +------------+ VPN2   |EXTIP2                      |                          |
        |                 |        +------------->IPSEC<--------+                          |
        |                 +--------+                                                       |
        |                                                                                  |
        |                                                                                  |
        |                                     PREFFERED PATCH                              |
        +------------------------------------>TUN1<----------------------------------------+
        172.16.0.3(10.3.3.5)                10.3.3.4/30                  172.16.0.4(10.3.3.6)

Для первоначального запуска все работает нормально, когда основной канал TUN1 выходит из строя, происходит переключение, и через несколько секунд (ospf) или минут (bgp) канал сходится, и сетевой поток через TUN0 в порядке. НО, когда TUN1 вернется, поток будет нарушен, маршрутизаторы изменят путь в соответствии с конфигурацией (TUN1 всегда является предложенным путем), но сетевой поток не идет. Я могу ping 192.7.0.0 <-> 192.0.0.0 с небольшими пакетами, но, например, VNC, HTTP или другие приложения больше не работают. Я обнаружил, когда TUN1 вернется, и я сброшу ссылку туннелей вручную с помощью команды:

sudo ip link set tun0 down
sudo ip link set tun1 down
sudo ip link set tun1 up
few seconds pause
sudo ip link set tun0 up

все вернулось к норме Итак, мой вопрос:

Это неправильное представление о реализации аварийного переключения?

Это ошибка?

Это особенность?

Спасибо за ответ

Vyatta 6.4 8.04 на R1 R7 Vyatta 6.4 5.31 на VPN [1 | 2 | 7]

Обновление: я запускал mroute на TUN0 с 192.0.0.0

mturoute.exe 192.7.0.162
* ICMP Fragmentation is not permitted. *
* Speed optimization is enabled. *
* Maximum payload is 10000 bytes. *
- ICMP payload of 1472 bytes is too big.
+ ICMP payload of 92 bytes succeeded.
+ ICMP payload of 782 bytes succeeded.
+ ICMP payload of 1127 bytes succeeded.
+ ICMP payload of 1299 bytes succeeded.
- ICMP payload of 1385 bytes is too big.
+ ICMP payload of 1342 bytes succeeded.
- ICMP payload of 1363 bytes is too big.
+ ICMP payload of 1352 bytes succeeded.
+ ICMP payload of 1357 bytes succeeded.
- ICMP payload of 1360 bytes is too big.
+ ICMP payload of 1358 bytes succeeded.
- ICMP payload of 1359 bytes is too big.
Path MTU: 1386 bytes.

После аварийного переключения TUN0-> TUN1 также из 192.0.0.0

mturoute.exe 192.7.0.162
* ICMP Fragmentation is not permitted. *
* Speed optimization is enabled. *
* Maximum payload is 10000 bytes. *
- ICMP payload of 1472 bytes is too big.
+ ICMP payload of 92 bytes succeeded.
...- ICMP payload of 782 bytes failed. (IP_REQ_TIMED_OUT)
+ ICMP payload of 437 bytes succeeded.
.- ICMP payload of 609 bytes failed. (IP_REQ_TIMED_OUT)
.- ICMP payload of 523 bytes failed. (IP_REQ_TIMED_OUT)
+ ICMP payload of 480 bytes succeeded.
.- ICMP payload of 501 bytes failed. (IP_REQ_TIMED_OUT)
+ ICMP payload of 490 bytes succeeded.
+ ICMP payload of 495 bytes succeeded.
.- ICMP payload of 498 bytes failed. (IP_REQ_TIMED_OUT)
+ ICMP payload of 496 bytes succeeded.
.- ICMP payload of 497 bytes failed. (IP_REQ_TIMED_OUT)
Path MTU: 524 bytes.

я не понимаю почему.

обновление # 2

EXTIP1, EXTIP2, EXTIP3 - 40 Мбит F / O EXTIP2 и EXTIP3 - от того же провайдера