GRE介紹
定義
對于IPv4 GRE和IPv6 GRE都支持的特性,正文中如果不做特殊說明,則表示二者實現無差異。IPv4 GRE和IPv6 GRE的實現差異,請參考附錄。
GRE(Generic Routing Encapsulation)是通用路由封裝協議,可以對某些網絡層協議(如IPX、ATM、IPv6、AppleTalk等)的數據報進行封裝,使這些被封裝的數據報文能夠在IPv4網絡中傳輸。
GRE提供了將一種協議的報文封裝在另一種協議報文中的機制,使報文能夠在異種網路中傳輸,而異種報文傳輸的通道稱為Tunnel。
NE40E支持如下GRE:
- 一維Tunnel接口的GRE隧道,也可稱為分布式GRE,GRE隧道報文直接在入接口板上進行封裝和解封裝處理,分布式GRE使用的是一維Tunnel接口。同時配置復雜流分類、car等業務時,可能會出現業務占用帶寬翻倍的問題。
目的
為了使某些網絡層協議(如IPX、ATM、IPv6、AppleTalk等)的報文能夠在IPv4網絡中傳輸,可以將某些網絡層協議的報文進行封裝,以此解決了異種網絡的傳輸問題。
GRE也可以作為VPN的第三層隧道協議,為VPN數據提供透明傳輸通道。目前,只有IPv4 L3VPN支持GRE隧道,IPv6 L3VPN暫不支持GRE隧道。
受益
GRE對設備的性能的要求較低,可以在不支持MPLS的設備間建立隧道。
GRE基本原理
產生原因
骨干網中一般采用單一網絡協議(例如IPv4)進行數據報文傳輸,但是不同的非骨干網上可能會使用不同網絡協議(例如:IP、IPv6、IPX等)進行數據報文傳輸。由于骨干網與非骨干網使用的協議不同,這樣將導致非骨干網之間無法通過骨干網傳輸數據報文。GRE協議通過實現一種協議封裝另一種協議來解決這個問題。
如圖3-1所示,group1和group2是運行Novell IPX的非骨干網,term1和term2是運行IPv6的非骨干網,中間的骨干網使用的是IPv4網絡。為了實現group1和group2、term1和term2通過骨干網傳輸數據,可以在DeviceA和DeviceB之間采用GRE協議建立隧道,當數據報文從group1或term1發送至DeviceA后,將會被封裝在一個GRE數據包中,所得的GRE數據包可以封裝在IPv4協議中,然后被轉發。
圖3-1 GRE組網圖
相關概念
- GRE報文格式系統收到需要進行封裝和路由的某網絡層協議(如IPX)數據時,將首先對其加上GRE報文頭,使之成為GRE報文,再將其封裝在另一協議(如IP)中。這樣,此報文的轉發就可以完全由IP協議負責。封裝后的報文的格式如圖3-2所示:圖3-2 封裝好的GRE報文格式
凈荷(Payload):系統收到的需要封裝和傳輸的數據報稱為凈荷。乘客協議(Passenger Protocol):封裝前的報文協議稱為乘客協議。封裝協議(Encapsulation Protocol):上述的GRE協議稱為封裝協議,也稱為運載協議(Carrier Protocol)。傳輸協議(Transport Protocol或者Delivery Protocol):負責對封裝后的報文進行轉發的協議稱為傳輸協議。例如一個封裝在IP Tunnel中的IPX報文的格式可以表示為:圖3-3 Tunnel中傳輸IPX報文的格式 對于IPv6 GRE隧道:傳輸協議為IPv6協議。需要進行封裝和路由的報文目前只支持IPv4報文和IPv6報文。 - GRE報文頭GRE報文頭格式如圖3-4所示:圖3-4 GRE報文頭格式
各字段解釋如下:C:校驗和驗證位。如果該位置1,表示GRE頭插入了校驗和(Checksum)字段;該位為0表示GRE頭不包含校驗和字段。K:關鍵字位。如果該位置1,表示GRE頭插入了關鍵字(Key)字段;該位為0表示GRE頭不包含關鍵字字段。Recursion:用來表示GRE報文被封裝的層數。完成一次GRE封裝后將該字段加1。如果封裝層數大于3,則丟棄該報文。該字段的作用是防止報文被無限次的封裝。 相關標準規定該字段默認值為0。相關標準規定當發送和接收端該字段不一致時不會引起異常,且接收端必須忽略該字段。NE40E實現時該字段僅在加封裝報文時用作標記隧道嵌套層數,GRE解封裝報文時不感知該字段,不會影響報文的處理。Flags:預留字段。當前必須設為0。Version:版本字段,必須置為0。Version為1是使用在相關標準的PPTP中。Protocol Type:乘客協議的協議類型。Checksum:對GRE頭及其負載的校驗和字段。Key:關鍵字字段,隧道接收端用于對收到的報文進行驗證。因為目前實現的GRE頭不包含源路由字段,所以Bit 1、Bit 3和Bit 4都置為0。
報文在GRE中的傳輸過程
報文在GRE隧道中傳輸包括封裝和解封裝兩個過程。如圖3-5所示,如果私網報文從Ingress PE向Egress PE傳輸,則封裝在Ingress PE上完成;而解封裝在Egress PE上進行。
圖3-5 私有網絡通過GRE隧道互連
- 封裝Ingress PE從連接私網的接口接收到私網報文后,首先交由私網上運行的協議模塊處理。私網協議模塊檢查私網報文頭中的目的地址域在私網路由表或轉發表中查找出接口,確定如何路由此包。如果發現出接口是GRE Tunnel接口,則將此報文發給隧道模塊。隧道模塊收到此報文后進行如下處理:隧道模塊根據乘客報文的協議類型和當前GRE隧道所配置的Key參數,對報文進行GRE封裝,即添加GRE頭。根據配置信息(傳輸協議為IP),給報文加上IP頭。該IP頭的源地址就是隧道源地址,IP頭的目的地址就是隧道目的地址。將該報文交給IP模塊處理。IP模塊根據該IP頭目的地址,在公網路由表中查找相應的出接口并發送報文。之后,封裝后的報文將在該IP公共網絡中傳輸。
- 解封裝解封裝過程和封裝過程相反。Egress PE從連接公網的接口收到該報文,分析IP頭發現報文的目的地址為本設備,且協議字段值為47,表示協議為GRE,于是交給GRE模塊處理。GRE模塊去掉IP頭和GRE報文頭,并根據GRE頭的Protocol Type字段,發現此報文的乘客協議為私網上運行的協議,于是交由此私網協議處理。此私網協議像對待一般數據報一樣對此數據報進行轉發。
使用價值
在網絡中部署GRE隧道,有益于以下三個方面:
- 使客戶的部署不同協議網絡使用單一網絡協議進行數據傳輸。
- 可以擴大受協議的步跳數限制的網絡的工作范圍。
- 將一些不能連續的子網連接起來,用于組建VPN。
Keepalive檢測
產生原因
由于GRE協議并不具備檢測鏈路狀態的功能。如果遠端端口不可達,隧道并不能及時關閉該Tunnel連接,這樣會造成源端會不斷的向對端轉發數據,而對端卻因Tunnel不通而丟棄所有報文,由此就會形成數據發送的空洞。
NE40E實現了GRE隧道的鏈路狀態檢測功能(Keepalive檢測功能)。Keepalive檢測功能用于時刻檢測隧道鏈路是否處于Keepalive狀態,即檢測隧道對端是否可達。如果對端不可達,隧道連接就會及時關閉,避免形成數據空洞。
實現過程
如果GRE隧道源端使能Keepalive檢測功能,則會周期地發送Keepalive探測報文給對端。若對端可達,則源端會收到對端的回應報文;否則,收不到對端的回應報文。具體過程如下:
- 當GRE隧道的源端使能Keepalive檢測功能后,就創建一個定時器,周期地發送Keepalive探測報文,同時進行不可達計數。每發送一個探測報文,不可達計數加1。
- 對端每收到一個探測報文,就給源端發送一個回應報文。
- 如果源端的計數器值未達到預先設置的值就收到回應報文,就表明對端可達,并把不可達計數清零。如果源端的計數器值到達預先設置的值——重試次數(Retry Times)時,還沒收到回送報文,就認為對端不可達。此時,源端將關閉隧道連接。
對于NE40E實現的GRE,只要在隧道一端配置Keepalive,該端就具備Keepalive功能,而不要求隧道對端也具備該功能。隧道對端收到報文,如果是Keepalive探測報文,無論是否配置Keepalive,都會給源端發送一個回應報文。
使用價值
Keepalive檢測功能可以檢測隧道狀態,避免因對端不可達而造成的數據丟失,保證數據傳輸的可靠性。
GRE的安全機制
GRE支持識別關鍵字驗證。識別關鍵字(key)是指對Tunnel接口進行校驗。通過這種弱安全機制,可以防止錯誤識別、接收其它地方來的報文。
相關標準中規定:若GRE報文頭中的K位為1,則在GRE頭中插入關鍵字字段,收發雙方將進行通道識別關鍵字的驗證。
關鍵字是一個四字節長的數,在報文封裝時被插入GRE頭。關鍵字的作用是標志隧道中的流量。屬于同一流量的報文使用相同的關鍵字。在報文解封裝時,隧道端將基于關鍵字來識別屬于相同流量的數據報。
只有Tunnel兩端設置的識別關鍵字完全一致時才能通過驗證,否則將報文丟棄。這里的“完全一致”是指兩端都不設置識別關鍵字;或者兩端都設置關鍵字,且關鍵字的值相等。
GRE應用
擴大跳數受限的網絡工作范圍
圖3-6 擴大網絡工作范圍
在圖3-6中,網絡運行IP協議,假設IP協議限制跳數為255。如果兩臺PC之間的跳數超過255,它們將無法通信。在網絡中使用隧道可以隱藏一部分步跳,從而擴大網絡的工作范圍。
將不連續的子網連接起來,用于組建VPN
使用GRE隧道可以將不連續的子網連接起來,實現跨越廣域網的VPN。
例如,兩個VPN子網Site1和Site2位于不同的城市,通過在網絡邊界設備之間建立GRE隧道,可以把這兩個子網連接成一個連續的VPN網絡。
GRE可應用于L2VPN,也可以應用于L3VPN。有兩種模式:
- CPE-based VPN中,GRE隧道兩端駐留在CE上,如圖3-7。圖3-7 GRE in CPE-based VPN
- Network-based VPN中,GRE隧道兩端駐留在PE上,如圖3-8。圖3-8 GRE in Network-based VPN
通常,VPN骨干網使用LSP作為公網隧道。但如果骨干網核心設備(P設備)只提供純IP功能,不具備MPLS功能;而網絡邊緣的PE具備MPLS功能,這樣,就不能使用LSP作為公網隧道。此時,可以使用GRE隧道替代LSP,在核心網提供三層或二層VPN解決方案。其私網報文在VPN骨干網中傳輸時,報文格式如圖3-9。
圖3-9 含MPLS標簽的GRE報文格式
GRE隧道也可以作為非MPLS的VPN骨干網隧道。這種情況下,私網報文在VPN骨干網中傳輸時不含有MPLS標簽,其報文格式如圖3-10。
圖3-10 不含MPLS標簽的GRE報文格式
CE采用GRE隧道接入MPLS VPN
在MPLS VPN中,為了讓用戶端設備CE(Customer Edge)接入VPN中往往需要CE與MPLS骨干網的PE(Provider Edge)設備之間有直接的物理鏈路,即在同一個網絡中。在這樣的組網中,需要在PE上將VPN與PE到CE的物理接口進行關聯。
如圖3-11所示,在實際組網中,并非所有的CE和PE都能用物理鏈路直接相連。例如,很多已經連接到Internet或基于IP技術的骨干網上的機構,其CE和PE設備之間地理位置上相距甚遠,不可能直接接入到MPLS骨干網的PE設備上。這樣就無法通過Internet或者是IP骨干網直接訪問MPLS VPN內部的站點。
圖3-11 CE使用基于IP技術的骨干網接入MPLS VPN骨干網
為了讓CE能接入到MPLS VPN且可以保證數據傳輸的安全性,可以在CE和PE間利用公共網絡或某私有網絡相連,并在CE與PE之間創建GRE隧道。這樣,可以看成CE和PE直連。在PE上將VPN與PE-CE之間的接口進行關聯時,就可以把GRE隧道當作一個物理接口,在這個接口上進行VPN關聯。
采用GRE隧道接入MPLS VPN時,GRE的實現模式可按以下三種情形來劃分:
- 私有網絡的GRE:GRE隧道關聯某個VPN實例,而GRE隧道的源接口(或源地址)和目的地址也屬于該VPN實例。
- 穿過公網的GRE:GRE隧道關聯某個VPN實例,GRE隧道的源地址和目的地址為公網地址,不屬于VPN實例。
- 穿越VPN的GRE:GRE隧道關聯某個VPN實例(例如VPN1),GRE隧道的源接口綁定了另一個VPN實例(例如VPN2),即GRE隧道需要穿越VPN2。
私有網絡的GRE
圖3-12 私有網絡的GRE示意圖
如圖3-12所示,GRE隧道的源和目的地址都屬于私有網絡。在實際的應用中在私有網絡里再創建一個隧道到PE的使用價值不高,因此不推薦使用,建議直接使用Device1作為CE設備。
穿過公網的GRE
在這種組網中,CE和PE都需要有屬于公網的接口,該接口需要使用公網IP地址。CE的公網路由表中需要有到PE的路由,PE公網路由表也需要有到CE的路由。
圖3-13 穿越公網的GRE示意圖
此外,為了讓CE上的私網流量通過隧道傳輸到PE上,CE的路由表中,到遠端site網段路由的出接口為GRE隧道接口,下一跳為隧道對端接口的IP地址。
穿越VPN的GRE
與穿過公網的GRE相比,穿越VPN的GRE不同點在于CE不是通過公共網絡與PE互連,而是通過另一個VPN(如VPN2)與PE互連。也就是說,CE上流向PE的私網數據的出接口及PE上返回該CE的私網數據流量的出接口都屬于VPN2。
圖3-14 穿越VPN的GRE示意圖
例如圖3-14中,PE1和PE2是一級運營商的MPLS骨干網邊界設備。VPN2是屬于二級運營商的一個VPN。CE1和CE2是屬于用戶的設備。
為了在此網絡環境中部署一個基于MPLS網絡的VPN(如VPN1),可以在PE1和CE1之間搭建一個穿越VPN2的GRE,在邏輯上使CE1與PE1直連。
GRE在ERSPAN網絡中的應用
ERSPAN是一種流量鏡像協議,它允許向一個乃至多個端口或VLAN做流量鏡像。這些流量鏡像將被發送到服務器,用于做流量監控。
如圖3-15所示,交換機A通過IP網絡向交換機B發送流量。同時為做流量監控,交換機A通過ERSPAN將交換機A發給交換機B的流量做出鏡像流量,即發送備份流量到交換機C,這樣,只需將分析或偵聽設備連接至監控端口,即可實現對被監控端口的分析和偵聽。通過建立GRE隧道,ERSPAN允許鏡像報文跨越一個IP網絡,將ERSPAN報文封裝成GRE報文在IP網絡內傳輸到交換機C上。
圖3-15 GRE在ERSPAN網絡中應用的組網圖