OSPF Fast Hellos 使用時の注意点及びトラブルシューティング方法

Takashi Higashimura · ‎2014-06-17

本ドキュメントは OSPF fast hello 使用時に予め理解しておくべき内容及びトラブルシューティングの方法を記載します。

1. 本ドキュメントのネットワーク構成

2. OSPF設定

R1

interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Ethernet0/0
ip address 10.1.2.1 255.255.255.0
ip ospf dead-interval minimal hello-multiplier 4
!
router ospf 1
router-id 1.1.1.1
network 10.1.2.1 0.0.0.0 area 0
!

R2

interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Ethernet0/0
 ip address 10.1.2.2 255.255.255.0
 ip ospf dead-interval minimal hello-multiplier 4
!
router ospf 1
 router-id 2.2.2.2
 network 10.1.2.2 0.0.0.0 area 0
!

上記の通り、R1/R2 では ip ospf dead-interval minimal hello-multiplier 4 の設定により、holdtime 1秒内に250msec毎に4回Helloを送信する設定となります。
この場合、1秒間 Hello が受信できなければ、OSPF neighbor down となります。

3. OSPFネイバーダウンの確認

OSPF Fast Hellos を使っていない場合と同様に Holdtime (1秒) の間、Hello が受信できない場合は下記メッセージのように Dead timer expired で表示されます。

R2#
*Jun 17 13:50:50.295 JST: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired

4. Dead timer expired の理由

Fast hellos を設定している場合の Dead timer expired となる理由としては一時的な CPU 負荷の上昇があります。
しかしながら、1秒という短い間でCPU負荷がスパイクする場合には show ログからの確認も困難であり、show process cpu history 表示で1秒という短い時間でのCPU負荷のスパイクを捉えることはできません。

IOSの実装では、割り込み処理や OSPF よりも優先度の高い処理がある場合は、OSPF の処理は保留され、先に優先度の高いプロセスが処理されます。また、一つのプロセスがデフォルトで最大 200msec の間、CPUリソースを占有することができるため、単純に計算すると OSPF よりも高い優先度のプロセス処理が 5つ以上続くような場合が発生した時には OSPF Hello の送受処理が1秒間できず、Dead timer expired でネイバーダウンに至ります。

前述の通り、show ログから CPU 負荷の上昇について捉えることは困難ですが OSPF Hello の送受に影響が出ていることは debug ログから判断が可能です。

考えられる方法としては下記 3つの方法があります。

1) debug ip ospf hello の送受間隔

R2#
*Jun 17 14:09:17.593 JST: OSPF-1 HELLO Et0/0: Rcv hello from 1.1.1.1 area 0 10.1.2.1
*Jun 17 14:09:17.837 JST: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.1.2.2
*Jun 17 14:09:17.846 JST: OSPF-1 HELLO Et0/0: Rcv hello from 1.1.1.1 area 0 10.1.2.1
*Jun 17 14:09:18.085 JST: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.1.2.2
*Jun 17 14:09:18.094 JST: OSPF-1 HELLO Et0/0: Rcv hello from 1.1.1.1 area 0 10.1.2.1

通常は上記のように 250msec 間隔で OSPF Hello を送受しています。

R2#
*Jun 17 14:10:59.261 JST: OSPF-1 HELLO Et0/0: Rcv hello from 1.1.1.1 area 0 10.1.2.1
*Jun 17 14:10:59.310 JST: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.1.2.2
*Jun 17 14:10:59.493 JST: OSPF-1 HELLO Et0/0: Rcv hello from 1.1.1.1 area 0 10.1.2.1
*Jun 17 14:10:59.559 JST: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.1.2.2
*Jun 17 14:10:59.798 JST: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.1.2.2
*Jun 17 14:11:00.034 JST: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.1.2.2
*Jun 17 14:11:00.285 JST: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.1.2.2
*Jun 17 14:11:00.497 JST: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired

上記 Dead timer expired となったタイミングの debug を見ると、DOWN の直前に Send hello が続いているものの Rcv hello が見えていないのが分かります。
これには下記2つの理由が考えられます。

自ルータの一時的なCPU高負荷により OSPF Hello の受信処理が1秒以上できなかった
対向ルータの一時的なCPU後負荷により対向ルータが OSPF Hello を1秒以上送信できなかった

上記のいずれかを判断するためには、OSPF Hello をやり取りしているリンクのパケットキャプチャを取得し、キャプチャ上では定期的に送信されてきている Hello が debug 上で見えないということであれば、自ルータの一時的な高負荷と判断できます。

2) show ip ospf neighbor を連続して取得

R262#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/BDR        871 msec    10.1.2.1        Ethernet0/0

R262#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/BDR        585 msec    10.1.2.1        Ethernet0/0

R262#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/BDR     900 msec    10.1.2.1        Ethernet0/0

今回の設定では、250msec 間隔で Hello を受信するため、上記 show ip ospf neighbor の Dead Time は通常 750msec を下回ることはありません。

上記のように連続して show ip ospf neighbor を取得し、上記 "585 msec" のように 750msec を下回っているような状況が定常的に見えるようであれば、一時的なCPU高負荷により OSPF neighbor down が発生しやすい状況にあると言えます。

5. 回避策及び対策

OSPF Fast Hello はプロセス処理のため、前述の IOS のプロセス処理の実装から一時的な CPU高負荷によって DOWN が発生することは避けることができないものとなります。
そのため、設定時には予めCPU高負荷には DOWN する可能性があることを考慮の上、設計/設定する必要があります。

OSPF Fast Hello の代わりに BFD を使うことを検討することは一つの対策として考えられます。BFD は IOS の実装において優先して扱われるようになっているため、OSPF Fast Hello と比較した場合、一時的な CPU高負荷により DOWN する可能性が低くなります。

6. 最後に

前述の通り、OSPF Fast Hellos のトラブルシューティングでは 1sec 未満での一時的なCPU高負荷を捉えることは難しく、上記のように debug やキャプチャを取得して CPU高負荷の影響が考えられるか否かを判断する必要があります。
実環境においては debug 及びキャプチャを取得するのが容易でない場合があるため、そのような場合は Fast Hellos を止め、OSPF holdtime 4秒/Hello 1秒などによる設定変更による切り分けが必要となります。

以上

Anim Saxena · ‎2014-06-17

Hi Takashi,

Thnaks for such a great info posted on CSC and inturn virtually helping the customers. Very nice document.

Regards,

Anim Saxena

Community Manager Security