Parecia que isso estava relacionado ao pmtud, depois de desabilitar o pmtud no R7 (net.ipv4.ip_no_pmtu_disc = 1) parece funcionar ok. Este é o post colapso dos túneis link
comando ip útil:
ip route show table cache
Eu tenho um problema estranho com o failover de roteamento no cenário: Estou tentando fazer este failover via ospf ou bgp, em ambos acontece o mesmo comportamento estranho com túneis: Para 192.7.0.0 TUN fornecendo rota padrão para R1 - site principal (precisamos de todo o tráfego).
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)
Na inicialização, tudo está funcionando bem, quando o link principal TUN1 desce, o failover acontece e, após alguns segundos (ospf) ou minutos (bgp), o link é convergente e o fluxo de rede é aprovado via TUN0. MAS, quando o TUN1 voltará, o fluxo está desordenado, os roteadores mudarão o caminho de acordo com a configuração (o caminho TUN1 é sempre oferecido), mas o fluxo da rede não está indo. Eu posso pingar 192.7.0.0 < - > 192.0.0.0 com pequenos pacotes mas por exemplo VNC, HTTP ou outros aplicativos não funcionam mais. Eu descobri quando o TUN1 está de volta e eu vou resetar o link dos túneis manualmente via comando:
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
tudo está de volta ao normal Então minha pergunta é:
Está errado pensar na implementação de failover?
Isso é um bug?
Isso é um recurso?
Obrigado por responder
Vyatta 6.4 8.04 em R1 R7 Vyatta 6.4 5.31 na VPN [1 | 2 | 7]
Atualização: Eu corri mroute no TUN0 de 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.
Após o failover TUN0- > TUN1 também de 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.
não entendi o porquê.
atualização # 2
EXTIP1, EXTIP2, EXTIP3 são 40 Mbit F / O EXTIP2 e EXTIP3 são do mesmo ISP
Parecia que isso estava relacionado ao pmtud, depois de desabilitar o pmtud no R7 (net.ipv4.ip_no_pmtu_disc = 1) parece funcionar ok. Este é o post colapso dos túneis link
comando ip útil:
ip route show table cache