Hierarchical Navigation |
目次概要前提条件 要件 使用するコンポーネント 表記法 ネットワークの例 理由 1：ネットワーク トポロジの変化 解決策 理由 2：ネットワーク タイプが broadcast として定義されている 解決策 理由 3：1 台以上のルータがデマンド回線を認識していない 理由 4：ホスト ルートが OSPF データベースに再配布される 解決策 1：no peer neighbor-route コマンドの使用 解決策 2：route-map コマンドの使用 解決策 3：異なるメジャー ネットの使用 理由 5：OSPF デマンド回線が非同期インターフェイスで構成されている 解決策 理由 6：OSPF デマンド回線がマルチリンク PPP で構成されている 解決策 Cisco サポート コミュニティ - 特集対話 関連情報 概要Open Shortest Path First（OSPF）リンクをデマンド回線として設定すると、OSPF Hello が抑止され、リンク上で定期的な LSA リフレッシュがフラッディングされません。これらのパケットによってリンクがアップになるのは、パケットが初めて交換されたとき、またはパケットに含まれる情報が変化したときに限られます。そのため、ネットワーク トポロジが安定している場合には、基盤となっているデータリンク層が閉じられています。デマンド回線がアップしたりダウンしたりする場合、何らかの問題があることを示しています。このドキュメントでは、考えられるいくつかの原因とその解決策を示します。 デマンド回線の詳細については、「OSPF デマンド回線の機能」を参照してください。 前提条件要件このドキュメントに関する特別な要件はありません。 使用するコンポーネントこのドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。 表記法ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。 ネットワークの例次のようなネットワーク図と設定を使用して、前述の問題を説明します。
注：デマンド回線を設定する必要があるのは、リンクの片側だけです。ただし、このコマンドをリンクの両側で設定しても、特に問題はありません。 この図では、ルータ 1 とルータ 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 として定義されているリンク上にデマンド回線を設定する場合、リンク タイプをポイントツーポイントまたはポイントツーマルチポイントとして定義する必要があります。ネットワーク タイプがポイントツーポイントまたはポイントツーマルチポイント以外の場合、OSPF Hello が抑止されないために、その他のリンク タイプではリンクが不必要にアップします。ルータ 1 およびルータ 2 でこの問題が発生する設定例を次に示します。
ネットワーク タイプを 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) 解決策この問題を解決するには、ネットワーク タイプをポイントツーポイントまたはポイントツーマルチポイントに変更します。ここでネットワーク タイプ broadcast を削除すると、デフォルトでポイントツーポイントに設定されます。
ネットワーク タイプをポイントツーポイントまたはポイントツーマルチポイントに変更すると、リンク上で OSPF Hello が抑止され、デマンド回線リンクのフラップが停止します。 理由 3：1 台以上のルータがデマンド回線を認識していないOSPF ドメイン内にデマンド回線を認識していないルータが 1 台以上あると、定期的な LSA リフレッシュが発生します。この問題の解決方法については、このドキュメントの「定期的な LSA リフレッシュが OSPF デマンド回線で送信される条件」を参照してください。 理由 4：ホスト ルートが OSPF データベースに再配布されるたとえば、次のようなネットワーク図について考えます。
ルータ 1 とルータ 2 の間のリンクは 131.108.1.0/24 であり、ルータ 1 とルータ 2 の間にはデマンド回線が設定されています。ルータ 1 は Routing Information Protocol（RIP; ルーティング情報プロトコル）ルートを OSPF に再配布しています。
リンクのカプセル化タイプは 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 エージがリセットされます。その後、リンクのデッド タイマーが作動すると、リンクが再びダウンになります。このプロセスは自動的に繰り返され、デマンド回線リンクはフラッピングした状態のままになります。この問題を解決するには、次の 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 にはそのメジャー ネットに対応するネットワーク ステートメントがないため、RIP はこの PPP によってインストールされるホスト ルートを所有しません。次のネットワーク図は、この例を示しています。
この場合、RIP ドメインは 141.108.0.0 ネットワークに存在し、OSPF ドメイン（およびデマンド回線リンク）は 131.108.0.0 ネットワークに存在します。 理由 5：OSPF デマンド回線が非同期インターフェイスで構成されているデマンド回線を非同期（async）インターフェイスで設定する場合、レイヤ 2 がダウンすると、実際の物理インターフェイスもダウンします。これにより、OSPF データベースが変更され、非同期インターフェイスがもう一度起動し、データベースを交換します。レイヤ 2 は再度ダウンし、さらにデータベースが変更されるため、自動的にこのプロセスが繰り返されます。 次のシナリオを使用して、この問題を再現します。
上記のシナリオでは、次の設定を使用しています。
非同期インターフェイスでの OSPF のデフォルト ネットワーク タイプはポイントツーポイントですが、デマンド回線はリンクを繰り返しアップします。 Rouer1# show ip ospf interface Async1
Async1 is up, line protocol is up (spoofing)
Internet Address 192.158.254.13/32, Area 1
Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:869
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:02
Index 1/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
解決策デマンド回線がリンクを繰り返しアップする理由は、アイドル タイムアウトの期限が切れた後にレイヤ 2 がダウンすると、すべてのインターフェイスがダウンするためです。しかし、BRI または PRI の場合は、チャネルの 1 つがダウンしても、インターフェイスは（スプーフィング モードで）アップしたままになります。ダイヤラ インターフェイスはダウンしないため、問題を解決するにはダイヤラ インターフェイスを設定する必要があります。ダイヤラ インターフェイスは（スプーフィング モードで）アップしたままになります。
ダイヤラ インターフェイスはダウンしないため、非同期インターフェイスがダウンしたときのような問題は発生しません。 理由 6：OSPF デマンド回線がマルチリンク PPP で構成されているマルチリンク PPP 機能を使用すると、複数の WAN リンクがある場合に、ロード バランシングを実行できます。OSPF について注意すべき重要な点の 1 つは、マルチリンク PPP の帯域幅です。複数のリンクが組み合わされている場合、マルチリンク インターフェイスの帯域幅は変わります。 次のシナリオを使用して、この問題を再現します。
上記のシナリオでは、次の設定を使用しています。
次の出力は、マルチリンク PPP に集束されているシリアル インターフェイスが 3 つあることを示しています。 Router1# show ppp multilink
Multilink1, bundle name is Router2
Bundle up for 00:05:35
Bundle is Distributed
0 lost fragments, 0 reordered, 0 unassigned
0 discarded, 0 lost received, 3/255 load
0x1226 received sequence, 0x1226 sent sequence
Member links: 3 active, 0 inactive (max not set, min not set)
Serial1/0/0:0, since 00:05:35, no frags rcvd
Serial1/0/1:0, since 00:05:35, no frags rcvd
Serial1/0/2:0, since 00:05:35, no frags rcvd
インターフェイスの帯域幅は、リンクの集約された帯域幅を表し、この帯域幅は OSPF のコスト計算に使用されます。 Router1# show interface multilink 1
Multilink1 is up, line protocol is up
Hardware is multilink group interface
Internet address is 192.168.254.1/24
MTU 1500 bytes, BW 5952 Kbit, DLY 100000 usec,
reliability 255/255, txload 3/255, rxload 3/255
Encapsulation PPP, loopback not set
Keepalive set (10 sec)
DTR is pulsed for 2 seconds on reset
LCP Open, multilink Open
Open: IPCP
Last input 00:00:00, output never, output hang never
Last clearing of "show interface" counters 00:06:39
Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 241000 bits/sec, 28 packets/sec
5 minute output rate 241000 bits/sec, 28 packets/sec
6525 packets input, 9810620 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
6526 packets output, 9796112 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
show ip ospf interface の出力には、現在の OSPF コストである 16 が示されています。 Router1# show ip ospf interface multilink 1
Multilink1 is up, line protocol is up
Internet Address 192.158.254.13/24, Area 1
Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:16
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:02
Index 1/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
このリンクがダウンすると、ログにはリンクがダウンしたことが示されます。 Router1# show log | include down %LINK-3-UPDOWN: Interface Serial1/0/0:0, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0/0:0, changed state to down 帯域幅を再度確認すると、以前とは異なる帯域幅が示されます。今回は 3968 と示され、集束には 3 つではなく 2 つのインターフェイスだけが表示されます。これは、インターフェイスが 1 つダウンしたためです。次では、インターフェイスはまだアップしていることに注意してください。 Router1# show ppp multilink
Multilink1, bundle name is Router2
Bundle up for 00:05:35
Bundle is Distributed
0 lost fragments, 0 reordered, 0 unassigned
0 discarded, 0 lost received, 3/255 load
0x1226 received sequence, 0x1226 sent sequence
Member links: 2 active, 1 inactive (max not set, min not set)
Serial1/0/1:0, since 00:05:35, no frags rcvd
Serial1/0/2:0, since 00:05:35, no frags rcvd
Serial1/0/0:0 (inactive)
また、PPP マルチリンクは引き続き表示されていますが、リンクが 1 つダウンしているため、OSPF コストは 25 に変わりました。 Router1# show ip ospf interface multilink 1
Multilink1 is up, line protocol is up
Internet Address 192.158.254.13/24, Area 1
Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:25
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:02
Index 1/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
これにより SPF の計算が実行され、OSPF はデマンド回線をアップします。リンクがフラッピングを繰り返す場合、リンクがマルチリンク PPP バンドルに追加されたり、削除されたりするたびにコストが変わるため、デマンド回線もフラッピングを繰り返す可能性があります。 解決策PPP マルチリンクは OSPF でサポートされていますが、バンドル内のすべてのリンクが起動している限り、デマンド回線は安定しています。リンクに関連付けられている IP アドレスがなくても、そのリンクがダウンするとすぐに OSPF コスト計算は影響を受けます。そのため、OSPF は SPF を実行して最適なパスを再計算します。この問題を解決する唯一の解決策は、次のコマンドを使用して、OSPF コストを手動で設定することです。
このコマンドを実行すると、リンクがマルチリンク PPP バンドルに追加または削除されても、OSPF コストへの影響はなくなります。そのため、PPP マルチリンク上で OSPF デマンド回線が安定します。 Cisco サポート コミュニティ - 特集対話関連情報 |
| 
