web-dev-qa-db-ja.com

OSPFルーター（DebianでBIRDを使用）は相互にネイバーとして認識しますが、相互にpingを実行できません

仮想ボックスを使用して「ライン」トポロジを作成しました-4台のマシンを作成し、内部ネットワークを使用してそれぞれの間に個別のリンクを作成します-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。以下を使用して、ipv4のパケット転送を有効にしました。

Sudo sysctl net.ipv4.ip_forward=1

/etc/bird.confのR2およびR3のOSPF構成は次のようになります。

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

birdcに入って入力すると

ospf  show topology

そして

ospf show neighbors

すべてのルーターが正しいトポロジを認識し、隣接ルーターをネイバーとして認識し、コストを正しく計算しているようです。ただし、インターフェイスを手動で指定しない限り、R2からR3にpingを実行することはできません（ping -I eth2 10.0.3.1）。これは、両端でeth0が使用されるR1とR2には当てはまりません。

/ etc/network/interfacesが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

問題がインターフェイスの構成にあるのか、ルーティングプロトコルの構成にあるのか、少し混乱しています。

ここ はの出力です

ip link

そして

ip route

マシンごとに

routingrouterospfbird
1
pldimitrov

私はそれを考え出した！セットアップが機能しなかった理由はいくつかあります。まず、アドレスが正しく設定されていませんでした。物事を機能させるには、インターフェースに次の（たとえば）アドレスを割り当てる必要があります。

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

2つの隣接するルーターで向かい合っている両方のインターフェイスが同じブロードキャストドメイン（/ 24サブネット）上にあるようにするため。各インターフェイスのネットマスクは255.255.255.0に設定する必要があります。

BIRDのOSPF構成に関しては、ルーターが交換する情報の種類（特に、ルーターが話しているネットワーク）を指定するために、「ネットワーク」ブロックをエリアに追加する必要がありました。その場合、両端に/ 24（255.255.255.0）ネットワークがあるため、networksステートメントで/ 16ネットワーク（255.255.0.0）を使用して、2つの隣接する/ 24ネットワーク（10.0.1と10.0）間で情報を交換できます。 .2たとえば）。したがって、最終的には次のようになります。

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

from bird ospf構成マニュアル ネットワーク{セット}-エリアIP範囲の定義。これは、LSAの作成の要約で使用されます。隠されたネットワークは他のエリアに伝播されません。

3
pldimitrov

OSPFは、どのインターフェイスからでもマルチキャストを使用してネイバーを検出するため、ルーターはOSPFを介して相互に認識できます。つまり、2つのルーターが同じマルチキャストドメイン上にある限り、ネイバーを表示するために実際にルーティングテーブルを操作する必要はありません。

したがって、スクリーンショットを見ると、すべてのルーターインターフェイスは10.0.0.0/8または192.168.0.0/24のいずれかにあります。ルーターはそれを認識し、同じブロードキャストドメインにあると想定するため、パケットをeth0やeth2などに送信する代わりに、トラフィックをランダムなインターフェイスに送信します。

ルーター間の通信には、直接接続された小さなサブネットを使用する必要があります。混乱を招くような巨大な/ 8サブネットは使用しないでください。

実際には異なる実際のネットワークである、重複するルーティングテーブルが多数あるルーターがあるのは一般的な状況です。

特に鳥の場合： http://bird.network.cz/?get_doc&f=bird-2.html

最後に、birdがOSルートを認識し、OSにルートを設定していることを確認する必要があります。ああ、これがあなたのトラブルの原因かもしれません [〜＃〜] faq [〜＃〜] から：

BIRDはカーネルから一部のルーターをインポートしません

まず、カーネルプロトコルの学習オプションがアクティブである必要があります。

次に、OS /カーネルによって自動的に追加されたインターフェイスアドレス/プレフィックスに関連する「デバイス」ルートはインポートされません。直接プロトコルを使用してそれらを追加できます。

第三に、いくつかのあいまいで歴史的な理由により、BIRD 1.3.x（またはそれ以前）は、手動で追加されたデバイス/ホストルート（つまり、ゲートウェイのないルート）でさえインポートしません。これを修正するには2つの方法があります。これらのルートを静的プロトコルソースを使用してカーネルルーティングテーブルに追加するか（例： '@ ip route add 10.20.30.0/24 dev eth0 proto static @'）、パッチを添付してBIRDを再コンパイルし（ページの下部を参照）、これを修正します。問題。

1
chris