GREトンネルのキープアライブについて

はじめに

このドキュメントでは、総称ルーティングカプセル化(GRE)キープアライブとその仕組みについて説明します。

GRE トンネル

GREトンネルは、トランスポートプロトコル内のネットワークプロトコルパケットをカプセル化する方法を提供するルータ上の論理インターフェイスです。これは、ポイントツーポイントカプセル化スキームでネットワークトラフィックの転送を提供するメカニズムです。

GRE トンネルは、完全にステートレスになるように設計されています。つまり、各トンネル エンドポイントは、リモート トンネル エンドポイントの状態または可用性に関する情報を保持しないということを意味します。この結果、トンネルのリモート エンドに到達不能な場合、ローカル トンネル エンドポイント ルータは GRE トンネル インターフェイスの回線プロトコルをダウンさせる機能がありません。そのインターフェイスを発信インターフェイスとして使用するルーティング テーブル内のルート（特にスタティック ルート）を削除するために、リンクのリモート エンドが利用できない場合にインターフェイスをダウンとしてマークする機能が使用されます。具体的には、インターフェイスの回線プロトコルがダウンに変更された場合、そのインターフェイスを指すスタティック ルートはルーティング テーブルから削除されます。これにより、代替のネクストホップまたはインターフェイスを選択するために、代替（フローティング）スタティック ルートまたはポリシー ベース ルーティング（PBR）のインストールが可能になります。

通常、GREトンネルインターフェイスは、設定されるとすぐにアップし、有効なトンネル送信元アドレスまたはアップ状態のトンネル送信元インターフェイスがある限り、アップ状態を維持します。トンネルの宛先 IP アドレスもルーティング可能である必要があります。これは、トンネルの反対側が設定されていない場合にも必要です。これは、GRE トンネル インターフェイスを経由するパケットのスタティック ルートまたは PBR フォワーディングは、GRE トンネル パケットがトンネルの他方の終端に到達しない場合でも、依然として有効であることを意味します。

GREキープアライブが実装される前は、ルータのローカルな問題を判別する方法しかなく、トランスポートネットワークの問題を判別する方法はありませんでした。たとえば、GRE トンネリングされたパケットが転送に成功しても、トンネルのもう一方の端に達する前に失われるケースです。このようなシナリオでは、PBRを使用する代替ルートまたは別のインターフェイスを介したフローティングスタティックルートが使用可能であったとしても、GREトンネルを通過するデータパケットが「ブラックホール化」されます。GRE トンネルのインターフェイスのキープアライブは、キープアライブが物理インターフェイスで使用されるのと同様にこの問題を解決するために使用されます。

注:GREキープアライブは、どのような状況であってもIPSecトンネル保護とともにはサポートされません。このドキュメントでは、この問題について説明します。

トンネルのキープアライブの動作方法

GRE トンネル キープアライブ メカニズムは、リモート ルータが GRE キープアライブをサポートしない場合でも一方がリモート ルータとの間でキープアライブ パケットを発信および受信できる点で、PPP キープアライブと似ています。GRE は IP 内で IP をトンネリングするパケット トンネリング メカニズムなので、別の GRE IP トンネル パケットの内部に GRE IP トンネル パケットを構築できます。GRE キープアライブの場合、送信者は元のキープアライブ要求パケット内にキープアライブ応答パケットを事前に構築するため、リモート エンドは外部 GRE IP ヘッダーの標準 GRE カプセル化解除を実行し、内部 IP GRE パケットを送信者に戻すだけで十分です。次のパケットは、IP トンネリングの概念を示しています。この場合、GRE がカプセル化プロトコルで、IP がトランスポート プロトコルです。パッセンジャプロトコルもIPです（ただし、NHRPのような別のプロトコルを使用することもできます）。

ノーマル パケット：

トンネリングされたパケット：

• IP はトランスポート プロトコルです。
• GRE はカプセル化プロトコルです。
• IP はパッセンジャ プロトコルです。

ルータ A から送信され、ルータ B を宛先とするキープアライブ パケットの例を示します。ルータ B がルータ A に戻すキープアライブの応答は内部の IP ヘッダー内にすでにあります。ルータ B は単にキープアライブ パケットをカプセル化解除して、それを物理インターフェイス（S2）に送り返すだけです。 その他の GRE IP データ パケットと同様に GRE キープアライブ パケットを処理します。

GRE キープアライブ：

このメカニズムにより、キープアライブ応答がトンネルインターフェイスではなく物理インターフェイスから転送されるようになります。つまり、GREキープアライブ応答パケットは、「tunnel protection ...」などのトンネルインターフェイスの出力機能の影響を受けません。 QoS、Virtual Routing and Forwarding(VRF)など

注:GREトンネルインターフェイスに着信アクセスコントロールリスト(ACL)が設定されている場合、相手側のデバイスが送信するGREトンネルのキープアライブパケットが許可される必要があります。そうでない場合は、相手側のデバイスのGREトンネルがダウンします。(access-list <number> permit gre host <tunnel-source> host <tunnel-destination>)

GRE トンネル キープアライブのもう 1 つの特性は、PPP キープアライブと同様に、各側のキープアライブ タイマーが独立しており、一致する必要がないという点です。

ヒント：トンネルの片側だけでキープアライブを設定することの問題点は、キープアライブタイマーの期限が切れた場合、キープアライブが設定されているルータだけがトンネルインターフェイスをダウンしたとマーキングすることです。キープアライブが設定されていない反対側の GRE トンネルのインターフェイスは、トンネルの相手側がダウンした場合でもアップ状態のままです。キープアライブが設定されていない側からトンネルに送信されたパケットに対しては、トンネルがブラックホールになる可能性があります。

ヒント：大規模なハブアンドスポークGREトンネルネットワークでは、GREキープアライブをハブ側ではなくスポーク側でのみ設定するのが適切な場合があります。これは、多くの場合、スポークにとってハブが到達不能であることを検出し、バックアップパス（ダイヤルバックアップなど）に切り替えることの方が重要であるためです。

GRE トンネルのキープアライブ

Cisco IOS® ソフトウェア リリース 12.2(8)T では、ポイントツーポイントの GRE トンネル インターフェイスにキープアライブを設定できます。この変更によって、トンネル インターフェイスは、一定期間キープアライブが失敗した場合に、動的にシャットダウンします。

その他の形式のキープアライブの仕組みの詳細は、「Cisco IOS でのキープアライブ メカニズムの概要」を参照してください。

注:GREトンネルのキープアライブがサポートされているのは、ポイントツーポイントのGREトンネルでだけです。トンネルのキープアライブは、マルチポイント GRE（mGRE）トンネルでも設定できますが、効果はありません。

注：一般に、VRFがトンネルインターフェイスで使用されていて、fVRF(tunnel vrf ...)とiVRF(ip vrf forwarding ...、トンネルインターフェイス)が一致していない場合は、トンネルのキープアライブが機能しません。これは、キープアライブを要求者に再び反映するトンネルエンドポイントで重要です。キープアライブ要求が受信されるとき、fVRF で受信され、カプセル化解除されます。これにより、送信者に転送する必要がある事前に作成されたキープアライブ応答が表出しますが、その転送はトンネル インターフェイスの iVRF のコンテキストです。したがって、iVRF と fVRF が一致しない場合、キープアライブ応答パケットは送信者に転送されません。これは、iVRFやfVRFをglobalに置き換えた場合にも当てはまります。

この出力は、GRE トンネルにキープアライブを設定するために使用するコマンドを示しています。

Router#configure terminal
Router(config)#interface tunnel0
Router(config-if)#keepalive 5 4          

!--- The syntax of this command is keepalive [seconds [retries]].

!--- Keepalives are sent every 5 seconds and 4 retries.
!--- Keepalives must be missed before the tunnel is shut down.
!--- The default values are 10 seconds for the interval and 3 retries.

トンネル キープアライブ メカニズムの仕組みの理解を深めるため、この例のトンネル トポロジと構成を考えてみましょう。

ルータ A：

interface loopback 0
  ip address 192.168.1.1 255.255.255.255
interface tunnel 0
  ip address 10.10.10.1 255.255.255.252
  tunnel source loopback0
  tunnel destination 192.168.1.2
  keepalive 5 4

ルータ B：

interface loopback 0
  ip address 192.168.1.2 255.255.255.255
interface tunnel 0
  ip address 10.10.10.2 255.255.255.252
  tunnel source loopback0
  tunnel destination 192.168.1.1
  keepalive 5 4 

このシナリオでは、ルータ A で次のステップを実行します。

• • 送信元はローカルのトンネルの宛先（192.168.1.2）として設定
  • 宛先がローカルトンネル送信元(192.168.1.1)として設定され、 
  • プロトコルタイプ(PT)0でGREヘッダーが追加される内部IPヘッダーを5秒ごとに作成します。
  
  ルータ A によって生成されるが送信されないパケット
  

  IP ヘッダー		GRE
  Source:192.168.1.2	Destination:192.168.1.1	PT=0

  
  
  

そのパケットをトンネル インターフェイスから送信し、その結果、次のように外部 IP ヘッダーでパケットがカプセル化されます。

• 送信元はローカルのトンネルの送信元（192.168.1.1）として設定
• 宛先がローカルトンネルの宛先として設定されている（この場合は192.168.1.2）。
• GREヘッダーはPT = IPで追加されます。
  
  ルータ A からルータ B に送信されたパケット：

• トンネル キープアライブ カウンタを 1 ずつ増加させます。
• 遠端トンネルのエンドポイントに到達する方法があり、トンネルの回線プロトコルが何らかの理由によりダウンしていない場合には、パケットはルータ B に到達します。トンネル 0 に対して照合され、カプセル化解除されると、ルータ A のトンネル送信元 IP アドレスの宛先 IP に転送されます。
  
  ルータ B からルータ A へ送信：
  

  IP ヘッダー		GRE
  Source:192.168.1.2	Destination:192.168.1.1	PT=0

  
  
  
• ルータ A で着信すると、パケットはカプセル化解除され、PT のチェックが 0 になります。このことは、これがキープアライブ パケットであることを示します。その後、トンネルのキープアライブ カウンタは 0 にリセットされ、パケットは廃棄されます。

ルータ B が到達不能な場合、ルータ A は通常のトラフィックとともにキープアライブ パケットの生成と送信を続行します。キープアライブが戻ってこない場合、トンネルの回線プロトコルは、トンネル キープアライブ カウンタが再試行回数（このケースでは 4 回）未満である限り、アップ状態のままになります。この条件が true でない場合、次回ルータ A がルータ B にキープアライブを送信しようとするときに回線プロトコルがダウンします。

注：アップ/ダウン状態では、トンネルはデータトラフィックを転送または処理しません。ただし、キープアライブ パケットを送信し続けます。キープアライブ応答を受信し、トンネル エンドポイントが到達可能であることが再度示唆されると、トンネル キープアライブ カウンタは 0 にリセットされ、トンネルの回線プロトコルはアップ状態になります。

操作でキープアライブを確認するには、debug tunnel と debug tunnel keepalive を有効にします。

ルータ A からのデバッグの例：

debug tunnel keepalive
        Tunnel keepalive debugging is on
        01:19:16.019: Tunnel0: sending keepalive, 192.168.1.1->192.168.1.2
        (len=24 ttl=0), counter=15
        01:19:21.019: Tunnel0: sending keepalive, 192.168.1.1->192.168.1.2
        (len=24 ttl=0), counter=16
        01:19:26.019: Tunnel0: sending keepalive, 192.168.1.1->192.168.1.2
        (len=24 ttl=0), counter=17

GRE キープアライブと Unicast Reverse Path Forwarding

ユニキャスト RPF（Unicast Reverse Path Forwarding）は、ルーティング テーブルに対してパケット送信元アドレスの検証を行うことでスプーフィングされた IP トラフィックを検出および破棄できるセキュリティ機能です。 ユニキャスト RPF がストリクトモード（ip verify unicast source reachable-via rx）で実行されるときは、戻りパケットを転送するためにルータが使用するインターフェイスでパケットを受信する必要があります。GREキープアライブパケットを受信するルータのトンネルインターフェイスでstrictモードまたはlooseモードのユニキャストRPFが有効になっている場合、パケットの送信元アドレス（ルータ自身のトンネル送信元アドレス）へのルートがトンネルインターフェイスを経由しないため、トンネルのカプセル化解除後にRPFによってキープアライブパケットがドロップされます。RPF パケット ドロップは、次に示す show ip traffic 出力で確認できます。

Router#show ip traffic | section Drop 
 Drop: 0 encapsulation failed, 0 unresolved, 0 no adjacency
 0 no route, 156 unicast RPF, 0 forced drop
 0 options denied 

その結果、キープアライブの戻りパケットの損失が原因で、トンネルのキープアライブの発信側がトンネルをダウンさせます。このため、GRE トンネル キープアライブが機能するためには、ユニキャスト RPF をストリクト モードまたはルーズ モードで設定してはなりません。ユニキャスト RPF の詳細については、「Unicast Reverse Path Forwarding について」を参照してください。

IPsec と GRE キープアライブ

IPsec を使用する GRE トンネル

IPsec は IP マルチキャスト パケットをサポートしないため、GRE トンネルは IPsec と組み合わせることがあります。このため、ダイナミック ルーティング プロトコルは IPsec VPN ネットワークを介して正常に実行できません。GRE トンネルでは IP マルチキャストがサポートされているので、GRE トンネル上ではダイナミック ルーティング プロトコルが動作します。その結果の GRE IP ユニキャスト パケットは、IPsec で暗号化できます。

IPsec が GRE パケットを暗号化できる方法は 2 つあります。

• 1 つは、暗号マップを使用する方法です。暗号マップを使用すると、GRE トンネル パケットのアウトバウンド物理インターフェイスに適用されます。この場合、一連のステップは次のようになります。
  
  
  1. 暗号化されたパケットが物理インターフェイスに到達します。
  2. パケットは復号され、トンネル インターフェイスに転送されます。
  3. パケットはカプセル化解除され、クリア テキストで IP の宛先に転送されます。
  
  
  
• もう 1 つは、トンネル保護を使用する方法です。トンネル保護を使用する場合は、GRE トンネル インターフェイスに設定します。tunnel protection コマンドは、Cisco IOS ソフトウェア リリース 12.2(13)T で導入されました。この場合、一連のステップは次のようになります。
  
  
  1. 暗号化されたパケットが物理インターフェイスに到達します。
  2. パケットがトンネル インターフェイスに転送されます。
  3. パケットは復号されてカプセル化解除され、クリア テキストで IP の宛先に転送されます。

いずれの方法も、IPsec 暗号化が GRE カプセル化の追加後に実行されることを指定します。暗号マップを使用する場合とトンネル保護を使用する場合とには、2 つの主な違いがあります。

• IPsec 暗号マップは物理インターフェイスに関連付けられ、パケットが物理インターフェイスに転送されるときにチェックされます。GRE トンネルでは、この時点ですでにパケットを GRE カプセル化しています。
• トンネル保護では暗号化機能が GRE トンネルに結び付けられており、パケットが GRE カプセル化された後、物理インターフェイスに送られる前にチェックされます。

IPsec と GRE を組み合わせる場合のキープアライブの問題

GRE トンネルに暗号化を追加する 2 つの方法を考えると、暗号化された GRE トンネルをセットアップする方法は 3 つあります。

1. ピア A はトンネル インターフェイスでトンネル保護を設定し、ピア B は物理インターフェイスで暗号マップを設定する。
2. ピア A は物理インターフェイスで暗号マップを設定し、ピア B はトンネル インターフェイスでトンネル保護を設定する。
3. 両方のピアがトンネル インターフェイスでトンネル保護を設定する。

シナリオ 1 と 2 で説明する構成は、多くの場合、ハブアンドスポーク設計で行われます。トンネル保護は、設定の規模を小さくするためにハブ ルータで設定し、スタティックな暗号マップは各スポークで使用します。

ピア B（スポーク）で GRE キープアライブを有効にするこれらの各シナリオを検討し、どこで暗号化にトンネル モードを使用するのかを考えてみましょう。

シナリオ 1

設定：

• ピア A はトンネル保護を使用します。
• ピア B は暗号マップを使用します。
• キープアライブはピア B で有効になっています。
• IPsec 暗号化は、トンネル モードで実行されます。

このシナリオでは、GRE キープアライブがピア B で設定されるため、キープアライブが生成されるときの一連のイベントは次のようになります。

1. ピア B はキープアライブ パケットを生成します。これは GRE カプセル化されてから物理インターフェイスに転送され、ここで暗号化されてトンネルの宛先であるピア A に送信されます。
   
   ピア B からピア A に送信されたパケット：
   

   IP ヘッダー	ESP ヘッダー	GRE IP ヘッダー		GRE ヘッダー	IP ヘッダー GRE ソースA 宛先B PT=0	ESP トレーラ
   ソースB	宛先A	ソースB	宛先A	PT=IP

   
   
   
2. ピア A で、GRE キープアライブは復号化されて受信されます。
   

   GRE IP ヘッダー		GRE	IP ヘッダー GRE ソースA 宛先B  PT=0
   ソースB	宛先A	PT=IP

   
   
   カプセル化解除されます。
   

   IP ヘッダー		GRE
   ソースA	宛先B	PT=0

   
   
   次に、内部GREキープアライブ応答パケットは、宛先アドレス（ピアB）に基づいてルーティングされます。これは、ピア A ではパケットが物理インターフェイスからピア B にすぐにルーティングされることを意味します。ピア A はトンネル インターフェイスでトンネル保護を使用するため、キープアライブ パケットは暗号化されません。
   
   したがって、ピア A からピア B に送信されたパケットは次のとおりです。
   

   IP ヘッダー		GRE
   ソースA	宛先B	PT=0

   
   

   注：キープアライブは暗号化されていません。

3. これでピア B は物理インターフェイスで暗号化されていない GRE キープアライブ応答を受信しますが、物理インターフェイスで暗号マップが設定されているため、暗号化されたパケットが要求され、破棄されます。

そのため、ピアAがキープアライブに応答し、ルータのピアBが応答を受信しても、ピアBは応答を処理しないため、最終的にはトンネルインターフェイスの回線プロトコルをダウン状態に変更します。

Result:

ピア B でキープアライブが有効になっていると、ピア B のトンネルの状態はアップ/ダウンに変更されます。

シナリオ 2

設定：

• ピア A は暗号マップを使用します。
• ピア B はトンネル保護を使用します。
• キープアライブはピア B で有効になっています。
• IPsec 暗号化は、トンネル モードで実行されます。

このシナリオでは、GRE キープアライブがピア B で設定されるため、キープアライブが生成されるときの一連のイベントは次のようになります。

1. ピア B はキープアライブ パケットを生成します。これは GRE カプセル化されてからトンネル インターフェイスでトンネル保護によって暗号化され、物理インターフェイスに転送されます。
   
   ピア B からピア A に送信されたパケット：
   

   IP ヘッダー	ESP ヘッダー	GRE IP ヘッダー	GRE ヘッダー	IP ヘッダー GRE ソースA 宛先B PT=0	ESP トレーラ
   ソースB	宛先A	ソースB	宛先A	PT=IP

   
   
   
2. ピア A で、GRE キープアライブは復号化されて受信されます。
   

   GRE IP ヘッダー		GRE	IP ヘッダー GRE ソースA 宛先B  PT=0
   ソースB	宛先A	PT=IP

   
   
   カプセル化解除されます。
   

   IP ヘッダー		GRE
   ソースA	宛先B	PT=0

   
   
   次に、内部GREキープアライブ応答パケットは、宛先アドレス（ピアB）に基づいてルーティングされます。これは、ピア A ではパケットが物理インターフェイスからピア B にすぐにルーティングされることを意味します。ピアAは物理インターフェイス上で暗号マップを使用するため、このパケットを転送する前にまず暗号化します。
   
   したがって、ピア A からピア B に送信されたパケットは次のとおりです。
   

   IP ヘッダー		ESP ヘッダー	IP ヘッダー GRE ソースA 宛先B PT=0	ESP トレーラ
   ソースB	宛先A

   
   

   注：キープアライブ応答は暗号化されています。

3. ピアBは、暗号化されたGREキープアライブ応答を受信します。この応答は、宛先が復号化されるトンネルインターフェイスに転送されます。
   

   IP ヘッダー		GRE
   ソースA	宛先B	PT=0

   
   プロトコル タイプが 0 に設定されているため、ピア B はこれがキープアライブ応答であることを認識し、それに応じた処理を行います。

Result:

ピアBで有効にされたキープアライブにより、トンネルの状態がトンネルの宛先のアベイラビリティに基づいて判断されます。

シナリオ 3

設定：

• 両方のピアでトンネル保護を使用します。
• キープアライブはピア B で有効になっています。
• IPsec 暗号化は、トンネル モードで実行されます。

このシナリオは、ピア A が暗号化されたキープアライブを受信し、復号してカプセル化解除する点でシナリオ 1 と似ています。ただし、応答が転送される場合、ピア A がトンネル インターフェイスでトンネル保護を使用するため、暗号化されません。したがって、ピア B は暗号化されていないキープアライブ応答を破棄し、処理しません。

Result:

ピア B でキープアライブが有効になっていると、ピア B のトンネルの状態はアップ/ダウンに変更されます。

回避策

GRE パケットを暗号化する必要があるこのような状況では、利用可能な解決策は 3 つあります。

1. ピア A で暗号マップ、ピア B でトンネル保護を使用し、ピア B でキープアライブを有効にします。
   
   このタイプの設定は主にハブアンドスポークのセットアップで使用され、このようなセットアップではスポークがハブの到達可能性を認識することが重要であるため、解決策はハブ（ピアA）でダイナミック暗号マップを使用し、スポーク（ピアB）でトンネル保護を使用し、スポークでGREキープアライブを有効にすることです。この方法では、ハブの GRE トンネル インターフェイスはアップ状態のままですが、トンネル経由のルーティング ネイバーとルートは失われ、代替ルートを確立できます。スポークでは、トンネル インターフェイスがダウンしたことによって、ダイヤラ インターフェイスの起動とハブ（またはハブで別のルータ）へのコール バックが行われ、新しい接続が確立されます。
   
   
2. ピアの到達可能性を判断するために GRE キープアライブ以外の方法を使用します。
   
   両方のルータでトンネル保護が設定されている場合、GRE トンネル キープアライブはどちらの方向にも使用できません。この場合、ピアが到達可能であるかどうかを検出するための唯一のオプションは、ルーティング プロトコルやサービス保証エージェントなどのその他のメカニズムを使用することです。
   
   
3. ピア A とピア B で暗号マップを使用します。
   
   両方のルータで暗号マップが設定されている場合、トンネル キープアライブは両方向で使用でき、GRE トンネル インターフェイスはいずれかまたは両方向でシャットダウンでき、バックアップ接続の作成をトリガーできます。これは最も柔軟性の高いオプションです。

関連情報

• RFC 1701, Generic Router Encapsulation (GRE)
• RFC 2890, Key and Sequence Number Extensions to GRE
• 総称ルーティング カプセル化（GRE）トンネルのキープアライブ
• IP フラグメンテーションと PMTUD
• Cisco IOS でのキープアライブ メカニズムの概要
• テクニカルサポート - Cisco Systems