解答
[どのルータでどのような設定ミスのため、このトラブルが起こっているでしょうか？]
R1のFastEthernet0/0に次の設定ミスがあります。
interface FastEthernet0/0 ip ospf network point-to-multipoint ip ospf hello-interval 10
トラブルを解決するためには、次のコマンドでネットワークタイプをデフォルトのBROADCASTに戻します。
interface FastEthernet0/0 no ip ospf network
[その設定ミスに関わらずなぜネイバーはすべてFULL状態になるのでしょうか？]
ネットワークタイプの一致は、ネイバーを確立するための条件ではないので、ネイバーを確立することができます。しかし、DR/BDRの要/不要の認識が違っていると、LSDBの同期をうまくとれなかったり、LSDBの同期がとれてFULL状態になってもSPF計算がうまくできなくなります。
解説
R1のshow ip ospf neighborを見ると、Steteが「FULL/ - 」の表示になっています。
R1 show ip ospf neighbor ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ R1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 192.168.2.2 0 FULL/ - 00:00:32 192.168.123.2 FastEthernet0/0 192.168.3.3 0 FULL/ - 00:00:33 192.168.123.3 FastEthernet0/0 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
これは、R1はFastEthernet0/0上にはDR/BDRは存在しないとしています。DR/BDRが存在しないようなインタフェースはPOINT_TO_POINTまたはPOINT_TO_MULTIPOINTのネットワークタイプのインタフェースです。FastEthernet0/0のデフォルトのネットワークタイプはBROADCASTなので、設定によってPOINT_TO_POINTまたはPOINT_TO_MULTIPOINTに変更されていることがわかります。
POINT_TO_POINTの場合は、インタフェース上のネイバーはただ一つになるはずです。FastEthernet0/0上で2つのネイバーを認識していて、DR/BDRが存在しないと言うことはPOINT_TO_MULTIPOINTのネットワークタイプになっています。R1のshow ip ospf interfaceを見ると、FastEthernet0/0がPOINT_TO_MULTIPOINTになっていることが確認できます。POINT_TO_MULTIPOINTのデフォルトのHelloインターバルは30秒です。Helloインターバルがデフォルトの30秒から10秒に変更されていることもわかります。つまり、R1ではFa0/0で次のような設定がされていることになります。
interface FastEthernet0/0 ip ospf network point-to-multipoint ip ospf hello-interval 10
R1 show ip ospf neighbor
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
R1#show ip ospf interface
Loopback0 is up, line protocol is up
Internet Address 192.168.1.1/32, Area 0
Process ID 1, Router ID 192.168.1.1, Network Type LOOPBACK, Cost: 1
Loopback interface is treated as a stub Host
FastEthernet0/0 is up, line protocol is up
Internet Address 192.168.123.1/24, Area 0
Process ID 1, Router ID 192.168.1.1, Network Type POINT_TO_MULTIPOINT, Cost: 1
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:00
Supports Link-local Signaling (LLS)
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 2, Adjacent neighbor count is 2
Adjacent with neighbor 192.168.2.2
Adjacent with neighbor 192.168.3.3
Suppress hello for 0 neighbor(s)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
これがこのトラブルの原因です。
R1のFa0/0はPOINT_TO_MULTIPOINTのネットワークタイプで、DR/BDRは存在しないと思っています。一方、R2とR3のFa0/0はデフォルトのBROADCASTでDR/BDRが存在します。各ルータのネイバーのStateはFULLなので、LSDBの同期自体はとれています。ですが、R1はDR/BDRが存在しないはずのFa0/0のネットワークを表すLSAタイプ2があり、SPF計算を正常に行うことができなくなっています。そのため、R1のルーティングテーブルにはR2やR3のLoopbackインタフェースのルート情報がありません。
OSPFのネットワークタイプは、ネイバーを確立する条件には直接関係していないということをきちんと認識しておきましょう。ネイバーを確立する条件は、Helloパケット内の下記のパラメータが一致していることが条件です。
- エリア番号
- ネットマスク
- Hello/Deadインターバル
- 認証情報
- スタブエリアフラグ
ネットワークタイプによって、Hello/Deadインターバルのデフォルト値が決まるので間接的にはネイバーを確立する条件に関わっています。ですが、ネットワークタイプが違っていてもネイバーにはなれます。ネットワークタイプが違っていてもネイバーになれるのですが、DR/BDRの要/不要の認識がきちんと一致していなければいけません。そうしなければ、この問題のようにネイバーになれてもLSDBの同期がとれなかったり、SPF計算がうまくできなくなります。
つまり、
- POINT_TO_POINTとPOINT_TO_MULTIPOINT
- BROADCASTとNON_BROADCAST
の組み合わせであれば、ネイバーを確立したうえで、正常にLSDBの同期をとってSPF計算もできるようになります。
「ネイバー」とは、同一ネットワーク上のOSPFルータなので、ネットワークタイプはほとんどの場合、一致しているはずです。そのため、実環境ではあまりネットワークタイプが一致しているかどうかは気にしないですし、あえてネットワークタイプを変更することもまずないでしょう。ですが、CCIEラボ試験ではOSPFのネットワークタイプに関する問題は、もうお決まりと言っていいぐらいです。CCIEラボ試験を受験する方は、OSPFのネットワークタイプの理解を深めてください。
