Na versão atual do Quagga no Linux, descobri que existe uma regra que pode impedir que alguns tipos de informações de rotas sejam anunciadas para roteadores vizinhos via RIPv2.
Se o roteador r1 se conectar a outro roteador r2 por meio de uma interface 'nic0' e r1 tiver outra interface 'nic1', conecte-se a outra rede 'net1'. Então r1 espera anunciar a rota para 'net1' para seu vizinho r2. A rede, digamos net0, é a rede que conecta r1 e r2, que é, digamos, 10.3.1.32/27, e a rede 'net1' é, digamos, 10.3.1.0/24.
Nesse caso, a entrada da rota 10.3.1.0/24 (via nic1) não será enviada para r2 porque o programa RIPv2 no Quagga suprimiu internamente a entrada e a descartou.
Verifiquei o código fonte do RIPv2 do Quagga e descobri que é por causa de uma regra: 10.3.1.0/24 tem um prefixo de rede que está contido no prefixo de rede 10.3.1.32/27, ou seja, os 24 bits mais à esquerda de 10.3.1.0 é uma substring dos 27 bits mais à esquerda de 10.3.1.32.
Mas não entendo por que existe tal regra. É definido pelo padrão RIPv2 ou apenas uma peculiaridade do Quagga? No meu entendimento, a sobreposição entre net0 e net1 é válida e não deve ser um problema por causa da 'Regra de correspondência de prefixo de rede mais longa' no roteamento, e para o roteador r2, ele realmente precisa saber que existe uma rede net1 maior (comparando para net0) pode ser alcançado via r1. Se esta informação de rota foi suprimida pelo Quagga, r2 não saberá disso e os hosts em net1 não poderão ser acessados de net0 pelo lado r2.
Existe alguém que sabe disso?
Obrigado, amadeirado
Responder1
Se a rede 10.3.1.0/24 estiver conectada diretamente ao R1, isso poderá representar um problema. Nesse caso, R1 possui endereços IP sobrepostos em ambas as interfaces. Não sou especialista em Linux, mas sei que isso não é compatível com roteadores Cisco (e tenho certeza de que também não é compatível com nenhum outro roteador/firewall).
Se a rede não estiver conectada diretamente a R1, deverá haver um terceiro roteador na rede, vamos chamá-lo de R0. R0 está diretamente conectado à rede 10.3.1.0/24 e se conecta a R1 através de alguma outra rede, por exemplo, 172.16.0.0/24. Nesse caso, a configuração deve funcionar perfeitamente. Eu testei isso em roteadores Cisco.
10.0.0.0/8 is variably subnetted, 4 subnets, 4 masks
R 10.3.1.0/24 [120/1] via 172.16.0.101, 00:00:13, Ethernet0/1 (nic1)
C 10.3.1.32/27 is directly connected, Ethernet0/0 (nic0)
Talvez Quagga – embora não reclame disso – também não consiga lidar com esses intervalos de IP sobrepostos em ambas as suas interfaces.