1 votes

Les routeurs OSPF (avec BIRD sur Debian) se reconnaissent comme voisins mais ne peuvent pas se pinguer.

J'ai créé une topologie "en ligne" à l'aide d'une boîte virtuelle - en créant 4 machines et en établissant un lien séparé entre chacune d'elles en utilisant les réseaux internes - 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. J'ai activé la redirection des paquets pour ipv4 en utilisant :

sudo sysctl net.ipv4.ip_forward=1

la configuration OSPF pour R2 et R3 dans /etc/bird.conf ressemble à ceci :

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;
        };
    };
}

quand j'entre dans birdc et que je tape

ospf  show topology

et

ospf show neighbors

il semble que tous les routeurs voient la topologie correcte, reconnaissent les routeurs adjacents comme voisins et calculent les coûts correctement. Cependant, il n'est pas possible d'envoyer un ping à R3 depuis R2, à moins que l'interface soit spécifiée manuellement (ping -I eth2 10.0.3.1). Ce n'est pas le cas avec R1 et R2, où eth0 est utilisé aux deux extrémités.

Voici à quoi ressemble le fichier /etc/network/interfaces sur 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

Je ne sais pas si le problème réside dans la configuration des interfaces ou dans celle du protocole de routage.

Ici est la sortie de

ip link

et

ip route

pour chaque machine

3voto

pldimitrov Points 143

J'ai trouvé ! Il y a plusieurs raisons pour lesquelles la configuration ne fonctionnait pas - tout d'abord, les adresses n'étaient pas correctement définies. Pour que tout fonctionne, il faut attribuer à l'interface les adresses suivantes (par exemple) :

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

afin que les deux interfaces se faisant face sur chacun des deux routeurs adjacents soient sur le même domaine de diffusion (sous-réseau /24). Le masque de réseau de chaque interface doit être défini sur 255.255.255.0.

En ce qui concerne la configuration OSPF dans BIRD, le bloc "networks" a dû être ajouté à la zone afin de désigner le type d'informations que les routeurs sont censés échanger (en particulier, de quels réseaux les routeurs parlent). Dans ce cas, puisque nous avons un réseau /24 (255.255.255.0) à chaque extrémité, nous pouvons utiliser un réseau /16 (255.255.0.0) dans l'instruction networks pour échanger des informations entre les deux réseaux /24 adjacents (10.0.1 et 10.0.2 par exemple). Donc, à la fin, cela ressemble à ceci :

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 manuel de confiiguration bird ospf networks {set} - Définition des plages IP de la zone. Ceci est utilisé dans la création de LSA sommaire. Les réseaux cachés ne sont pas propagés dans d'autres zones.

1voto

Dave Points 864

Vos routeurs peuvent se voir les uns les autres via OSPF car OSPF utilise le multicast de l'interface quelconque pour découvrir les voisins. Cela signifie que vous n'avez pas besoin de tables de routage actives pour voir vos voisins, tant que les deux routeurs se trouvent dans le même domaine de multidiffusion.

Donc, en regardant vos captures d'écran - toutes vos interfaces de routeur sont soit dans 10.0.0.0/8 ou 192.168.0.0/24. Vos routeurs vont voir cela et supposer qu'ils sont dans le même domaine de diffusion, donc au lieu d'envoyer le paquet sur eth0 ou eth2 ou autre, ils vont simplement envoyer le trafic sur des interfaces aléatoires.

Vous devriez utiliser de petits sous-réseaux à attachement direct pour la communication entre routeurs et ne pas avoir ces sous-réseaux /8 géants qui ne feront que rendre les choses confuses.

Il est fréquent qu'un routeur dispose d'un grand nombre de tables de routage différentes qui se chevauchent et qui correspondent en fait à des réseaux réels différents.

Pour les oiseaux en particulier : http://bird.network.cz/?get_doc&f=bird-2.html

Enfin, vous devez vous assurer que Bird connaît les routes du système d'exploitation et qu'il les configure sur le système d'exploitation. Ah, c'est peut-être la source de votre problème -- de la part du FAQ :

BIRD n'importe pas certains routeurs du noyau

Tout d'abord, l'option d'apprentissage du protocole du noyau doit être active.

Deuxièmement, les routes "périphériques" liées aux adresses/préfixes d'interface ajoutés. automatiquement par l'OS/le noyau ne sont jamais importées. Vous pouvez les ajouter en utilisant le protocole direct.

Troisièmement, pour des raisons obscures et historiques, BIRD 1.3.x (ou plus ancien) n'importe pas même certaines routes d'appareils/hôtes ajoutées manuellement (c'est-à-dire celles sans passerelle). Il y a deux façons de résoudre ce problème. Soit vous ajoutez ces routes à la table de routage du noyau avec une source de protocole statique (par ex. '@ip route add 10.20.30.0/24 dev eth0 proto static@' ), soit recompiler BIRD avec le patch joint (voir le bas de la page) pour corriger ce problème. problème.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X