為什麼GRE Tunnel兩端的介面IP地址不在同一網段甚至完全一樣時隧道仍可工作？

06-04

測試拓撲如下：
即使我將AR3的Tunnel 0/0/0的IP地址設為172.16.2.1/24，甚至172.16.1.1/24，仍然可以在PC1上PING通PC2。請問原理是什麼呢？
AR1配置如下：
[V200R003C00] # snmp-agent local-engineid 800007DB03000000000000 snmp-agent # clock timezone China-Standard-Time minus 08:00:00 # portal local-server load flash:/portalpage.zip # drop illegal-mac alarm # wlan ac-global carrier id other ac id 0 # set cpu-usage threshold 80 restore 75 # aaa authentication-scheme default authorization-scheme default accounting-scheme default domain default domain default_admin local-user admin password cipher %$%$K8m.Nt84DZ}e#&<0`8bmE3Uw}%$%$ local-user admin service-type http # firewall zone Local priority 15 # interface GigabitEthernet0/0/0 ip address 192.168.1.1 255.255.255.0 # interface GigabitEthernet0/0/1 ip address 10.0.12.1 255.255.255.0 # interface NULL0 # interface Tunnel0/0/0 ip address 172.16.1.2 255.255.255.0 tunnel-protocol gre source 10.0.12.1 destination 10.0.23.3 # ip route-static 0.0.0.0 0.0.0.0 10.0.12.2 ip route-static 192.168.3.0 255.255.255.0 Tunnel0/0/0 # user-interface con 0 authentication-mode password user-interface vty 0 4 user-interface vty 16 20 # wlan ac # return
AR3配置如下：

[V200R003C00] # snmp-agent local-engineid 800007DB03000000000000 snmp-agent # clock timezone China-Standard-Time minus 08:00:00 # portal local-server load flash:/portalpage.zip # drop illegal-mac alarm # wlan ac-global carrier id other ac id 0 # set cpu-usage threshold 80 restore 75 # aaa authentication-scheme default authorization-scheme default accounting-scheme default domain default domain default_admin local-user admin password cipher %$%$K8m.Nt84DZ}e#&<0`8bmE3Uw}%$%$ local-user admin service-type http # firewall zone Local priority 15 # interface GigabitEthernet0/0/0 ip address 192.168.3.1 255.255.255.0 # interface GigabitEthernet0/0/1 ip address 10.0.23.3 255.255.255.0 # interface NULL0 # interface Tunnel0/0/0 ip address 172.16.1.2 255.255.255.0 tunnel-protocol gre source 10.0.23.3 destination 10.0.12.1 # ip route-static 0.0.0.0 0.0.0.0 10.0.23.2 ip route-static 192.168.1.0 255.255.255.0 Tunnel0/0/0 # user-interface con 0 authentication-mode password user-interface vty 0 4 user-interface vty 16 20 # wlan ac # return

有些技術細節值的去深究，但是也有一些技術細節就跟著最佳實踐走就行，沒必要問得蘿蔔不生根。你這個問題就是第二種...

先劇透下最佳實踐就是：隧道兩端的IP地址應該配置成同一網段，後面我再來說為什麼。

你問：為什麼不在同一網段也能通？

答案：因為GRE是point-to-point的隧道，你靜態路由又直接寫了出介面，那肯定封裝完直接轉發出去了。

你又問：既然是點到點的隧道，是不是我不寫IP地址也可以通？

答案：不是的，IP不在同一網段和沒有IP完全不是一回事，上層的TCP、ICMP，甚至應用層的數據都是依賴於三層的IP去承載的，沒有IP你如何將數據封裝成包？用Underlay的外層IP？別鬧了，Underlay的外層IP在對端的路由器收到數據的時候直接彈出了(解封裝)，這個時候真實的數據能沒有IP層？

既然不在同一網段照樣能通，我為什麼要說，最佳實踐還是把隧道IP地址配成同一網段。

因為現網裡很多場景會在隧道上跑路由協議啊，就拿OSPF來舉例子，IP不在同一網段，OSPF的鄰居都無法建立，根本不要去想後面同步LSDB了。

這個問題Eric回答的很好，把核心思想都說出來了，基於我的理解談談。

配置過串列介面HDLC 或PPP協議的同學一定用過「 IP unnumbered 介面xx」，什麼意思呢？

就是該串列介面借用別的介面的IP，而無需浪費重新有自己獨立的IP，那為何一定要借用IP呢？

因為三層介面沒有IP信息就無法完成初始化，沒有初始化就不會工作。

之所以提到串列介面，是因為他是「Point-to-Point」特徵，而GRE Tunnel 也是虛擬的點對點的通道，介面IP只是為了完成初始化，而沒有互聯互通的意義，因為那個transport source /destination 可以完成互聯互通的任務。

你這裡是通過靜態路由互相指 site to site 的路由，當site 數目變多，路由條目巨大時，靜態路由管理很不方便，擴展性差，要考慮使用路由協議來分發site 之間的私有路由，要在Tunnel 介面上運行路由協議，這時則需要Tunnel介面IP在一個網段，否則無法建立鄰居關係。

此時Tunnel介面的IP地址、網路掩碼才有通信的意義！

僅供參考。

對現有的答案都不太滿意，本質的原因在於這個IP其實根本就不出現在網路協議里。這跟網關的情況有點像。我們複習一下網關，三層路由的時候會有個路由項指向網關的IP地址，發送需要三層路由的包的時候，發送方解析網關的MAC，然後向網關的MAC發送IP包，網關將MAC地址替換成自己為發送方、下一跳為接收方然後轉發，我們可以看到在實際發送的報文里其實沒有出現網關IP，網關IP只起到了指示路由設備，或者說提供網關MAC地址的作用，如果配置一個錯誤的網關IP，然後通過靜態MAC綁定綁到正確的MAC，也仍然是可以通的。

GRE的情況類似，GRE的報文是一個三層包套著一個三層包，外層的三層包起到了類似於普通IP包里MAC層的作用，負責提供通路；內層直接就是源和目的IP，中轉介面上的IP是不出現的。這就相當於直接綁定了網關MAC地址的情況，這時候網關IP配錯了也不會影響通信了。

tunnel 介面上的IP作用和網關IP類似，是為了方便管理路由，IP配同網段的情況下，路由規則指向對端IP就可以自動找到相應的GRE介面，而不需要記住介面的編號，管理起來比較方便。

GRE隧道「屬於」主機，也就是說，我們所說的「隧道」，邏輯上說，是A主機和B主機間的一個協議，是主機的，不是介面的，不是IP路由邏輯主體的。
A主機和B主機，是各自作為一個獨立的處理節點處理的。這個處理節點，在「物理主機」中，就是一個單獨的應用，單獨的模塊。
A的任務第一就是把「交給A要轉到B的包」打包成GRE隧道包，交給IP層協議處理模塊。第二就是把「B發過來的GRE包」脫去GRE封裝，交給IP層協議處理模塊。
IP層協議模塊掌管處理過的包的路由。
上述3中，A接收包的來源，就是IP路由模塊。

介面地址與IP協議處理模塊相關。

GRE模塊無關。

換句話說，

物理主機A的IP協議處理模塊收到一個IP包以後，發現這個包路由目的是GRE隧道，那麼就把這個包轉給GRE處理模塊
GRE處理模塊裡面配置了隧道的源地址和目的地址，配置了打包的方式（以及其他例如安全相關的參數），GRE模塊則按照這些配置把收到的那個包封裝成GRE包
GRE處理模塊把封裝好的包交給IP協議處理模塊
IP協議處理模塊根據新的目的IP地址路由新包

接收端也類似，只是把上述的2修改為「根據配置去掉封裝變成裸包」

GRE介面是點到點(p2p)介面，點到點介面的特點是從一個介面進去的報文必然從另一個介面出來，本來就不要求兩端介面地址在同一網段

謝邀。。。真的謝邀。真的不好意思，，我不懂這個，覺得不回不禮貌，還是回復一下啦。

先說結論：

在三層網路中，沒有「內網網段」的概念。內網網段只在二層網路中有意義。
GRE隧道如果僅用於轉發，那麼隧道介面本身也可以不配置IP地址。

以下是我在兩台Linux機器上做的實驗。兩台機器分別為：

A，本機IP：192.168.10.51
B，本機IP：192.168.10.52

# 在 A 上創建隧道 (host A)# ip link add gre-tun type gre local 192.168.10.51 remote 192.168.10.52 (host A)# ip link set dev gre-tun up # 在 B 上創建隧道（命令相同，只需要交換local、remote的地址） (host B)# ip link add gre-tun type gre local 192.168.10.52 remote 192.168.10.51 (host B)# ip link set dev gre-tun up


# 在 A 上設置一個臨時的IP，10.1.2.1，可以設置到任何一個iface上

# 注意，我沒有把這個IP綁到gre隧道上，而是任意其他iface

(host A)# ip addr add 10.1.2.1/32 dev lo

# 在 B 上同樣設置一個臨時IP，10.1.2.2

(host B)# ip addr add 10.1.2.2/32 dev lo
# 在 A 上配置路由，指定訪問 10.1.2.2 時，通過 gre-tun 隧道來訪問

(host A)# ip route add 10.1.2.2/32 dev gre-tun

# 在 B 上同樣配置一個路由

(host B)# ip route add 10.1.2.1/32 dev gre-tun
# 然後嘗試在 A 上 ping 10.1.2.2

(host A)# ping -c 1 10.1.2.2 -I 10.1.2.1

PING 10.1.2.2 (10.1.2.2) from 10.1.2.1 : 56(84) bytes of data.

64 bytes from 10.1.2.2: icmp_seq=1 ttl=64 time=0.363 ms
--- 10.1.2.3 ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 0.363/0.363/0.363/0.000 ms

# 為了確認這個ping確實是在隧道中走的，我們可以在B上抓包 (host B)# tcpdump -i gre-tun -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on gre-tun, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 17:07:39.518494 IP 10.1.2.1 &> 10.1.2.2: ICMP echo request, id 27880, seq 3, length 64 17:07:39.518533 IP 10.1.2.2 &> 10.1.2.1: ICMP echo reply, id 27880, seq 3, length 64

接下來解釋：

1、關於網段

我們平時說的網段是指，在同一二層網路中的設備，設置IP地址時可以配置一個子網掩碼，在訪問同一子網的其他設備時，會通過ARP協議獲取其他設備的mac地址，並通過mac地址來實現訪問。同時，這種情況下，同一子網的機器也可以在三層地址上廣播數據（實際上仍然是二層上的通信）。脫離了二層網路，就沒有這一層網段的概念了。

2、GRE隧道

GRE隧道內跑的是三層的數據，所以與網段無關。所有二層的東西都不可能在GRE中跑，比如ARP協議是無法在GRE中使用的。給GRE隧道的介面配置「同網段/不同網段的IP地址」，本身就是一個偽概念了。我在實踐中，給GRE隧道介面配置的IP一般都是 /32 的，配置任何非 /32 的地址沒有意義。至於具體用什麼IP，完全取決於管理方便的需求。實際上，如果隧道兩端的設備都有各自的IP，可以直接用現成的IP綁到gre隧道的介面上，沒有任何問題（是的，同一個設備上，不同的iface可以綁定相同的IP），這樣就不需要管理額外的IP地址了。

3、為什麼GRE隧道兩端不配置IP都可以通信

這個其實其他回答已經解釋了，GRE隧道是一個點對點的隧道，從隧道一段發送出去的包，目的地只有一個，這是明確的，隨意無需明確指明通信對端是誰。不同於一般的二層網路，二層網路中可能有許多設備（通過交換機）與你相連，你必須要指明需要發送給哪一個設備。

我也是謝邀，表示太高深看不懂