| ライター翻訳版 - August 31, 2005 |
| 機械翻訳版 - August 10, 2005 |
| 英語版 - August 10, 2005 |
| Document ID: 4808 |
目次
- 概要
ネットワークの例
理由1: ネットワーク トポロジーの変化
理由2: ネットワーク タイプがbroadcastとして定義されている場合
理由3: 1台または複数のルータがデマンド回線を認識していない場合
理由4: ホスト ルートがOSPFデータベースに再配布される場合
関連情報
概要
Open Shortest Path First（OSPF）リンクをデマンド回線として設定すると、OSPF Helloが抑止され、リンク上で定期的なLSAリフレッシュがフラッディングされません。これらのパケットによってリンクがアップになるのは、パケットが初めて交換されたとき、またはパケットに含まれる情報が変化したときに限られます。そのため、ネットワーク トポロジーが安定している場合には、基盤となっているデータ リンク レイヤが閉じられています。デマンド回線がアップしたりダウンしたりする場合、何らかの問題があることを示しています。この資料では、考えられるいくつかの原因とその解決策を示します。
デマンド回線についての詳細は、OSPFデマンド回線機能を参照してください。
ネットワークの例
上記の問題について検討するため、次のようなネットワークおよびコンフィギュレーションを例として使用します。
|
|
|
interface BRI1/1 ip address 192.158.254.13 255.255.255.252 ip ospf demand-circuit router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
interface BRI1/0 ip address 192.158.254.14 255.255.255.252 router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
注: デマンド回線を設定する必要があるのは、リンクの片側だけです。ただし、このコマンドをリンクの両側で設定しても、特に悪影響はありません。
上の図では、ルータ１およびルータ2がISDNリンク上でOSPFデマンド回線を稼働させています。ルータ1とルータ2の間のリンクは、アップの状態を続けていますが、これはOSPFデマンド回線の目的に反しています。show dialerコマンドの出力では、OSPFマルチキャストHelloパケットによってリンクがアップになったことがわかります。
Router1#show dialer BRI1/1:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (2 secs) Dialer state is data link layer up Dial reason: ip (s=192.168.254.13, d=224.0.0.5)
リンクがアップになる理由は、いくつかあります。次に、いくつかの一般的なケースと、その解決策を示します。
理由1: ネットワーク トポロジーの変化
OSPFネットワークのトポロジーに変化があった場合には、OSPFルータへの通知が必要です。この状況では、ネイバが新しい情報を交換できるようにするため、OSPFデマンド回線をアップにする必要があります。新しいデータベースが交換されたあとは、リンクを再びダウンにすることができ、隣接関係はFULLステートに保たれます。
解決策
リンクがアップになった原因がネットワーク トポロジーの変化であるかどうかを判別するには、debug ip ospf monitorコマンドを使用します。このコマンドでは、次のように、どのLSAが変化したかが示されます。
Router1#debug ip ospf monitor OSPF: Schedule SPF in area 0.0.0.0 Change in LS ID 192.168.246.41, LSA type R, OSPF: schedule SPF: spf_time 1620348064ms wait_interval 10s
この出力では、ルータ ID 192.168.246.41のルータLSAが変化したことがわかります。その結果、データベースの再同期化が行われます。ネットワークが安定していれば、このデバッグ出力には何も現れません。
デマンド回線上でのリンク フラップの影響を抑えるには、デマンド回線を含むエリアを完全なスタブ エリアとして設定します。これが不可能であり、かつネットワーク上でリンク フラップが定常的に発生する場合には、デマンド回線は賢明な選択肢ではないと考えられます。
理由2: ネットワーク タイプがbroadcastとして定義されている場合
リンク上にデマンド回線を設定する場合、リンク タイプはpoint-to-pointまたはpoint-to-multipointとして定義する必要があります。これら以外のリンク タイプを定義すると、OSPF Helloが抑止されないために、リンクが不必要にアップする結果となります。次に、ルータ1およびルータ2でこのような問題が発生するコンフィギュレーション例を示します。
|
|
|
interface BRI1/1 ip address 192.158.254.13 255.255.255.252 ip ospf network broadcast router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
interface BRI1/0 ip address 192.158.254.14 255.255.255.252 ip ospf network broadcast router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
ネットワーク タイプをbroadcastとして定義すると、OSPF HelloによってHelloインターバルごとにリンクがアップになります。show dialerコマンドの出力により、リンクが最後にアップされた原因がOSPF Helloであることがわかります。
Router1#show dialer BRI1/1:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (2 secs) Dialer state is data link layer up Dial reason: ip (s=192.168.254.13, d=224.0.0.5) Interface bound to profile Di1 Current call connected 00:00:08 Connected to 57654 (R2)
解決策
この問題を解決するには、ネットワーク タイプをpoint-to-pointまたはpoint-to-multipointに変更します。次に、ネットワーク タイプbroadcastを削除し、デフォルトによりpoint-to-pointに設定する例を示します。
|
|
|
interface BRI1/1 ip address 192.158.254.13 255.255.255.252 router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
interface BRI1/0 ip address 192.158.254.14 255.255.255.252 router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
ネットワーク タイプをpoint-to-pointまたはpoint-to-multipointに変更することによって、リンク上でOSPF Helloが抑止され、デマンド回線リンクのフラップが止まります。
理由3: 1台または複数のルータがデマンド回線を認識していない場合
OSPFドメイン内にデマンド回線を認識していないルータが1台または複数あると、定期的なLSAリフレッシュが発生します。この問題の解決方法については、この資料のOSPFデマンド回線で定期的なLSAリフレッシュが送信される状況とは?を参照してください。
理由4: ホスト ルートがOSPFデータベースに再配布される場合
例として、次のようなネットワークについて考察してみましょう。
ルータ1とルータ2の間のリンクは131.108.1.0/24であり、ルータ1とルータ2の間にはデマンド回線が設定されています。ルータ1が、Routing Information Protocol（RIP）ルートをOSPFに再配布しています。
|
|
router ospf 1 redistribute rip subnets network 131.108.1.0 0.0.0.255 area 1 ! router rip network 131.108.0.0 |
リンクのカプセル化タイプはPPPなので、次のように、両方のルータがリンクの反対側のホスト ルートをインストールします。
Router1#show ip route 131.108.1.2 Routing entry for 131.108.1.2/32 Known via "connected", distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via BRI1/1 Route metric is 0, traffic share count is 1
Interior Gateway Routing Protocol（IGRP)およびRIPは、クラスフル ルーティング プロトコルです。したがって、このコンフィギュレーションのnetworkステートメントでは、131.108.0.0のクラスフル ネットワークを指定しています。そのため、131.108.1.2/32というホスト ルートは、RIPによって生成されたとみなされ、次のように外部ルートとしてOSPFに再配布されます。
Router1#show ip ospf database external 131.108.1.2 OSPF Router with ID (131.108.3.1) (Process ID 1) Type-5 AS External Link States LS age: 298 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 131.108.1.2 (External Network Number ) Advertising Router: 131.108.3.1 LS Seq Number: 80000001 Checksum: 0xDC2B Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0
リンクがダウンすると、/32は消失し、OSPFはこれをトポロジーの変化として認識します。/32マスクのMAXAGEバージョンをネイバに伝達するために、デマンド回線は再びリンクをアップにします。リンクがアップになると、/32マスクが再び有効になり、LSAエージがリセットされます。その後、リンクのdeadタイマーが作動すると、リンクが再びダウンになります。このプロセスが繰り返され、デマンド回線リンクがフラップした状態を続けます。この問題を解決するには、次に示す3通りの方法があります。
解決策1: no peer neighbor-routeコマンドの使用
デマンド回線が稼働するBRIインターフェイスに、no peer neighbor-routeを設定します。この場合、/32マスクのインストールが防止されます。次に示すコンフィギュレーションは、ルータ1でのみ使用することもできますが、一貫性を保つためにリンクの両側でこのコマンドを使用することを推奨します。
R1#configure terminal R1(config)#interface BRI1/1 R1(config-if)#no peer neighbor-route
解決策2: route-mapコマンドの使用
RIPからOSPFへの再配布を行う際、route-mapコマンドを使用して/32を否定し、OSPFデータベースに/32が注入されないようにします。このコンフィギュレーション コマンドが必要なのは、再配布を行うルータ（この例ではルータ1）上だけです。
まず、/32マスクにマッチするアクセス リストを作成する必要があります。次に、このアクセス リストをルート マップに適用し、redistributionコマンドを適用するときにルート マップを使用します。
R1#configure terminal R1(config)#access-list 1 deny host 131.108.1.2 R1(config)#access-list 1 permit any R1#configure terminal R1(config)#route-map rip-ospf R1(config-route-map)#match ip address 1 R1(config)#router ospf 1 R1(config-router)#redistribute rip subnets route-map rip-ospf
解決策3: 異なるメジャー ネットの使用
RIPドメインまたはOSPFドメインのどちらかに、異なるメジャー ネットを使用します。デマンド回線リンクで別のメジャー ネットを使用することにより、PPPカプセル化でリンクがアップするとき、リンクの反対側のホスト ルートがインストールされるようにします。RIPで使用されているものとは別のメジャー ネットにホスト ルートが存在する場合、RIPにはそのメジャー ネットに対応するnetworkステートメントがないので、RIPはPPPによってインストールされるホスト ルートを所有しません。この例を示すネットワーク図は、次のとおりです。
この場合、RIPドメインは141.108.0.0ネットワーク、OSPFドメイン（およびデマンド回線リンク）は131.108.0.0ネットワークに存在します。
関連情報
| Updated:Dec 1, 2003 | Document ID:4808 |