この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、総称ルーティングカプセル化(GRE)キープアライブとその仕組みについて説明します。
GRE トンネルとは、トランスポート プロトコル内で、パッセンジャ パケットをカプセル化する方法を提供する、Cisco ルータ上の論理インターフェイスです。これは、ポイントツーポイント カプセル化スキームを実装するサービスを提供する設計になっているアーキテクチャです。
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 です(Decnet、Internetwork Packet Exchange(IPX)、Appletalk などの別のプロトコルにもできます)。
ノーマル パケット:
IP ヘッダー |
TCP ヘッダー |
Telnet |
トンネリングされたパケット:
GRE IP ヘッダー |
GRE |
|
ルータ A から送信され、ルータ B を宛先とするキープアライブ パケットの例を示します。ルータ B がルータ A に戻すキープアライブの応答は内部の IP ヘッダー内にすでにあります。ルータ B は単にキープアライブ パケットをカプセル化解除して、それを物理インターフェイス(S2)に送り返すだけです。その他の GRE IP データ パケットと同様に GRE キープアライブ パケットを処理します。
GRE キープアライブ:
GRE IP ヘッダー |
GRE |
|
|||||||
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キープアライブをハブ側ではなくスポーク側でのみ設定するのが適切な場合があります。これは、多くの場合はスポーク側でハブに到達不可能なことを検出して、バックアップ パスに切り替えることの方が重要であるためです(ダイヤル バックアップなど)。
Cisco IOS® ソフトウェア リリース 12.2(8)T では、ポイントツーポイントの GRE トンネル インターフェイスにキープアライブを設定できます。この変更によって、トンネル インターフェイスは、一定期間キープアライブが失敗した場合に、動的にシャットダウンします。
その他の形式のキープアライブの仕組みの詳細は、「Cisco IOS でのキープアライブ メカニズムの概要」を参照してください。
注:GREトンネルのキープアライブは、ポイントツーポイントGREトンネルでのみサポートされます。トンネルのキープアライブは、マルチポイント GRE(mGRE)トンネルでも設定できますが、効果はありません。
注:一般に、VRFがトンネルインターフェイスとfVRF('tunnel vrf ...')およびiVRF ('ip vrf forwarding ...' on tunnel interface)が一致しません。これは、キープアライブを要求者に「反映」させるトンネル エンドポイントでは重要です。キープアライブ要求が受信されるとき、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 で次のステップを実行します。
IP ヘッダー |
GRE |
|
Source:192.168.1.2 | Destination:192.168.1.1 | PT=0 |
GRE IP ヘッダー |
GRE |
|
|||||||
Source:192.168.1.1 | Destination:192.168.1.2 | PT=IP |
IP ヘッダー |
GRE |
|
Source:192.168.1.2 | Destination:192.168.1.1 | PT=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
ユニキャスト 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 は IP マルチキャスト パケットをサポートしないため、GRE トンネルは IPsec と組み合わせることがあります。このため、ダイナミック ルーティング プロトコルは IPsec VPN ネットワークを介して正常に実行できません。GRE トンネルでは IP マルチキャストがサポートされているので、GRE トンネル上ではダイナミック ルーティング プロトコルが動作します。その結果の GRE IP ユニキャスト パケットは、IPsec で暗号化できます。
IPsec が GRE パケットを暗号化できる方法は 2 つあります。
いずれの方法も、IPsec 暗号化が GRE カプセル化の追加後に実行されることを指定します。暗号マップを使用する場合とトンネル保護を使用する場合とには、2 つの主な違いがあります。
GRE トンネルに暗号化を追加する 2 つの方法を考えると、暗号化された GRE トンネルをセットアップする方法は 3 つあります。
シナリオ 1 と 2 で説明する構成は、多くの場合、ハブアンドスポーク設計で行われます。トンネル保護は、設定の規模を小さくするためにハブ ルータで設定し、スタティックな暗号マップは各スポークで使用します。
ピア B(スポーク)で GRE キープアライブを有効にするこれらの各シナリオを検討し、どこで暗号化にトンネル モードを使用するのかを考えてみましょう。
設定:
-----------
このシナリオでは、GRE キープアライブがピア B で設定されるため、キープアライブが生成されるときの一連のイベントは次のようになります。
IP ヘッダー |
ESP ヘッダー |
GRE IP ヘッダー |
GRE ヘッダー |
|
ESP トレーラ |
|||||||
送信元B | 宛先A | 送信元B | 宛先A | PT=IP |
GRE IP ヘッダー |
GRE |
|
|||||||
送信元B | 宛先A | PT=IP |
IP ヘッダー |
GRE |
|
送信元A | 宛先B | PT=0 |
IP ヘッダー |
GRE |
|
送信元A | 宛先B | PT=0 |
注:キープアライブは暗号化されません。
したがって、ピアAがキープアライブに応答し、ルータPeer Bがその応答を受信しても、ピアBは応答を処理せず、最終的にはトンネルインターフェイスの回線プロトコルをダウン状態に変更します。
Result:
----------
ピア B でキープアライブが有効になっていると、ピア B のトンネルの状態はアップ/ダウンに変更されます。
設定:
-----------
このシナリオでは、GRE キープアライブがピア B で設定されるため、キープアライブが生成されるときの一連のイベントは次のようになります。
IP ヘッダー |
ESP ヘッダー |
GRE IP ヘッダー |
GRE ヘッダー |
|
ESP トレーラ |
|||||
送信元B | 宛先A | 送信元B | 宛先A | PT=IP |
GRE IP ヘッダー |
GRE |
|
|||||||
送信元B | 宛先A | PT=IP |
IP ヘッダー |
GRE |
|
送信元A | 宛先B | PT=0 |
IP ヘッダー |
ESP ヘッダー |
|
ESP トレーラ |
|||||||
送信元B | 宛先A |
注:キープアライブ応答は暗号化されます。
IP ヘッダー |
GRE |
|
送信元A | 宛先B | PT=0 |
Result:
----------
ピアBでイネーブルにされたキープアライブは、トンネルの宛先のアベイラビリティに基づいて、どのトンネル状態が可能かを正常に判断します。
設定:
-----------
このシナリオは、ピア A が暗号化されたキープアライブを受信し、復号してカプセル化解除する点でシナリオ 1 と似ています。ただし、応答が転送される場合、ピア A がトンネル インターフェイスでトンネル保護を使用するため、暗号化されません。したがって、ピア B は暗号化されていないキープアライブ応答を破棄し、処理しません。
Result:
----------
ピア B でキープアライブが有効になっていると、ピア B のトンネルの状態はアップ/ダウンに変更されます。
GRE パケットを暗号化する必要があるこのような状況では、利用可能な解決策は 3 つあります。
改定 | 発行日 | コメント |
---|---|---|
2.0 |
19-Dec-2022 |
代替テキストが追加されました。概要、用語、スタイルの要件、および書式を更新。 |
1.0 |
31-Oct-2014 |
初版 |