IP : 総称ルーティング カプセル化(GRE)

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

2005 年 8 月 10 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2015 年 6 月 29 日) | 英語版 (2015 年 4 月 23 日) | フィードバック

目次

概要
前提条件
      要件
      使用するコンポーネント
      表記法
GRE トンネルのキープアライブ メカニズム
      GRE トンネル
      一般的なキープアライブ メカニズム
      イーサネットのキープアライブ
      HDLC のキープアライブ
      GRE トンネルのキープアライブ
      トンネルのキープアライブの動作方法
IPsec と GRE のキープアライブ
      IPSec が備わった GRE トンネル
      IPSec と GRE を組み合わせたときのキープアライブに関する問題
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

この文書では、GRE キープアライブとその仕組みについて説明します。 『総称ルーティング カプセル化(GRE)トンネルのキープアライブ』文書では、GRE トンネルのキープアライブは tunnel protection ipsec profile コマンドとの組み合わせではサポートされないとしています。 この文書では、この問題と、これらの機能が同時に動作するケースについて説明します。

前提条件

要件

この文書に関する特別な要件はありません。

使用するコンポーネント

この文書は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

表記法

文書表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

GRE トンネルのキープアライブ メカニズム

GRE トンネル

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

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

GRE キープアライブが実装される以前は、GRE トンネルがシャットダウンする理由が 3 つだけありました。

  • トンネルの宛先アドレスへのルートがない。

  • トンネルの発信元のアンカーとなるインターフェイスがダウンしている。

  • トンネルの宛先アドレスへのルートが、トンネル自体を通っている。

これらの 3 つのルール(ルートがない、インターフェイスがダウン、トンネルの宛先への不正なルート)は、トンネルのエンドポイントでのルータに限定された問題であり、中間のネットワークでの問題は対象としていません。 たとえば、これらのルールは、GRE トンネル パケットが正しく転送されているものの、トンネルの反対側に到達する前に失われるという場合は対象になりません。 これによって、他のインターフェイスを経由する PBR、またはフローティング スタティック ルートを使用する代替ルートを使用できる場合でも、GRE トンネルを通過するデータ パケットが「ブラック ホール化」されることになります。 GRE トンネル インターフェイスでキープアライブを使用する理由は、物理インターフェイスでキープアライブを使用する場合と同様に、この問題を解決するためです。

Cisco IOS(R) ソフトウェア リリース 12.2(8)T では、ポイントツーポイントの GRE トンネル インターフェイスにキープアライブを設定できます。 この変更によって、トンネル インターフェイスは、一定時間動作キープアライブが失敗した場合に、動的にシャットダウンされるようになります。 GRE トンネルのキープアライブの動作について、さらに詳しく理解するために、このセクションでは他の一般的なキープアライブ メカニズムについて説明します。

一般的なキープアライブ メカニズム

キープアライブ メッセージは、あるネットワーク デバイスから他のネットワーク デバイスに対して、その間にある回線が動作していることを知らせるために、物理回線または仮想回線を経由して送られます。 キープアライブの間隔とは、ネットワーク デバイスから送られる各キープアライブ メッセージ間の時間を指します。 キープアライブのリトライとは、インターフェイスをダウンと判断する前に、応答がなくてもデバイスがキープアライブ パケットを送信し続ける回数のことです。

イーサネットのキープアライブ

イーサネットのようなブロードキャスト メディアでは、キープアライブの仕組みはやや異なっています。 イーサネット上では、想定される隣接ルータが多数あるため、回線上のある特定の隣接ルータへのパスが使用可能かどうかを判定する目的ではキープアライブは設計されていません。 イーサネット回線自体に対して、ローカル システムが読み込み/書き込みアクセスができるかどうかをチェックするだけの設計になっています。 ルータは自身を発信元および宛先とする MAC アドレスと、0x9000 という特別なイーサネット タイプ コードを持つイーサネット パケットを生成します。 イーサネットのハードウェアはこのパケットをイーサネット回線上に送信し、そしてただちにこのパケットを受信します。 これによって、イーサネット アダプタ上の送受信ハードウェアと、回線の状態をチェックします。

gre-tunnel-keepalive-a.gif

HDLC のキープアライブ

よく知られている別のキープアライブ メカニズムは、HDLC 用のシリアル キープアライブです。 シリアル キープアライブは 2 台のルータ間で相互に送信され、確認応答されます。 各ルータは、連続番号を使用して、送信および確認応答されたキープアライブ パケットをトラッキングします。 この方法によって、リモート ルータは互いのキープアライブを監視し、送信したキープアライブが受信されたかどうかをトラッキングします。

シリアル キープアライブが動作する仕組みの説明として、ルータ 1 とルータ 2 がそれぞれ Serial0/0 と Serial2/0 を介して直接接続されているとします。 ルータ 1 の出力では、Serial 0/0 が意図的にシャットダウンされています。 これによって、ルータ 2 では 3 個のキープアライブが失われます。この障害によって、キープアライブが失われたときには、ルータ 2 が Serial2/0 をシャットダウンするしくみを説明しています。

これは、キープアライブがイネーブルになっているときの HDLC 接続に対して、debug serial interface コマンドを実行したときの出力例です。 ルータ 2 で myseq フィールドと mineseen フィールドの値の差が 3 を超えると、その回線がダウンし、インターフェイスがリセットされます。

ルータ 1

 17:21:09.685: Serial0/0: HDLC myseq 0, mineseen 0*, yourseen 1, line up 
 17:21:19.725: Serial0/0: HDLC myseq 1, mineseen 1*, yourseen 2, line up
 17:21:29.753: Serial0/0: HDLC myseq 2, mineseen 2*, yourseen 3, line up
 17:21:39.773: Serial0/0: HDLC myseq 3, mineseen 3*, yourseen 4, line up
 17:21:49.805: Serial0/0: HDLC myseq 4, mineseen 4*, yourseen 5, line up
 17:21:59.837: Serial0/0: HDLC myseq 5, mineseen 5*, yourseen 6, line up
 17:22:09.865: Serial0/0: HDLC myseq 6, mineseen 6*, yourseen 7, line up
 17:22:19.905: Serial0/0: HDLC myseq 7, mineseen 7*, yourseen 8, line up
 17:22:29.945: Serial0/0: HDLC myseq 8, mineseen 8*, yourseen 9, line up
 Router1 (config-if)#shut
 17:22:39.965: Serial0/0: HDLC myseq 9, mineseen 9*, yourseen 10, line up
 17:22:42.225: %LINK-5-CHANGED: Interface Serial0/0, changed state 
 to administratively down
 17:22:43.245: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, 
 changed state to down

ルータ 2

 *Sep 24 17:21:04.929: Serial2/0: HDLC myseq 0, mineseen 0, yourseen 0, line up 
 *Sep 24 17:21:14.941: Serial2/0: HDLC myseq 1, mineseen 1*, yourseen 1, line up 
 *Sep 24 17:21:24.961: Serial2/0: HDLC myseq 2, mineseen 2*, yourseen 2, line up 
 *Sep 24 17:21:34.981: Serial2/0: HDLC myseq 3, mineseen 3*, yourseen 3, line up 
 *Sep 24 17:21:45.001: Serial2/0: HDLC myseq 4, mineseen 4*, yourseen 4, line up 
 *Sep 24 17:21:55.021: Serial2/0: HDLC myseq 5, mineseen 5*, yourseen 5, line up 
 *Sep 24 17:22:05.041: Serial2/0: HDLC myseq 6, mineseen 6*, yourseen 6, line up 
 *Sep 24 17:22:15.061: Serial2/0: HDLC myseq 7, mineseen 7*, yourseen 7, line up 
 *Sep 24 17:22:25.081: Serial2/0: HDLC myseq 8, mineseen 8*, yourseen 8, line up 
 *Sep 24 17:22:35.101: Serial2/0: HDLC myseq 9, mineseen 9*, yourseen 9, line up 
 *Sep 24 17:22:45.113: Serial2/0: HDLC myseq 10, mineseen 10*, yourseen 10, line up 
 *Sep 24 17:22:55.133: Serial2/0: HDLC myseq 11, mineseen 10, yourseen 10, line up 
 *Sep 24 17:23:05.153: HD(0): Reset from 0x203758
 *Sep 24 17:23:05.153: HD(0): Asserting DTR 
 *Sep 24 17:23:05.153: HD(0): Asserting DTR and RTS 
 *Sep 24 17:23:05.153: Serial2/0: HDLC myseq 12, mineseen 10, yourseen 10, line up 
 *Sep 24 17:23:15.173: HD(0): Reset from 0x203758
 *Sep 24 17:23:15.173: HD(0): Asserting DTR 
 *Sep 24 17:23:15.173: HD(0): Asserting DTR and RTS 
 *Sep 24 17:23:15.173: Serial2/0: HDLC myseq 13, mineseen 10, yourseen 10, line down 
 17:23:16.201: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/0, 
 changed state to down
 Router2#
 17:23:25.193: Serial2/0: HDLC myseq 14, mineseen 10, yourseen 10, line down

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

GRE トンネルのキープアライブ メカニズムは、イーサネット インターフェイスやシリアル インターフェイスの場合とやや異なります。 このメカニズムでは、リモート ルータで GRE キープアライブがサポートされていない場合でも、片側のルータではリモート ルータへ送るキープアライブ パケットを送信でき、送られてくるパケットを受信できます。 GRE は IP 内で IP をトンネリングするパケット トンネリング メカニズムなので、別の GRE IP トンネル パケットの内部に GRE IP トンネル パケットを構築できます。 GRE キープアライブでは、送信側がキープアライブの応答パケットを、元のキープアライブ要求パケットの内部に事前に構築します。そのため、リモート エンドでは外側の GRE IP ヘッダーについて標準の GRE のカプセル化解除を行い、内側の IP GRE パケットを転送する必要があるだけです。 このメカニズムにより、キープアライブの応答はトンネル インターフェイスではなく物理インターフェイスに転送されます。 これは、GRE キープアライブ応答パケットは、トンネル インターフェイスでの出力機能(「トンネル保護」、QoS など)には左右されないことを意味しています。 GRE トンネル インターフェイスに着信 ACL が設定されている場合は、戻ってくる GRE トンネル キープアライブ パケットを許可する必要があります(access-list <number> permit gre host <tunnel-source> host <tunnel-destination>)。

GRE トンネル キープアライブのもう 1 つの特性は、各側のキープアライブ タイマーが独立しており、一致している必要がないことです。 トンネルの片側だけでキープアライブを設定することの問題点は、キープアライブ タイマーが切れたときに、キープアライブが設定されているルータだけがトンネル インターフェイスをダウンしたとマークすることです。 キープアライブが設定されていない反対側の GRE トンネルのインターフェイスは、トンネルの相手側がダウンした場合でもアップ状態のままです。 キープアライブが設定されていない側からトンネルへ送られたパケットに関して、トンネルがブラックホールになる可能性があります。 大規模なハブアンドスポーク GRE トンネル ネットワークでは、スポーク側だけに GRE キープアライブを設定し、ハブ側には設定しないことが適切と考えられます。 これは、多くの場合はスポーク側でハブに到達不可能なことを検出して、バックアップ パスに切り替えることの方が重要であるためです(ダイヤル バックアップなど)。

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

GRE トンネルとは、トランスポート プロトコル内で、パッセンジャ パケットをカプセル化する方法を提供する、Cisco ルータ上の論理インターフェイスです。これは、ポイントツーポイントのカプセル化スキームを実装するサービスを提供する設計になっているアーキテクチャです。

次のパケットは、IP トンネリングの概念を示しています。この場合、GRE がカプセル化プロトコルで、IP がトランスポート プロトコルです。 パッセンジャ プロトコルも IP です(Decnet、IPX、または Appletalk などのその他のプロトコルも可能です)。

gre-tunnel-keepalive-b.gif

  • IP はトランスポート プロトコルです。

  • GRE はカプセル化プロトコルです。

  • IP はパッセンジャ プロトコルです。

トンネル キープアライブ メカニズムが動作する仕組みをさらに理解するために、この例のトンネルのトポロジと設定について考えます。 ルータ A とルータ B の物理インターフェイスは、それぞれ S1 と S2 で、トンネル インターフェイスは Tu0 と呼ばれています。 GRE トンネルの 2 台のエンドポイント ルータ間に、IP バックボーン ネットワークがあります。

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

gre-tunnel-keepalive-1.gif

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

 Router# configure terminal
 Router(config)#interface tunnel0
 Router(config-if)#keepalive 5 4          
 
 !--- このコマンドの構文は keepalive [seconds [retries]] です。
 
 
 
 !--- キープアライブは 5 秒ごとに 4 回まで送信されます。
 !--- トンネルをシャットダウンする前に、キープアライブが途絶えている必要があります。
 !--- デフォルトの値は 10 秒間の間隔と、3 回のリトライです。
 
 

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

この表では、ルータ A とルータ B の両方で tunnel keepalive を設定する例を示しています。

ホスト名 Router-A

ホスト名 Router-B

 interface loopback 0
   ip address 129.9.9.9 255.255.255.255
 interface tunnel 0
   ip address 1.1.1.1 255.255.255.240
   tunnel source loopback0
   tunnel destination 128.8.8.8
   keepalive 5 4
 interface loopback 0
   ip address 128.8.8.8 255.255.255.255
 interface tunnel 0
   ip address 1.1.1.2 255.255.255.240
   tunnel source loopback0
   tunnel destination 129.9.9.9
   keepalive 5 4 

ルータ A のトンネル エンドポイントでキープアライブをイネーブルにすると、ルータでは各「時間」間隔で内部 IP ヘッダーと GRE ヘッダーが Protocol Type(PT; プロトコル タイプ)0 で作成されます。ルータは次に、このパケットをトンネル インターフェイスに送信します。この結果、外側の IP ヘッダーと PT = IP の GRE ヘッダーを持つパケットのカプセル化が行われます。 ルータ A はトンネルのキープアライブのカウンタを 1 増やします。 ここでは、遠端側のトンネル エンドポイントに到達する経路が 1 つあり、トンネルの回線プロトコルが他の理由でダウンしていることはなく、パケットがルータ B に到達すると仮定します。次に、パケットはトンネル 0 に対応付けられて、カプセル化解除され、ルータ A のトンネルの発信元 IP アドレスである宛先 IP アドレスに転送されます。ルータ A に到達すると、パケットはカプセル化解除され、PT のチェック結果が 0 になります。これはキープアライブ パケットであることを示します。 その後、トンネルのキープアライブ カウンタは 0 にリセットされ、パケットは廃棄されます。

ルータ B に到達できないとき、ルータ A は通常のトラフィックと同様にキープアライブ パケットの作成と送信を続けます。 キープアライブが戻ってこない場合、トンネルのキープアライブ カウンタが <retries> で指定された回数より小さいうちは回線プロトコルはアップ状態のままです。 この条件が真でなくなると、次にルータ A がルータ B にキープアライブを送信したときに、回線プロトコルはダウン状態になります。

アップ/ダウン状態では、トンネルはデータ トラフィックの転送や処理を行いません。 ただし、キープアライブ パケットの送信は継続します。 キープアライブの応答を受信すると、トンネルのエンドポイントが再度到達可能になったことが示唆されることになり、トンネルのキープアライブ カウンタは 0 にリセットされ、トンネルの回線プロトコルはアップ状態になります。 この図では、ルータ A がルータ B に GRE キープアライブを送信しているときに起きるシナリオ例を示しています。

gre-tunnel-keepalive-2.gif

この図では、ルータ B がルータ A に GRE キープアライブを送信しているときに起きるシナリオ例を示しています。

gre-tunnel-keepalive-3.gif

IPsec と GRE のキープアライブ

IPSec が備わった GRE トンネル

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

IPSec で GRE パケットを暗号化するには、2 種類の方法があります。 1 つは暗号マップを使う方法で、もう 1 つはトンネル保護を使う方法です。 いずれの方法も、GRE カプセル化を追加した後に IPSec 暗号化を実行するよう指定します。 暗号マップを使用する場合は、GRE トンネル パケットの発信物理インターフェイスに適用します。 トンネル保護を使用する場合は、GRE トンネル インターフェイスに設定します。 トンネル保護のコマンドは、Cisco IOS ソフトウェア リリース 12.2(13)T で導入されました。

この図では、暗号化されたパケットが GRE トンネル インターフェイス経由でルータに着信することを示しています。 ルータには物理インターフェイスに適用する暗号マップが備わっています。 パケットの復号化とカプセル化解除が行われると、クリアテキストで IP の宛先へ続いて送られます。

gre-tunnel-keepalive-4.gif

この図は、GRE トンネル インターフェイスでトンネル保護を設定したときに起きることを示しています。 パケットが暗号化されてトンネル インターフェイス経由でルータに着信し、復号化およびカプセル化解除された後、それぞれの宛先にクリアテキストで送られます。

gre-tunnel-keepalive-5.gif

暗号マップを使用する場合と、トンネル保護を使用する場合では、2 つの大きな違いがあります。

  • IPSec の暗号マップは物理インターフェイスに結び付けられており、パケットが物理インターフェイスから転送されるときにチェックされます。

    注:GRE トンネルでは、この時点ですでにパケットを GRE カプセル化しています。 

  • トンネル保護では暗号化機能が GRE トンネルに結び付けられており、パケットが GRE カプセル化された後、物理インターフェイスに送られる前にチェックされます。

IPSec と GRE を組み合わせたときのキープアライブに関する問題

GRE IPSec トンネルの片側で暗号マップが使用されていて(物理インターフェイスで設定)、もう一方の側ではトンネル保護が設定されていると、問題が発生します。 トンネル保護は、物理インターフェイスではなく、トンネル インターフェイスだけに設定されます。 このタイプの設定が、ハブ & スポーク型の設計で行われることがあります。 トンネル保護は、設定の規模を小さくするためにハブ ルータで設定し、スタティックな暗号マップは各スポークで使用します。 このシナリオでスポークに GRE トンネルのキープアライブを設定すると、キープアライブは失敗します。 これは、ハブから戻ってくるキープアライブが、暗号マップが設定されていない物理インターフェイスを通過するためです。 このため、戻ってくるキープアライブは暗号化されていません。受信するルータ(元々キープアライブ パケットを送ったルータ)では、このキープアライブ応答が IPSec で保護(暗号化)されていないため廃棄してしまいます。

次の図では、この問題を説明しています。

gre-tunnel-keepalive-6.gif

この問題は回避することができ、トンネル保護が設定されているルータに GRE キープアライブが設定されている場合には利点があることがあります。 次の図では、この点について説明しています。

gre-tunnel-keepalive-7.gif

ハブでダイナミック暗号マップが使用されていて、スポーク ルータでトンネル保護が使用されている場合は、スポーク ルータに GRE キープアライブを設定して、そのスポーク上でトンネル インターフェイスがシャットダウンした場合にバックアップ インターフェイスがハブにダイヤルするようにできます。

ハブの GRE トンネル インターフェイスがアップ状態であっても、ルーティングを行う隣接ルータとトンネルを通過するルートが失われた場合、代替ルートを確立できます。 スポークでは、トンネル インターフェイスがダウンしたことによって、ダイヤラ インターフェイスの起動とハブ(またはハブで別のルータ)へのコール バックが行われ、新しい接続が確立されます。

両方のルータで暗号マップが設定されていると、トンネルのキープアライブが両方向で行われ、片方または両方の方向で GRE トンネル インターフェイスがシャットダウンし、バックアップ接続の確立がトリガーされます。 これは最も柔軟性の高いオプションです。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 64565