一、GRE簡介
通用路由封裝協議GRE（Generic Routing Encapsulation）可以對某些網絡層協議（如IPX、ATM、IPv6、AppleTalk等）的數據報文進行封裝，使這些被封裝的數據報文能夠在另一個網絡層協議（如IPv4）中傳輸。GRE提供了將一種協議的報文封裝在另一種協議報文中的機制，是一種三層隧道封裝技術，使報文可以通過GRE隧道透明的傳輸，解決異種網絡的傳輸問題。
GRE實現機制簡單，對隧道兩端的設備負擔小。GRE隧道可以通過IPv4網絡連通多種網絡協議的本地網絡，有效利用了原有的網絡架構，降低成本。GRE隧道擴展了跳數受限網絡協議的工作范圍，支持企業靈活設計網絡拓撲。GRE隧道可以封裝組播數據，和IPSec結合使用時可以保證語音、視頻等組播業務的安全。GRE隧道支持使能MPLS LDP，使用GRE隧道承載MPLS LDP報文，建立LDP LSP，實現MPLS骨干網的互通。GRE隧道將不連續的子網連接起來，用於組建VPN，實現企業總部和分支間安全的連接。
二、GRE實現過程
報文在GRE隧道中傳輸包括封裝和解封裝兩個過程。
如上圖所示，如果X協議報文從Ingress PE向Egress PE傳輸，則封裝在Ingress PE上完成，而解封裝在Egress PE上進行。封裝后的數據報文在網絡中傳輸的路徑，稱為GRE隧道。
1、封裝
Ingress PE從連接X協議的接口接收到X協議報文后，首先交由X協議處理。X協議根據報文頭中的目的地址在路由表或轉發表中查找出接口，確定如何轉發此報文。如果發現出接口是GRE Tunnel接口，則對報文進行GRE封裝，即添加GRE頭。根據骨干網傳輸協議為IP，給報文加上IP頭。IP頭的源地址就是隧道源地址，目的地址就是隧道目的地址。根據該IP頭的目的地址（即隧道目的地址），在骨干網路由表中查找相應的出接口並發送報文。之后，封裝后的報文將在該骨干網中傳輸。
2、解封裝
解封裝過程和封裝過程相反。Egress PE從GRE Tunnel接口收到該報文，分析IP頭發現報文的目的地址為本設備，則Egress PE去掉IP頭后交給GRE協議處理。GRE協議剝掉GRE報頭，獲取X協議，再交由X協議對此數據報文進行后續的轉發處理。
3、GRE報文格式
GRE封裝后的報文結構如上圖所示。
1）乘客協議（Passenger Protocol）：
封裝前的報文稱為凈荷，封裝前的報文協議稱為乘客協議。
2）封裝協議（Encapsulation Protocol）：
GRE Header是由封裝協議完成並填充的，封裝協議也稱為運載協議（Carrier Protocol）。
3）傳輸協議（Transport Protocol或者Delivery Protocol）：
負責對封裝后的報文進行轉發的協議稱為傳輸協議。
GRE頭的各字段解釋如下表所示
GRE頭的各字段解釋
| GRE頭 | 字段解釋 |
| C | 校驗和驗證位 該位置1，表示GRE頭插入了校驗和（Checksum）字段 該位置0，表示GRE頭不包含校驗和字段 |
| K | 關鍵字位。 該位置1，表示GRE頭插入了關鍵字（Key）字段 該位置0，表示GRE頭不包含關鍵字字段 |
| Recursion | 表示GRE報文被封裝的層數。完成一次GRE封裝后將該字段加1.如果封裝層數大於3，則丟棄該報文。該字段的作用是防止報文被無限次的封裝。 RFC1701規定該字段默認值為0。RFC2784規定當發送和接收端該字段不一致時不會引起異常，且接收端必須忽略該字段。 設備實現時該字段僅在加封裝報文時用作標記隧道嵌套層數，GRE解封裝報文時不感知該字段，不會影響報文的處理。 |
| Flags | 預留字段。當前必須置為0 |
| Version | 版本字段。必須置為0 |
| Protocol Type | 標識乘客協議的協議類型。常見的乘客協議為IPv4協議，協議代碼為0x0800 |
| Checksum | 對GRE頭及其負載的校驗和字段。 |
| Key | 關鍵字字段，隧道接收端用於對收到的報文進行驗證。 |
因為目前實現的GRE頭不包含源路由字段，所以Bit 1、Bit 3和Bit 4都置為0
四、GRE的安全機制
GRE本身提供兩種基本的安全機制：校驗和驗證，識別關鍵字。
1）校驗和驗證
校驗和驗證是指對封裝的報文進行端到端校驗。若GRE報文頭中的C位標識位置1，則校驗和位有效。發送方將根據GRE頭及Payload信息計算校驗和，並將包含校驗和的報文發送給對端。接收方對接收到的報文計算校驗和，並與報文中的校驗和比較，如果一致則對報文進一步處理，否則丟棄。
隧道兩端可以根據實際應用的需要決定配置校驗和或禁止校驗和。如果本端配置了校驗和而對端沒有配置，則本端將不會對接收到的報文進行校驗和檢查，但對發送的報文計算校驗和；相反，如果本端沒有配置校驗和而對端已配置，則本端將對從對端發來的報文進行校驗和檢查，但對發送的報文不計算校驗和。
2）識別關鍵字
識別關鍵字（Key）驗證是指對Tunnel接口進行校驗。通過這種弱安全機制，可以防止錯誤識別、接收其它地方來的報文。RFC1701中規定：若GRE報文頭中的K位為1，則在GRE頭中插入一個四字節長關鍵字字段，收發雙方將進行識別關鍵字的驗證。
關鍵字的作用是標志隧道中的流量，屬於同一流量的報文使用相同的關鍵字。在報文解封裝時，GRE將基於關鍵字來識別屬於相同流量的數據報文。只有Tunnel兩端設置的識別關鍵字完全一致時才能通過驗證，否則將報文丟棄。這里的“完全一致”是指兩端都不設置識別關鍵字，或者兩端都設置相同的關鍵字。
五、GRE的Keepalive檢測
由於GRE協議並不具備檢測鏈路狀態的功能，如果對端接口不可達，隧道並不能及時關閉該Tunnel連接，這樣會造成源端會不斷的向對端轉發數據，而對端卻因隧道不通接收不到報文，由此就會形成數據空洞。
GRE的Keepalive檢測功能可以檢測隧道狀態，即檢測隧道對端是否可達。如果對端不可達，隧道連接就會及時關閉，避免因對端不可達而造成的數據丟失，有效防止數據空洞，保證數據傳輸的可靠性。Keeppalive檢測功能的實現過程如下：
- 當GRE隧道的源端使能Keepalive檢測功能后，就創建一個定時器，周期地發送Keepalive探測報文，同時通過計數器進行不可達計數。每發送一個探測報文，不可達計數加1
- 對端每收到一個探測報文，就給源端發送一個回應報文
- 如果源端的計數器值未達到預先設置的值就收到回應報文，就表明對端可達。如果源端的計數器值到達預先設置的值——重試次數（Retry Times）時，還沒收到回送報文，就認為對端不可達。此時，源端將關閉隧道連接。但是源端口仍會繼續發送Keepalive報文，若對端Up，則源端口也會Up，建立隧道鏈接
對於設備實現的GRE Keepalive檢測功能，只要在隧道一端配置Keepalive，該端就具備Keepalive功能，而不要求隧道對端也具備該功能。隧道對端收到報文，如果是Keepalive探測報文，無論是否配置Keepalive，都會給源端發送一個回應報文。
六、GRE應用場景
1）多協議本地網可以通過這GRE隧道傳輸
如上圖所示，Term1和Term2是運行IPv6的本地網，Term3和Term4是運行IP的本地網，不同地域的子網間需要通過公共的IP網絡互通。通過在Router_1和Router_2之間采用GRE協議封裝的隧道，Term1和Term2、Term3和Term4可以互不影響地進行通信。
2）通過GRE擴大跳數受限的網絡工作范圍
在上圖中，網絡運行IP協議，假設IP協議限制跳數為255。如果兩台PC之間的跳數超過255，它們將無法通信。在網絡中選取兩台設備建立GRE隧道，可以隱藏設備之間的跳數，從而擴大網絡的工作范圍。
例如，RIP路由的跳數為16時表示路由不可達。此時，可以在兩台設備上建立GRE隧道實現邏輯直連，使經過GRE隧道的RIP路由跳數減至16以下，保證路由可達。
3）GRE與IPSec結合，保護多播數據
GRE可以封裝多播數據並在GRE隧道中傳輸。
如上圖所示，GRE over IPSec隧道應用，對於多播數據需要在IPSec隧道中傳輸的情況，可以先建立GRE隧道，對多播數據進行GRE封裝，再對封裝后的報文進行IPSec加密，從而實現多播數據在IPSec隧道中的加密傳輸。
4）通過GRE隧道組建L2VPN和L3VPN
通常，MPLS VPN骨干網通常使用LSP作為公網隧道。如果骨干網的核心設備（P設備）不具備MPLS功能，而邊緣設備（PE設備）具備MPLS功能，那么骨干網就不能使用LSP作為公網隧道。此時，骨干網可以使用GRE隧道替代LSP，從而在骨干網提供三層或二層VPN解決方案。
LDP over GRE技術通過在GRE隧道接口上使能MPLS LDP，使用GRE隧道承載MPLS LDP報文，建立LDP LSP。
如上圖，企業在PE1和PE2之間部署L2VPN或者L3VPN業務，由於骨干網設備可能未啟用或不支持MPLS，需要在PE1和PE2之間建立一條跨越GRE隧道的LDP LSP。
如上圖，骨干網P2設備支持MPLS，但P1設備不支持，此時可以通過在PE1和P2之間建立GRE隧道，從而建立一條跨越GRE隧道的LDP LSP。
5）CE采用GRE隧道接入MPLS VPN
基於MPLS骨干網的VPN服務可以給客戶提供比傳統IP VPN更優質的服務。因此，MPLS VPN技術是運營商選擇的主流VPN技術。但是Internet是基於IP技術的，且基於IP技術的骨干網還是大量存在的。
在MPLS VPN中，為了讓用戶端設備CE（Customer Edge）接入VPN中往往需要CE與MPLS骨干網的PE（Provider Edge）設備之間有直接的物理鏈路，即在同一個網絡中。在這樣的組網中，需要在PE上將VPN與PE到CE的物理接口進行關聯。
但實際組網中，並非所有的CE和PE都能用物理鏈路直接相連。例如，很多已經連接到Internet或基於IP技術的骨干網上的機構，其CE和PE設備之間地理位置上相距甚遠，不可能直接接入到MPLS骨干網的PE設備上。這樣就無法通過Internet或者是IP骨干網直接訪問MPLS VPN內部的站點。
為了讓CE也能接入到MPLS VPN中，可以考慮在CE和PE之間創建“邏輯上的直連”。也就是說，可以在CE和PE間利用公共網絡或某私有網絡相連，並在CE與PE之間創建GRE隧道。這樣，可以看成CE和PE直連。在PE上將VPN與PE-CE之間的接口進行關聯時，就可以把GRE隧道當作一個物理接口，在這個接口上進行VPN關聯。
采用GRE隧道接入MPLS VPN時，GRE的實現模式可按以下三種情形來划分：
5.1 穿過公網的GRE
GRE隧道關聯某個VPN實例，GRE隧道的源地址和目的地址為公網地址，不屬於VPN實例。
在這種組網中，CE和PE都需要有屬於公網的接口，該接口需要使用公網IP地址。CE的公網路由表中需要有到PE的路由，PE公網路由表也需要有到CE的路由。
5.2 穿越VPN的GRE
GRE隧道關聯某個VPN實例（例如VPN1），GRE隧道的源接口綁定了另一個VPN實例（例如VPN2），即GRE隧道需要穿越VPN2。
與穿過公網的GRE相比，穿越VPN的GRE不同點在於CE不是通過公共網絡與PE互連，而是通過另一個VPN（如VPN2）與PE互連。也就是說，CE上流向PE的私網數據的出接口及PE上返回該CE的私網數據流量的出接口都屬於VPN2。
例如上圖中，PE1和PE2是一級運營商的MPLS骨干網邊界設備。VPN2是屬於二級運營商的一個VPN。CE1和CE2是屬於用戶的設備。為了在此網絡環境中部署一個基於MPLS網絡的VPN（如VPN1），可以在PE1和CE1之間搭建一個穿越VPN2的GRE，在邏輯上使CE1與PE1直連。
5.3 私有網絡的GRE
GRE隧道關聯某個VPN實例，而GRE隧道的源端口（或源地址）和目的地址也屬於該VPN實例。
在這種組網中，GRE隧道的源和目的地址都屬於私有網絡，在實際的應用中在私有網絡里再創建一個隧道到PE，沒有什么價值，因此不推薦使用。
在上圖中，不如直接使用R1作為CE設備。