Отказоустойчивость Linux/Vyatta с GRE и OSPF/BGP
У меня есть странная проблема с переключением при сбое маршрутизации в сценарии: я пытаюсь сделать это переключение при помощи ospf или bgp, в обоих случаях происходит одинаковое странное поведение с туннелями: для TUN192.7.0.0 предоставление маршрута по умолчанию к 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 всегда является предложенным путем), но сетевой поток не идет. Я могу пропинговать 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 Мбит / с, EXTIP2 и EXTIP3 - от одного и того же провайдера
1 ответ
Кажется, это было связано с pmtud, после отключения pmtud на R7 (net.ipv4.ip_no_pmtu_disc=1), похоже, работает нормально. Это разрушение туннелей после упора http://utcc.utoronto.ca/~cks/space/blog/linux/IPSecPacketDropProblemII
полезная команда ip:
ip route show table cache