元ﾄﾋﾟ次ﾚｽ Re: GRE up/upで通信が失敗する場合の原因 最強WEB問題集CCNP TSHOOT (2019/5/11) 例えばあるﾙｰﾀで以下の設定を行っているとして
[code]
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
[/code]
そのﾙｰﾀが以下のように
- ﾙｰﾃｨﾝｸﾞﾃｰﾌﾞﾙにはtunnel destinationで指定したｱﾄﾞﾚｽ向けの経路情報がある
- しかし(tunnel destinationそのものではなく)宛先ﾈｯﾄﾜｰｸへのﾈｸｽﾄﾎｯﾌﾟへの到達性はない
状態であってもTunnelｲﾝﾀｰﾌｪｰｽはup/upになります｡
[code]
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 ←ここ
[/code]

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で通信が失敗する場合の原因(2019/5/11)
• Re: GRE up/upで通信が失敗する場合の原因(2019/5/11)

元ﾄﾋﾟ次ﾚｽ