Os roteadores OSPF (com BIRD no debian) reconhecem um ao outro como vizinhos, mas não podem pingar uns aos outros

Question

Eu criei uma topologia de "linha" usando caixa virtual - criando 4 máquinas e fazendo um link separado entre cada uma usando redes internas - R1 (eth0, 10.0.1.1) < - > (eth0, 10.0.2.1) R2 (eth2, 10.0.2.2) < - > (eth0, 10.0.3.1) R3 (eth2, 10.0.3.2) < - > (eth0, 10.0.4.1) R4. Eu habilitei o encaminhamento de pacotes para o ipv4 usando:

sudo sysctl net.ipv4.ip_forward=1

a configuração do OSPF para R2 e R3 em /etc/bird.conf se parece com isto:

protocol ospf MyOSPF {
    tick 2;
    rfc1583compat yes;
    area 0.0.0.0 {
        stub no;
        interface "eth2" {
            hello 9;
            retransmit 6;
            cost 10;
            transmit delay 5;
            dead count 5;
            wait 50;
            type broadcast;
        };
        interface "eth0" {
            hello 9;
            retransmit 6;
            cost 10;
            transmit delay 5;
            dead count 5;
            wait 50;
            type broadcast;
        };
    };
}

quando eu entro em birdc e digito

ospf  show topology

e

ospf show neighbors

parece que todos os roteadores veem a topologia correta, reconhecem os roteadores adjacentes como vizinhos e calculam os custos corretamente. No entanto, não é possível executar ping no R3 a partir do R2, a menos que a interface seja especificada manualmente (ping -I eth2 10.0.3.1). Este não é o caso de R1 e R2, onde eth0 é usado em ambas as extremidades.

Aqui está o que / etc / network / interfaces procura no R2:

allow-hotplug eth0
iface eth0 inet static
address 10.0.2.1

auto eth1 #this is the bridged adapter used to ssh to the vm from the host
iface eth1 inet dhcp 

allow-hotplug eth2
iface eth2 inet static
address 10.0.2.2

Estou um pouco confuso se o problema está na configuração das interfaces ou no protocolo de roteamento.

Aqui é a saída de

ip link

e

ip route

para cada máquina

    

Answer 1

Eu percebi isso! Há vários motivos pelos quais a configuração não estava funcionando - em primeiro lugar, os endereços não foram definidos corretamente. A interface deve receber os seguintes endereços (por exemplo) para fazer as coisas funcionarem:

R1 (eth0, 10.0.1.1) < - > (eth0, 10.0.1.2) R2 (eth2, 10.0.2.1) < - > (eth0, 10.0.2.2) R3 (eth2, 10.0.3.1) < - > (eth0, 10.0.3.2) R4

para que as duas interfaces, frente a frente em cada um dos dois roteadores adjacentes, estejam no mesmo domínio de transmissão (/ 24 sub-rede). A máscara de rede em cada interface deve ser definida como 255.255.255.0.

Quanto à configuração do OSPF no BIRD, o bloco de "redes" teve que ser adicionado à área para designar que tipo de informação os roteadores deveriam trocar (em particular, de quais redes os roteadores estão falando). Nesse caso, uma vez que temos uma rede / 24 (255.255.255.0) em cada extremidade, podemos usar uma rede / 16 (255.255.0.0) na declaração de redes para trocar informações entre as duas redes adjacentes / 24 (10.0.1 e 10.0 .2 por exemplo). Então, no final, parece assim:

protocol ospf MyOSPF {
    tick 2;
    rfc1583compat yes;
    area 0.0.0.0 {
        networks {
            10.0.0.0/16;
        };
        stub no;
        interface "eth2" {
            hello 9;
            retransmit 6;
            cost 10;
            transmit delay 5;
            dead count 5;
            wait 50;
            type broadcast;
        };
        interface "eth0" {
            hello 9;
            retransmit 6;
            cost 10;
            transmit delay 5;
            dead count 5;
            wait 50;
            type broadcast;
        };
    };
}

de manual de confiiguração do pássaro ospf networks {set} - Definição de faixas de IP da área. Isso é usado no resumo da origem da LSA. Redes ocultas não são propagadas para outras áreas.

    

Answer 2

Seus roteadores podem ver uns aos outros através do OSPF porque o OSPF usa multicast em qualquer interface para descobrir vizinhos. Isso significa que você não precisa realmente trabalhar com tabelas de roteamento para ver os vizinhos, desde que os dois roteadores estejam no mesmo domínio de multidifusão.

Então, olhando para suas screencaps - todas as interfaces do roteador estão em 10.0.0.0/8 ou 192.168.0.0/24. Seus roteadores verão isso e presumirão que estão no mesmo domínio de broadcast, então, em vez de enviar o pacote eth0 ou eth2, ou seja lá o que for, eles enviarão o tráfego para fora das interfaces aleatórias.

Você deve usar pequenas sub-redes conectadas diretamente para a comunicação entre roteadores e roteadores e não ter essas sub-redes gigantes / 8 que apenas tornarão as coisas confusas.

É uma situação comum ter um roteador com muitas tabelas de roteamento sobrepostas que são, na verdade, redes reais diferentes.

Para pássaros especificamente: link

Por último, você precisa ter certeza de que o pássaro sabe sobre as rotas do sistema operacional e está definindo rotas no sistema operacional. Ah, isso pode ser a fonte dos seus problemas - da FAQ :

BIRD does not import some routers from kernel

First, learn option of kernel protocol must be active.

Second, 'device' routes related to interface addresses/prefixes added automatically by OS/kernel are never imported. You could add them using direct protocol.

Third, for some obscure and historic reasons BIRD 1.3.x (or older) does not import even some manually added device/host routes (i.e. ones without gateway). There are two ways to fix this. Either add these routes to the kernel routing table with static protocol source (e.g. '@ip route add 10.20.30.0/24 dev eth0 proto static@' ), or recompile BIRD with attached patch (see the bottom of the page) to fix this issue.