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

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

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2005 年 8 月 10 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

このドキュメントでは、GRE キープアライブとその仕組みについて説明します。 GRE トンネルのキープアライブは tunnel protection ipsec profile コマンドとともにはサポートされません。 このドキュメントでは、この問題について説明します。

注:  GRE キープアライブは、どのような状況であっても IPSec トンネルの保護とともにはサポートされません

前提条件

要件

このドキュメントに関する特別な要件はありません。

使用するコンポーネント

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

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

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

GRE トンネル

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

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

GRE キープアライブを実行する前に、GRE トンネルをシャット ダウンする次の 3 つの原因がありました:

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

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

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

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

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

共通のキープアライブ メカニズム

キープアライブ メッセージは、物理回線または仮想回線で 1 台のネットワーク デバイスによって送信され、他のネットワーク デバイスとの回線も引き続き機能することを他のネットワーク デバイスに通知します。 キープアライブの間隔とは、ネットワーク デバイスから送られる各キープアライブ メッセージ間の時間を指します。 キープアライブのリトライとは、インターフェイスをダウンと判断する前に、応答がなくてもデバイスがキープアライブ パケットを送信し続ける回数のことです。

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

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-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 トンネルのインターフェイスでインバウンド インターフェイスが設定されると、他方のデバイスが送信する GRE トンネルのキープアライブ パケットが許可される必要があります。 そうでない場合、他方のデバイスの GRE トンネルはダウンします。 (access-list <number> permit gre host <tunnel-source> host <tunnel-destination>)

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

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

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

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-b.gif

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

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

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

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

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-1.gif

この出力は、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.

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

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

Hostname Router-A Hostname 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 のトンネル エンドポイントでキープアライブを有効にすると、<period> 間隔のルータは 0 のプロトコル タイプ(PT)を持つ内部の IP ヘッダーと GRE ヘッダーを作成します。 次に、そのパケットをトンネルのインターフェイスから送信します。これにより、パケットは PT = IP を持つ外側の IP ヘッダーと GRE ヘッダーを含むパケットにカプセル化されます。 ルータ A はトンネルのキープアライブのカウンタを 1 増やします。 遠端トンネルのエンドポイントに到達する方法があり、トンネルの回線プロトコルが何らかの理由によりダウンしていない場合には、パケットはルータ B に到達します。 次にトンネル 0 と照合されカプセル化解除されると、ルータ A のトンネル送信元 IP アドレスである宛先 IP に送信されます。ルータ A での到達時に、パケットはカプセル化解除され、PT のチェック結果は 0 となります。 このことは、これがキープアライブ パケットであることを示します。 その後、トンネルのキープアライブ カウンタは 0 にリセットされ、パケットは廃棄されます。

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

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

注: キープアライブのドロップが原因でトンネルがアップ状態またはダウン状態の場合、debug tunnel および debug tunnel keepalive をイネーブルにします。

次の表に、ルータ A の debug tunnel keepalive の出力例を示します:

Hostname Router-A
debug tunnel keepalive
        Tunnel keepalive debugging is on
        *Mar  1 01:19:16.019: Tunnel0: sending keepalive, 128.8.8.8->129.9.9.9 (len=24 ttl=0), counter=15
        *Mar  1 01:19:21.019: Tunnel0: sending keepalive, 128.8.8.8->129.9.9.9 (len=24 ttl=0), counter=16
        *Mar  1 01:19:26.019: Tunnel0: sending keepalive, 128.8.8.8->129.9.9.9 (len=24 ttl=0), counter=17

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-2.gif

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-3.gif

IPSec と GRE キープアライブ

IPSec を使用した GRE トンネル

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

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

注: GRE キープアライブはトンネルの保護と互換性がありません。

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-4.gif

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-5.gif

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

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

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

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

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

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

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-9.gif

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-10.gif

ハブがダイナミック暗号マップを使用し、スポーク ルータがトンネル保護を使用すると、スポーク ルータに GRE キープアライブを設定できるため、トンネルのインターフェイスがスポークでシャット ダウンした場合に、ハブにコールを発信するバックアップ インターフェイスをトリガーできます。

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

両方のルータが暗号マップを設定している場合、トンネルのキープアライブは両方向で処理され、GRE トンネルのインターフェイスは単一方向または両方向でシャット ダウンして、バックアップ接続を開始します。 これは最も柔軟性の高いオプションです。

両方のルータにトンネル保護を設定している場合、GRE トンネルのキープアライブはどちらの方向にも使用できません。 この場合、ルーティング プロトコルやその他のメカニズム(サービス保証エージェントなど)を使用して、トンネルが動作していないことを検出する必要があります。

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

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


関連情報


Document ID: 64565