【GRE】再帰ルーティングエラー

GRE トンネルの接続先（アンダーレイ）への経路を、GRE トンネル経由（オーバーレイ）で学習してしまうと、次のようなエラーログが出て、GRE トンネルが安定して使えなくなります。

%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing

これは、アンダーレイのインターフェースでも、オーバーレイのトンネルインターフェースと同じダイナミックルーティングを不用意に動かしたときに起こることがあります。この記事では、OSPF でこのエラーを実際に起こし、なぜトンネルがアップとダウンを繰り返すのかを確認します。

この記事でわかること

アンダーレイとトンネルの両方で OSPF を動かした構成と、経路の選ばれ方
OSPF のコストを変えて、トンネルの宛先への経路をトンネル経由にする
再帰ルーティングエラーでトンネルがアップ・ダウンを繰り返す理由と対策

検証構成
再帰ルーティングエラーが出たときは
まとめ

検証構成

【基本】GREトンネルの設定方法の構成から、R2 と R3 のスタティックルートを削除し、R2、R3、R5 で OSPF を有効にします。R2 と R3 の間には、R5 を経由する GRE トンネル（Tunnel0）があります。

図1　検証構成。アンダーレイ（169.254.0.0）とトンネル（192.168.235.0/24）の両方で OSPF を動かす

機器	Tunnel0 のアドレス	tunnel source → tunnel destination
R2	192.168.235.2/24	169.254.25.2 → 169.254.35.3
R3	192.168.235.3/24	169.254.35.3 → 169.254.25.2

アンダーレイとトンネルで OSPF を動かす

R2 と R3 では、アンダーレイ（169.254.0.0/16）、各端末側の LAN、トンネル（192.168.235.0/24）のすべてで OSPF を有効にします。R5 では、アンダーレイで OSPF を有効にします。

R2(config)#interface Tunnel0
R2(config-if)# ip address 192.168.235.2 255.255.255.0
R2(config-if)# tunnel source 169.254.25.2
R2(config-if)# tunnel destination 169.254.35.3
R2(config-if)#exit   
R2(config)#router ospf 1
R2(config-router)# network 169.254.0.0 0.0.255.255 area 0
R2(config-router)# network 192.168.12.0 0.0.0.255 area 0
R2(config-router)# network 192.168.235.0 0.0.0.255 area 0
R2(config-router)#exit

R3(config)#interface Tunnel0
R3(config-if)# ip address 192.168.235.3 255.255.255.0
R3(config-if)# tunnel source 169.254.35.3
R3(config-if)# tunnel destination 169.254.25.2
R3(config-if)#exit
R3(config)#router ospf 1
R3(config-router)# network 169.254.0.0 0.0.255.255 area 0
R3(config-router)# network 192.168.34.0 0.0.0.255 area 0
R3(config-router)# network 192.168.235.0 0.0.0.255 area 0
R3(config-router)#exit

R5(config)#router ospf 1
R5(config-router)# network 169.254.0.0 0.0.255.255 area 0

R2 のルーティングテーブルを確認します。

R2#show ip route ospf

      169.254.0.0/16 is variably subnetted, 3 subnets, 2 masks
O        169.254.35.0/24 
           [110/2] via 169.254.25.5, 00:17:55, FastEthernet0/0.25 
O     192.168.34.0/24 [110/3] via 169.254.25.5, 00:17:55, FastEthernet0/0.25

トンネルの宛先（169.254.35.3）を含む 169.254.35.0/24 も、R3 側の LAN（192.168.34.0/24）も、トンネルではなく、アンダーレイの物理インターフェース（R5 経由）の経路が選ばれています。

トンネル経由にならないのは、トンネルインターフェースの OSPF コストが大きいためです。show ip ospf interface を見ると、物理インターフェースのコストは 1、トンネルインターフェースのコストは既定で 1000 です。

R2#show ip ospf interface 
FastEthernet0/0.25 is up, line protocol is up 
  Internet Address 169.254.25.2/24, Area 0, Attached via Network Statement
  Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 1 
・・・
Tunnel0 is up, line protocol is up 
  Internet Address 192.168.235.2/24, Area 0, Attached via Network Statement
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 1000

R2 から 169.254.35.0/24 までのコストは、R5 経由なら 1＋1＝2、トンネル経由なら 1000＋1＝1001 です。OSPF はコストの合計が小さい経路を選ぶので、物理インターフェース側の経路が使われます。この状態では、トンネルの宛先への経路はアンダーレイ経由なので、問題は起きません。

R5 のコストを大きくする

次に、R5 の R2 側と R3 側のインターフェースで、OSPF のコストを 10000 にします。R5 を経由する経路のコストが大きくなり、トンネル経由の経路のほうが小さくなります。

R5(config)#interface FastEthernet0/0.25 
R5(config-subif)#ip ospf cost 10000 
R5(config-subif)#exit 
R5(config)#interface FastEthernet0/0.35 
R5(config-subif)#ip ospf cost 10000

そして、R5 で OSPF のプロセスを再起動します。

R5#clear ip ospf process 
Reset ALL OSPF processes? [no]: yes

図2　R5 のコストを変えると、169.254.35.0/24 への経路はトンネル経由のほうがコストが小さくなる

トンネルがアップとダウンを繰り返す

すると、R2 と R3 でトンネルインターフェースがアップとダウンを繰り返し、不安定になります。

R2#
%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down

%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down

トンネルがダウンしているときの R2 のルーティングテーブルを見ると、トンネルの宛先を含む 169.254.35.0/24 を、アンダーレイ（R5 経由、コスト 10001）で受信しています。

R2#show ip route ospf
      169.254.0.0/16 is variably subnetted, 3 subnets, 2 masks
O        169.254.35.0/24 
           [110/10001] via 169.254.25.5, 00:00:26, FastEthernet0/0.25
O     192.168.34.0/24 
           [110/10002] via 169.254.25.5, 00:00:26, FastEthernet0/0.25

この経路でトンネルの宛先に届くので、トンネルインターフェースがアップします。すると、トンネル上でも OSPF の経路交換が始まり、169.254.35.0/24 への経路は、コストの小さいトンネル経由（1001）に変わります。

R2#
 %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

R2#show ip route ospf
O      169.254.35.0/24 [110/1001] via 192.168.235.3, 00:00:04, Tunnel0
O     192.168.34.0/24 [110/1001] via 192.168.235.3, 00:00:04, Tunnel0

ところが、R2 にとって 169.254.35.0/24 は、トンネルを張るために必要な経路（トンネルの宛先 169.254.35.3 への経路）です。それをトンネル経由で学習すると、「トンネルのパケットを宛先に届けるために、そのトンネル自身を通る」という矛盾が起きます。そこで R2 は %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing（再帰ルーティングのエラー）を出力し、トンネルインターフェースを一時的にダウンさせます。

トンネルがダウンすると、トンネル経由の経路は消え、169.254.35.0/24 は再び R5 経由になります。するとトンネルがまたアップし……と、設定を直すまで、トンネルのアップとダウンをずっと繰り返します。

図3　再帰ルーティングでトンネルがアップとダウンを繰り返すしくみ

再帰ルーティングエラーが出たときは

再帰ルーティングのエラーが出たら、アンダーレイの経路（トンネルの宛先への経路）を、オーバーレイ（トンネル）経由で学習しようとしていないかを確認します。show ip route トンネルの宛先アドレス で、トンネルの宛先への経路がトンネルインターフェースを向いていないかを見ると切り分けられます。

対策は、トンネルの宛先への経路が、常にトンネル以外（物理インターフェース側）を向くようにすることです。

対策	内容
トンネルの宛先へのスタティックルート	トンネルの宛先アドレスへ、物理インターフェース側を向くスタティックルート（/32 のホストルートなど）を両端のルータに設定する。プレフィックス長の長い経路が優先されるので、OSPF でトンネル経由の /24 を学習しても、トンネルの宛先への通信は物理側を通る
アンダーレイをトンネル上のルーティングに入れない	アンダーレイ（今回は 169.254.0.0/16）の経路を、トンネル上で動かすルーティングプロトコルに広告しないように設計する

今回の構成なら、例えば R2 で ip route 169.254.35.3 255.255.255.255 169.254.25.5、R3 で ip route 169.254.25.2 255.255.255.255 169.254.35.5 のように、相手のトンネルの宛先を R5 経由に固定します。

まとめ

項目	内容
エラー	`%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing`
原因	トンネルの宛先への経路を、トンネル自身から学習した
今回のきっかけ	アンダーレイとトンネルで同じ OSPF を動かし、R5 のコストを 10000 にしてトンネル経由（1001）のほうが小さくなった
症状	トンネルのダウン → 経路が物理側に戻る → トンネルのアップ → 経路がトンネル経由になる → ダウン、を繰り返す
対策	トンネルの宛先への経路が常に物理側を向くようにする（スタティックのホストルート、アンダーレイをトンネル上のルーティングに入れない）