我在路由故障转移的场景中有一个奇怪的问题：我试图通过ospf或bgp做这个故障转移，在这两种情况下都发生了与隧道相同的奇怪行为：对于192.7.0.0 TUN提供默认路由到R1 – 主站点（我们需要所有stream量）。
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）链路收敛，networkingstream量通过TUN0可以正常工作。 但是当TUN1返回时，stream量会变差，路由器会根据configuration改变path（TUN1总是提供path），但是networkingstream量不会stream逝。 我可以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
一切都恢复正常所以我的问题是：
这是错误的思考故障转移实施？
这是一个错误？
这是一个function吗？
谢谢你的回答
Vyatta 6.4 8.04在R1 R7 Vyatta 6.4 5.31在VPN [1 | 2 | 7]
更新：我已经在192.0.0.0的TUN0上运行了mroute
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是40Mbit的F / O EXTIP2和EXTIP3是来自同一个ISP
看起来这与pmtud有关，在R7上禁用pmtud（net.ipv4.ip_no_pmtu_disc = 1）后似乎工作正常。 这是岗位邻接隧道崩溃http://utcc.utoronto.ca/~cks/space/blog/linux/IPSecPacketDropProblemII
有用的ip命令：
ip route show table cache