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

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

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

概要

総称ルーティング カプセル化(GRE) キープアライブがであるもの、そしてはたらくどのようにこの資料に説明されています。

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

著者:Cisco TAC エンジニア、Atri Basu および Wen Zhang

GRE トンネル

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

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

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

GRE キープアライブが設定されていた前に介在するネットワークの問題を判別する、ルータのローカル問題および方法を判別しない方法だけありました。 たとえば、GRE がトンネル伝送するケースはパケット正常にそれらがトンネルのもう一方の端に達する前に転送されますが、失われます。 使用する代替ルートが別のインターフェイスによる PBR かフローティング スタティック ルート 利用可能であるかもしれませんのにそのようなシナリオにより GREトンネルを「穴があく」黒であることを通過するデータパケットを引き起こします。 GRE トンネルのインターフェイスのキープアライブは、キープアライブが物理インターフェイスで使用されるのと同様にこの問題を解決するために使用されます。

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

GREトンネル キープアライブ メカニズムはリモートルータが GRE キープアライブをサポートしなくてもリモートルータに出入してキープアライブ パケットを送信し、受信する一方のための機能を与えること PPP キープアライブに類似したです。 GRE は IP 内で IP をトンネリングするパケット トンネリング メカニズムなので、別の GRE IP トンネル パケットの内部に GRE IP トンネル パケットを構築できます。 GRE キープアライブ、送信側 prebuilds に関してはオリジナル キープアライブ 要求パケットの中のキープアライブ応答 パケット リモート エンド 外側 GRE IP ヘッダーの標準 GRE 非カプセル化をし、次に送信側に内側の IP GRE パケットを戻す必要だけ。 次のパケットは、IP トンネリングの概念を示しています。この場合、GRE がカプセル化プロトコルで、IP がトランスポート プロトコルです。 パッセンジャープロトコルはまた(それが DECNet、Internetwork Packet Exchange (IPX)、または AppleTalk のような別のプロトコルである場合もあるが) IP です。

正常なパケット:

IP ヘッダー

TCP ヘッダ

Telnet

トンネル伝送されたパケット:

GRE IP ヘッダー

GRE

IP ヘッダー

TCP ヘッダ

Telnet

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

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

GRE キープアライブ:

GRE IP ヘッダー

GRE

IP ヘッダー

GRE

ソース B宛先 A PT=0
A のソースをたどって下さい宛先 B PT=IP

このメカニズムにより、キープアライブの応答はトンネル インターフェイスではなく物理インターフェイスに転送されます。 これは GRE キープアライブ応答 パケットがトンネルインターフェイスのあらゆる出力 機能から、「トンネル 保護…」、QoS、バーチャルルーティングおよびフォワーディング(VRF)のような影響を受けないことを、等意味します。

: GREトンネル インターフェイスの受信 Access Control List (ACL)が設定される場合、許可する反対デバイス送信が必要がある GREトンネル キープアライブ パケット。 そうでない場合、他方のデバイスの GRE トンネルはダウンします。 (access-list <number> permit gre host <tunnel-source> host <tunnel-destination>)

GREトンネル キープアライブのもう一つのアトリビュートは PPP キープアライブに類似した両方の側でキープアライブ タイマーが独立 して、一致する必要がないことです。

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

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

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

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

詳細については他の keepaliveの形式がどのようにに関するはたらくか、Cisco IOS のキープアライブ メカニズムの外観を参照して下さい。

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

この出力は、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 はこれらのステップを実行します:

  1. 内部 IP ヘッダーを 5 秒毎に組み立てます:

    • ソースはローカルとして 192.168.1.2 であるトンネル宛先 設定 されます、
    • 宛先は 192.168.1.1 であるローカル トンネル ソースとして設定 されます、


    そして GRE ヘッダは 0 のプロトコル タイプ(PT)と付加されます

    ルータ A によって生成されるが、送信 されない パケット:

    IP ヘッダー

    GRE

    Source:192.168.1.2Destination:192.168.1.1 PT=0


  2. 外 IP ヘッダーのパケットのカプセル化という結果に終るトンネルインターフェイスからそのパケットを送信 します、:

    • ソースはローカルとして 192.168.1.1 であるトンネル ソース 設定 されます、
    • 宛先は 192.168.1.2 であるローカル トンネル宛先として設定 されます、


    そして GRE ヘッダはと PT = IP 付加されます。

    パケットはルータ A からルータから B を送信 しました:

    GRE IP ヘッダー

    GRE

    IP ヘッダー

    GRE

    Source:192.168.1.2Destination:192.168.1.1 PT=0
    出典: 192.168.1.1Destination: 192.168.1.2 PT=IP


  3. 1 つによってトンネル キープアライブ カウンターを増分します。

  4. 遠端トンネルのエンドポイントに到達する方法があり、トンネルの回線プロトコルが何らかの理由によりダウンしていない場合には、パケットはルータ B に到達します。 ルータ A.のトンネル ソース IP アドレスであるそれはトンネル 0 とそして一致し、カプセル化を解除されるようになり、宛先IP に転送されます。

    送信 された ルータ B からルータから A:

    IP ヘッダー

    GRE

    Source:192.168.1.2Destination:192.168.1.1 PT=0


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

ルータ B が到達不能である場合、ルータ A はキープアライブ パケット、また正常なトラフィックを組み立て、送信 し続けます。 キープアライブがもどって来ない場合、トンネル行プロトコルはトンネル キープアライブ カウンターがこの場合 4 である再試行の数より小さい限りアップ状態に留まります。 この条件が true でない場合、次回ルータ A がルータ B にキープアライブを送信しようとするときに回線プロトコルがダウンします。

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

操作のキープアライブを見るために、デバッグ トンネルをイネーブルに設定し、トンネル キープアライブをデバッグして下さい

ルータ 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 は rx 到達可能を経てユニキャスト ソースを確認します)動作する時、パケットはリターンパケットを転送するためにルータが使用するインターフェイスで受信する必要があります。 厳密なモード ユニキャスト RPF が GRE キープアライブ パケットを受信するルータのトンネルインターフェイスで有効に なれば、キープアライブ パケットはトンネル 非カプセル化の後で 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 

その結果、トンネル キープアライブの発信側は抜けていたキープアライブ リターンパケットによるトンネルをダウンさせます。 つまりユニキャスト RPF は GREトンネル キープアライブがはたらくことができるように設定されてはなりません。 ユニキャスト RPF に関する詳細については、知識 Unicast Reverse Path Forwarding を参照して下さい。

IPsec および GRE キープアライブ

IPsec の GREトンネル

GREトンネルは時々 IPsec と IPsec が IP Multicast パケットをサポートしないので結合されます。 このような理由で、ダイナミック ルーティング プロトコルは IPSec VPN ネットワークにうまく働くことができません。 GRE トンネルでは IP マルチキャストがサポートされているので、GRE トンネル上ではダイナミック ルーティング プロトコルが動作します。 結果が IPsec によって暗号化することができる GRE IPユニキャスト パケット。

IPsec が GRE パケットを暗号化できること 2 つのさまざまな方法があります:

  • 1 つの方法はクリプト マップの使用とあります。 クリプト マップは使用されるとき、GREトンネルパケットのための送信 物理インターフェイスに加えられます。 この場合、ステップのシーケンスは次の通りです:

    1. 暗号化されたパケットは物理インターフェイスに到着します。
    2. パケットはトンネルインターフェイスに復号化され、転送されます。
    3. パケットはクリアテキストの IP目的地にカプセル化を解除され、次に転送されます。


  • 他の方法はトンネル 保護を使用することです。 トンネル保護を使用する場合は、GRE トンネル インターフェイスに設定します。 tunnel protection コマンドは、Cisco IOS ソフトウェア リリース 12.2(13)T で導入されました。 この場合、ステップのシーケンスは次の通りです:

    1. 暗号化されたパケットは phsyical インターフェイスに到着します。
    2. パケットはトンネルインターフェイスに転送されます。
    3. パケットはクリアテキストの IP目的地に復号化され、カプセル化を解除され、次に転送されます。

メソッドは両方とも IPSec暗号化が GRE カプセル化の付加の後で実行されたこと規定 します。 クリプト マップを使用するとき、そしてトンネル 保護を使用するとき 2 つの主な違いが間にあります:

  • IPsec クリプト マップは物理インターフェイスにパケットが物理インターフェイスを転送されると同時に接続し、チェックされます。

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

IPsec および GRE を結合する場合のキープアライブにおける問題

GREトンネルに暗号化を追加する 2 つの方法を与えられて暗号化された GREトンネルを設定する 3 つの個別の方法があります:

  1. ピア B に物理インターフェイスで設定されるクリプト マップがある間、持っていますトンネルインターフェイスで設定されるトンネル 保護を A はピアリングします。
  2. ピア B にトンネルインターフェイスで設定されるトンネル 保護がある間、持っています物理インターフェイスで設定されるクリプト マップを A はピアリングします。
  3. 同位に両方ともトンネルインターフェイスで設定されるトンネル 保護があります。

シナリオ 1 および 2 に説明がある設定は頻繁にハブ アンド スポーク型設計でされます。 トンネル保護は、設定の規模を小さくするためにハブ ルータで設定し、スタティックな暗号マップは各スポークで使用します。

トンネルモードが暗号化のために使用されるところでピア B(spoke)で有効に なる GRE キープアライブのこれらのシナリオのそれぞれを考慮すれば。

シナリオ 1

次の手順を実行してください。

-----------

  • 使用トンネル 保護はピアリングします。
  • ピア B はクリプト マップを使用します。
  • キープアライブはピア B.で有効に なります。
  • IPSec暗号化はトンネルモードで行われます。

このシナリオでは、GRE キープアライブがピア B で設定されるので、キープアライブが生成されるときシーケンス イベントは次の通りです:

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

    パケットはピア B からピアリングするために A 送信 しました:

    IP ヘッダー

    ESP ヘッダ

    GRE IP ヘッダー

    GRE ヘッダ

    IP ヘッダー

    GRE

    SourceADestinationBPT=0

    ESP トレーラ

    SourceBDestinationASourceBDestinationAPT=IP


  2. ピア A で、GRE キープアライブは復号化しました受け取られます:

    GRE IP ヘッダー

    GRE

    IP ヘッダー

    GRE

    SourceADestinationB PT=0
    SourceBDestinationA PT=IP


    カプセル化を解除される:

    IP ヘッダー

    GRE

    SourceADestinationB PT=0


    それから内側の GRE キープアライブ応答 パケットはピア B.である宛先アドレスに基づいてルーティングされます。 それはピア A で、パケットすぐにルーティングされます物理インターフェイス キャンセルしますピアリングする B.意味します。 ピア A 使用がトンネルインターフェイスの保護をトンネル伝送するので、キープアライブ パケットは暗号化されません。

    従って、パケットはピア A からピアリングするために B 送信 しました:

    IP ヘッダー

    GRE

    SourceADestinationB PT=0


    : キープアライブは暗号化されません。



  3. ピア B は今物理インターフェイスで暗号化されないが、物理インターフェイスで設定されるクリプト マップが理由で暗号化されたパケットを期待し、そう廃棄します GRE キープアライブ応答を受け取ります。

従って、ピア A が keepailves および送信元ルータに応答するのに、ピア B は応答を受け取ります、決してそれらを処理しないし、ダウン の 状態に結局トンネルインターフェイスの行プロトコルを変更します。

結果

----------

ピア B で有効に なる キープアライブによりピア B のトンネルステートは up/down に変更します。

シナリオ2

次の手順を実行してください。

-----------

  • 使用クリプト マップはピアリングします。
  • ピア B 使用は保護をトンネル伝送します。
  • キープアライブはピア B.で有効に なります。
  • IPSec暗号化はトンネルモードで行われます。

このシナリオでは、GRE キープアライブがピア B で onfigured ので、キープアライブが生成されるときシーケンス イベントは次の通りです:

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

    パケットはピア B からピアリングするために A 送信 しました:

    IP ヘッダー

    ESP ヘッダ

    GRE IP ヘッダー

    GRE ヘッダ

    IP ヘッダー

    GRE

    SourceADestinationBPT=0

    ESP トレーラ

    SourceBDestinationASourceBDestinationAPT=IP


  2. ピア A で、GRE キープアライブは復号化しました受け取られます:

    GRE IP ヘッダー

    GRE

    IP ヘッダー

    GRE

    SourceADestinationB PT=0
    SourceBDestinationA PT=IP


    カプセル化を解除される:

    IP ヘッダー

    GRE

    SourceADestinationB PT=0


    それから内側の GRE キープアライブ応答 パケットはピア B.である宛先アドレスに基づいてルーティングされます。 それはピア A で、パケットすぐにルーティングされます物理インターフェイス キャンセルしますピアリングする B.意味します。 ピア A が物理インターフェイスのクリプト マップを使用するので、それを転送する前に最初にこのパケットを暗号化します。

    従って、パケットはピア A からピアリングするために B 送信 しました:

    IP ヘッダー

    ESP ヘッダ

    IP ヘッダー

    GRE

    SourceADestinationBPT=0

    ESP トレーラ

    SourceBDestinationA


    : キープアライブ応答は暗号化されます。



  3. ピア B は今宛先が復号化されるトンネルインターフェイスに転送される暗号化された GRE キープアライブ応答を受け取ります:

    IP ヘッダー

    GRE

    SourceADestinationB PT=0


    Protocal 型が 0 に設定 されるので、これがキープアライブ応答で、それをそのように処理することをピア B は確認します。

結果

----------

ピア B で有効に なる キープアライブは正常にトンネルステートがトンネル宛先の availabilty に基づいている必要があるものを判別します。

シナリオ 3

次の手順を実行してください。

-----------

  • 両方の同位 使用 トンネル 保護。
  • キープアライブはピア B.で有効に なります。
  • IPSec暗号化はトンネルモードで行われます。

このシナリオはピア A が暗号化されたキープアライブを受け取るときそれのシナリオ1 に類似した、それ復号化し、カプセル化を解除しますそれをです。 ただし、応答は転送されるときピア A 使用がトンネルインターフェイスの保護をトンネル伝送するので、暗号化されませんキャンセルします。 従って、ピア B は非暗号化キープアライブ応答を廃棄し、処理しません。

結果

----------

ピア B で有効に なる キープアライブによりピア B のトンネルステートは up/down に変更します。

回避策

GRE パケットが暗号化する必要があるところにそのような状況で 3 つの可能 な 解決策があります:

  1. クリプト マップを A ピアリングし、トンネル伝送しピア B の保護を、有効に します ピア B.のキープアライブを使用して下さい。

    この種 の 設定がハブ・アンド・スポーク セットアップで大抵使用されるおよびそのようなセットアップでそれがハブの到達可能性に気づくためにのためにより重要であるので話したのでソリューションはおよびスポーク(B)ピア トンネル伝送するためおよびスポークの保護をの GRE キープアライブを有効に するためのダイナミック暗号マップをハブ(A)ピア使用することです。 ハブの GREトンネル インターフェイス アップのままになっているがこうすればは、ルーティング隣接関係およびトンネルによるルーティングは失われ、代替ルートは確立することができます。 スポークでは、トンネル インターフェイスがダウンしたことによって、ダイヤラ インターフェイスの起動とハブ(またはハブで別のルータ)へのコール バックが行われ、新しい接続が確立されます。

  2. ピア到達可能性を判別するために GRE キープアライブ以外何かを使用して下さい

    ルータが両方ともトンネル 保護で設定される場合、GREトンネル keeaplives はどちらの方向でも使用することができません。 この場合、唯一のオプションはピアが到達可能であるかどうか検出するためにルーティング プロトコルか他のメカニズムを、サービス保証エージェントのような使用することです。

  3. クリプト マップを A ピアリングし、B.ピアリングします使用して下さい。

    ルータが両方ともクリプト マップで設定される場合、トンネル キープアライブは両方向で通過、GREトンネル インターフェイスはどちらかまたは両方向でシャットダウンし、作られるべきバックアップ接続を起動できます。 これは最も柔軟性の高いオプションです。

関連情報



Document ID: 118370