トップ > 助け合いフォーラム > CCNA/CCNP関連 > 最強WEB問題集CCNP TSHOOT (前の質問|次の質問)

GRE up/upで通信が失敗する場合の原因

フォーラムは新サイトへ移行しました。
このフォーラムではゲスト投稿が禁止されています

ツリー構造順で表示投稿の新しいものから

GRE up/upで通信が失敗する場合の原因

msg# 1

前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 .2 | 投稿日時 2019-5-11 1:59

rokubusyuu 一人前

投稿数: 27

問題ID:33492です。

答えの「トンネルの宛先に到達する物理的な回線が無い」の意味が分かりません。
解説では
「トンネルにより離れたルータを仮想的に接続しますが、実際は物理的なネットワークを通じてパケットを転送していくので、トンネルを設定していない状態でも通信できている必要があります。」との記載です。

たとえば、GREを構成し宛先がloop backの場合、そのloop backにも
ipリーチャビリティが無いと通信ができないという解説になるのでしょうか?
上記の解説なら納得が行きますが。

Re: GRE up/upで通信が失敗する場合の原因

msg# 1.1

前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2019-5-11 9:36

arashi1977

居住地: 広島投稿数: 1715

例えばあるルータで以下の設定を行っているとして

interface Loopback0
 ip address 1.1.1.1 255.255.255.255
interface Tunnel0
 ip address 10.1.3.1 255.255.255.0
 tunnel source Loopback0
 tunnel destination 172.16.23.3
interface FastEthernet0/0
 ip address 172.16.12.1 255.255.255.0
 no shutdown
ip route 172.16.23.0 255.255.255.0 172.16.12.2

そのルータが以下のように
- ルーティングテーブルにはtunnel destinationで指定したアドレス向けの経路情報がある
- しかし（tunnel destinationそのものではなく）宛先ネットワークへのネクストホップへの到達性はない
状態であってもTunnelインターフェースはup/upになります。

R1#show ip route | begin Gateway
Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback0
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.1.3.0/24 is directly connected, Tunnel0
L        10.1.3.1/32 is directly connected, Tunnel0
      172.16.12.0/24 is variably subnetted, 2 subnets, 2 masks
C        172.16.12.0/24 is directly connected, FastEthernet0/0
L        172.16.12.1/32 is directly connected, FastEthernet0/0
S     172.16.23.0/24 [1/0] via 172.16.12.2
R1#ping 172.16.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.12.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            172.16.12.1    YES manual up                    up
FastEthernet0/1            unassigned      YES unset  administratively down down
GigabitEthernet1/0         unassigned      YES unset  administratively down down
Serial2/0                  unassigned      YES unset  administratively down down
Serial2/1                  unassigned      YES unset  administratively down down
Serial2/2                  unassigned      YES unset  administratively down down
Serial2/3                  unassigned      YES unset  administratively down down
POS3/0                     unassigned      YES unset  administratively down down
Loopback0                  1.1.1.1         YES manual up                    up
Tunnel0                    10.1.3.1      YES manual up                    up ←ここ

Tunnelインターフェースは仮想的なインターフェースで「何らかのカプセル化を行う」ためのものです。上記の設定であればGREでカプセル化することになります。
カプセル化するときには
- カプセル化パケットの生成元情報
- カプセル化パケットの宛先アドレス
があれば処理可能なので、この条件を満たす場合Tunnelインターフェースはup/upになります。逆に、いずれかがNGであればカプセル化に必要な情報が揃わないのでup/downになります。
参考にもありますが
引用：

■宛先（tunnel destination）設定誤り
tunnel destinationコマンドではGREパケットを受信する相手側のアドレスもしくはそのアドレスをもつホスト名を指定しますが、以下の状態ではtunnel destinationに無効な値が設定されていると判断されるため、トンネルインターフェースの状態がup/downになります。

・指定したアドレスへの経路情報がルーティングテーブルに存在しない（疎通不可でもルーティングテーブルに存在していればよい）
・指定したホスト名が名前解決できない（この場合、名前解決失敗時にコマンドがエラーになるため、tunnel destination未設定となる）

「tunnel destination宛の経路情報がルーティングテーブルにあるかどうか」が必要なだけで、リーチャビリティは関係ないんですね。なのでtunnel destinationのアドレスに到達できなくても、ルーティングテーブル上到達可能と判断できる状態であればup/upとなる（が、カプセル化パケットが相手まで届かず結果としてTunnelインターフェースの両端で疎通できない）んですね。

引用：

たとえば、GREを構成し宛先がloop backの場合、そのloop backにも
ipリーチャビリティが無いと通信ができないという解説になるのでしょうか?

tunnel destinationへのリーチャビリティを確認するのであれば、keepaliveを使うことになりますね。

Re: GRE up/upで通信が失敗する場合の原因

msg# 1.2

前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2019-5-11 14:33

rokubusyuu 一人前

投稿数: 27

arashi1977さん
解説いただきありがとうございます。

up/upの条件が、destのルーティングが存在することだから、destのリーチャビリティはup/upの条件では無いということですね。
ルーティングテーブルに記載が有る=リーチャビリティが有ると勝手に脳内変換してました。

ありがとうございます。

ツリー構造順で表示投稿の新しいものから

>フォーラム検索へ