Eu tenho uma rede de 3 nós com o Quagga OSPF sendo executado em cada um deles.
Cada nó conectado com o p2p, OpenVPN:
link
(Incluirá imagem aqui quando tiver reputação > 10)
O pfSense tem dois clientes OpenVPN, com ip 10.0.1.2 e 10.0.2.2, indo para o servidor 1 e 2 respectivamente.
Agora, a conexão C (10.0.2.1 - 10.0.2.2) morre. O que acontece é que a rede é adaptada e o pfSence recebe a atualização do OSPF que (10.0.2.1 - 10.0.2.2) é acessível por meio da rota [B- > A], em vez de apenas [C]
O pfSense tem informações sobre o link 10.0.2.1 - 10.0.2.2 e sabe que ele existe a 2 saltos de distância.
O resultado é que, quando o OpenVPN, o cliente de encapsulamento C está tentando reiniciar, não pode. Como não é possível atribuir o endereço IP que está na tabela de roteamento:
Citação
/sbin/ifconfig ovpnc1 10.0.2.1 - 10.0.2.2 mtu 1500 netmask 255.255.255.255 up
FreeBSD ifconfig failed: external program exited with error status: 1
Chamada manual diz
ifconfig: ioctl (SIOCAIFADDR): Address already in use
De que maneira posso evitar isso? Posso investigar o link morto de alguma forma? Então, se o túnel C morrer, o Servidor 2 o removerá e não anunciará
Eu já tentei link-detect, ele mostra o link como no servidor 2 (lado de escuta do OpenVPN):
interface tun1
description VPS link C
link-detect
ipv6 nd suppress-ra
!
Deve ser separado por zonas, por ex. A - backbone,? Ou existe uma inserção do tcp-probe no quagga para saber se o link é pingável?
Se houver uma investigação, ela ajudará a lidar com outro caso:
Na foto acima, se o segmento A estiver inativo. O tráfego será reencaminhado via pfSense (B- > C em vez de A) e preso lá. Como o tráfego está desativado (intencionalmente) de passar entre os túneis pelo pfSense.
Eu sou novo no roteamento dinâmico e acredito que existe uma maneira padrão de lidar com esse loop
