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

ダウンロードオプション

PDF (449.0 KB)
Adobe Reader を使ってさまざまなデバイスで表示

Updated: 2026 年 6 月 15 日

Document ID:118370

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポートコンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

内容

はじめに

GRE トンネル

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

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

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

IPsec と GRE キープアライブ

IPsec を使用する GRE トンネル

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

シナリオ 1

シナリオ 2

シナリオ 3

回避策

はじめに

このドキュメントでは、総称ルーティングカプセル化(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 ヘッダー

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
Source B	Destination A	PT=0

Source A

Destination B

PT=IP

このメカニズムにより、キープアライブ応答がトンネルインターフェイスではなく物理インターフェイスから転送されるようになります。つまり、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.

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

Tunnel Topology and Configuration for Keepalive Mechanism

ルータ 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 に送信されたパケット：

GRE IP ヘッダー

GRE

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

Source:192.168.1.1

Destination:192.168.1.2

PT=IP

トンネルキープアライブカウンタを 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 つあります。

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

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

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

シナリオ 1

設定：

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

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

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

ピア B からピア A に送信されたパケット：

IP ヘッダー

ESP ヘッダー

GRE IP ヘッダー

GRE ヘッダー

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

ESP トレーラ

ソースB

宛先A

ソースB

宛先A

PT=IP

ピア 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

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

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

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

結果：

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

シナリオ 2

設定：

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

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

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

ピア B からピア A に送信されたパケット：

IP ヘッダー

ESP ヘッダー

GRE IP ヘッダー

GRE ヘッダー

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

ESP トレーラ

ソースB

宛先A

ソースB

宛先A

PT=IP

ピア 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

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

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

IP ヘッダー

GRE

ソースA 宛先B PT=0

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

結果：

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

シナリオ 3

設定：

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

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

結果：

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

回避策

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

ピア A で暗号マップ、ピア B でトンネル保護を使用し、ピア B でキープアライブを有効にします。

このタイプの設定は主にハブアンドスポークのセットアップで使用され、このようなセットアップではスポークがハブの到達可能性を認識することが重要であるため、解決策はハブ（ピアA）でダイナミック暗号マップを使用し、スポーク（ピアB）でトンネル保護を使用し、スポークでGREキープアライブを有効にすることです。この方法では、ハブの GRE トンネルインターフェイスはアップ状態のままですが、トンネル経由のルーティングネイバーとルートは失われ、代替ルートを確立できます。スポークでは、トンネルインターフェイスがダウンしたことによって、ダイヤラインターフェイスの起動とハブ（またはハブで別のルータ）へのコールバックが行われ、新しい接続が確立されます。
ピアの到達可能性を判断するために GRE キープアライブ以外の方法を使用します。

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

両方のルータで暗号マップが設定されている場合、トンネルキープアライブは両方向で使用でき、GRE トンネルインターフェイスはいずれかまたは両方向でシャットダウンでき、バックアップ接続の作成をトリガーできます。これは最も柔軟性の高いオプションです。

改定	発行日	コメント
4.0	15-Jun-2026	再認定
3.0	18-Apr-2025	書式設定を更新し、文法とスペルの誤りを修正しました。
2.0	19-Dec-2022	代替テキストが追加されました。概要、ゲルンド、スタイルの要件、およびフォーマットを更新。
1.0	31-Oct-2014	初版

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

ダウンロードオプション

偏向のない言語

翻訳について

内容

はじめに

GRE トンネル

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

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

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

IPsec と GRE キープアライブ

IPsec を使用する GRE トンネル

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

シナリオ 1

シナリオ 2

シナリオ 3

回避策

関連情報

更新履歴

シスコエンジニア提供

このドキュメントは役に立ちましたか?

シスコに問い合わせ

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

ダウンロード オプション

偏向のない言語

翻訳について

内容

はじめに

GRE トンネル

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

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

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

IPsec と GRE キープアライブ

IPsec を使用する GRE トンネル

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

シナリオ 1

シナリオ 2

シナリオ 3

回避策

関連情報

更新履歴

シスコ エンジニア提供

このドキュメントは役に立ちましたか?

シスコに問い合わせ

ダウンロードオプション

シスコエンジニア提供