【NE探秘】一個報文的路由器之旅-(10)IP組播轉(zhuǎn)發(fā)流程【原創(chuàng)】

嗨，親愛的朋友們，NE探秘系列技術(shù)帖又與您相約了，有沒有很期待？

前面我們跟大家一起學(xué)習(xí)了介紹了IP單播轉(zhuǎn)發(fā)流程和L2橋接轉(zhuǎn)發(fā)流程，相信大家都比較熟悉了吧。本帖我們將給大家詳細介紹IP組播的轉(zhuǎn)發(fā)流程，包括組播基礎(chǔ)知識和轉(zhuǎn)發(fā)流程兩部分。

組播快速入門

?單播、組播和廣播

IP通信有三種典型的方式：

? 第一種是單播（unicast），是在一臺源IP主機和一臺目的IP主機之間進行。網(wǎng)絡(luò)上絕大部分的數(shù)據(jù)都是以單播的形式傳輸?shù)模纾娮余]件收發(fā)、網(wǎng)頁瀏覽、優(yōu)酷/土豆等的視頻點播，都是采用單播實現(xiàn)的。單播屬于一對一（點對點）的通訊方式，同時只有一個發(fā)送者和一個接收者，中間的交換機和路由器對數(shù)據(jù)只進行轉(zhuǎn)發(fā)不進行復(fù)制。

? 第二種是廣播（broadcast），在一臺源IP主機和網(wǎng)絡(luò)中所有其它的IP主機之間進行。廣播屬于一對所有的通訊方式，無路由過程，中間的交換機和路由器對數(shù)據(jù)進行無條件的復(fù)制和轉(zhuǎn)發(fā)，所有主機都可以接收到（不管是否需要）。廣播不僅會將信息發(fā)送給不需要的主機而浪費帶寬，也可能由于路由回環(huán)引起嚴重的廣播風(fēng)暴，所以廣播數(shù)據(jù)被限制在二層交換的局域網(wǎng)范圍內(nèi)，禁止其穿過路由器，防止廣播數(shù)據(jù)影響大面積的主機。但IP網(wǎng)絡(luò)中，廣播也是不可少的，如客戶機通過DHCP自動獲得IP地址的過程，通過ARP請求獲得某IP地址對應(yīng)的MAC地址的過程，都需要使用廣播。

? 第三種是組播（Multicast），在一臺源IP主機和網(wǎng)絡(luò)中多臺（一組）IP主機之間進行。組播是一對多（點對多點）的通訊方式，同時有一個發(fā)送者和多個接收者，中間的交換機和路由器根據(jù)接收者的需要，有選擇性地對數(shù)據(jù)進行復(fù)制和轉(zhuǎn)發(fā)。視頻/音頻會議、網(wǎng)絡(luò)電視、股票行情發(fā)布等，便是采用組播形式。

可能有讀者會有疑問，網(wǎng)頁瀏覽和網(wǎng)絡(luò)視頻點播，雖然不是所有人都想看，但觀看的人數(shù)不少，假設(shè)有1000個人想看同一個網(wǎng)頁/視頻，采用單播，服務(wù)器就得逐一傳送，重復(fù)1000次相同工作，那為什么采用單播不是組播呢？

那是因為，不是所有客戶都是同一時間想看同一內(nèi)容，單播能夠針對每個客戶的及時響應(yīng)；如果采用組播，用戶便有“過了這個村就沒那個點“的煩惱。視頻/音頻會議、股票行情發(fā)布，實時性很高，用戶在同一時間看同一內(nèi)容，就很適合采用組播。

組播對于網(wǎng)絡(luò)而言還是很有魅力的，比如下圖所示場景，一目了然，組播比單播更能節(jié)約網(wǎng)絡(luò)資源，也極大減輕了服務(wù)器的負擔(dān)。

組播分發(fā)樹

上圖右側(cè)所示的網(wǎng)絡(luò)流量轉(zhuǎn)發(fā)路徑，像不像一棵倒長的樹？這棵樹稱為”組播分發(fā)樹“，樹根是服務(wù)器（稱為組播源）；樹葉是客戶端（稱為組播接收者）。只是，組播分發(fā)樹有個特別之處，從根到葉子都是一樣粗，也就是說，網(wǎng)絡(luò)負載不會隨著組播接收者（客戶端）數(shù)量的增加而增加，這就是組播的魅力所在。

那么，IP網(wǎng)絡(luò)是如何將報文從組播源沿著組播分發(fā)樹發(fā)送給眾多接收者呢？如下圖中的Router-X收到組播數(shù)據(jù)后，該如何轉(zhuǎn)發(fā)呢？

按照傳統(tǒng)IP的尋址轉(zhuǎn)發(fā)機制，首先Router-X要到轉(zhuǎn)發(fā)表去匹配目的接收者的地址，找到對應(yīng)的出接口。上圖中，組播的目的地址是組播接收者1、接收者2、……，接收者7；出接口是接口A、接口B。那么，Router-X在轉(zhuǎn)發(fā)組播數(shù)據(jù)時，是拿數(shù)據(jù)包去逐一匹配目的地址（組播接收者1、接收者2、……，接收者7）嗎？這顯然效率太低了。如果組播接收者的數(shù)量非常巨大，尤其是越靠近組播源的節(jié)點，其組播接收者越多。這么大量的組播接收者，如果都在組播轉(zhuǎn)發(fā)表項中都列出來，轉(zhuǎn)發(fā)時逐一去匹配，是不大現(xiàn)實的。為此，誕生了“組播組“這個詞。

組播組

“組播組“用來表示一群組播接收者，即組播接收者的集合。組播組并不代表網(wǎng)絡(luò)上的具體主機，僅僅代表相應(yīng)的接收者組成的集合，只用于組播報文從組播源往接收者方向發(fā)送，是單向的。“組播組”如同電視頻道，組播源如同電視臺。電視臺向某頻道內(nèi)發(fā)送數(shù)據(jù)；觀眾想看該頻道的節(jié)目，就打開電視機切換到該頻道即可。

組播組地址

為了讓組播數(shù)據(jù)在網(wǎng)絡(luò)中能被正確的尋址轉(zhuǎn)發(fā)，需要給“組播組”分配地址。

組播報文在三層（IP）層轉(zhuǎn)發(fā)時，使用的是D類IP地址，即224.0.0.0至239.255.255.255之間的IP地址。協(xié)議規(guī)定，其中的224.0.0.0至224.0.0.255為保留的組播地址，給本地網(wǎng)絡(luò)協(xié)議使用，比如224.0.0.5和224.0.0.6這兩個是OSPF協(xié)議使用的組播地址，路由器對收到的目的地址在此范圍內(nèi)的報文，不管報文的TTL值是多少，都不能進行轉(zhuǎn)發(fā)。

當(dāng)組播報文在以太二層網(wǎng)絡(luò)轉(zhuǎn)發(fā)時，需要用到組播MAC地址。組播MAC地址同單播MAC地址一樣，都是48bit，一般用6字節(jié)的十六進制來表示，如XX-XX-XX-XX-XX。IEEE 802.3規(guī)定，MAC的第0字節(jié)的末位（The last bit of the first byte）用于表示這個地址是組播/廣播地址還是單播地址，如果這一位是0，表示此MAC地址是單播地址，如果這位是1，表示此MAC地址是多播地址或廣播地址。其中，廣播地址只有一個，即FF-FF-FF-FF-FF-FF。到目前為止，大部分組播MAC地址都是以0x01-00-5E開頭，即01-00-5E-XX-XX-XX。

組播轉(zhuǎn)發(fā)表四要素

如下圖，按照傳統(tǒng)IP的尋址轉(zhuǎn)發(fā)機制，Router-X收到組播數(shù)據(jù)，到轉(zhuǎn)發(fā)表去匹配目的接收者的地址，找到對應(yīng)的出接口。根據(jù)前面描述，組播轉(zhuǎn)發(fā)表的目的接收者的地址是“組播組地址”，出接口列表為{出接口A、出接口B}。如果有匹配的組播組地址，則將組播數(shù)據(jù)從出接口A和出接口B發(fā)送。這樣就完美了嗎？

其實不然。組播報文是發(fā)送給一組接收者的，如果轉(zhuǎn)發(fā)了不該轉(zhuǎn)發(fā)的數(shù)據(jù)，造成的影響很大，比如下圖中，正確的組播轉(zhuǎn)發(fā)應(yīng)該是藍色箭頭所示的方向。如果由于某種原因，Router-X把組播數(shù)據(jù)錯發(fā)了一份給RouterY（入紅色箭頭標識的流量），那么就會多出好多流量，浪費大量網(wǎng)絡(luò)資源。如果存在路由環(huán)路，影響則更大。

為了能確保正確發(fā)送組播數(shù)據(jù)，組播必須嚴格沿著組播分發(fā)樹轉(zhuǎn)發(fā)，即，沿著遠離組播源的方向進行轉(zhuǎn)發(fā)。為了做到這點，組播技術(shù)引入了RPF（Reverse Path Forwarding，逆向路徑轉(zhuǎn)發(fā)）檢查機制，路由器轉(zhuǎn)發(fā)組播數(shù)據(jù)時，執(zhí)行RPF檢查，確保組播數(shù)據(jù)流能夠沿組播轉(zhuǎn)發(fā)樹正確的傳輸，同時可以避免轉(zhuǎn)發(fā)路徑上環(huán)路的產(chǎn)生。RPF檢查的過程是：在接收到報文后，在單播轉(zhuǎn)發(fā)表中，查找到組播源地址的路由，如果該路由的出接口就是報文的入接口，則檢查通過，否則不通過。也就是說，組播轉(zhuǎn)發(fā)時，不僅要關(guān)心數(shù)據(jù)要到哪里去，還要關(guān)心它從哪里來。

但在實際組播數(shù)據(jù)轉(zhuǎn)發(fā)過程中，如果對每一份接收到的組播數(shù)據(jù)報文都通過查找單播路由表進行RPF檢查，會給路由器帶來很大負擔(dān)。因此，URPF檢查應(yīng)該放在轉(zhuǎn)發(fā)表項生成之前進行，也就是路由器在生成路由表的過程中進行URPF檢查，得到“組播源”及“到組播源的接口”，并將這兩個信息也放入轉(zhuǎn)發(fā)表項。這樣，在轉(zhuǎn)發(fā)組播報文時，匹配組播報文的源地址是否為轉(zhuǎn)發(fā)表的“組播源”，報文的目的地址是否為轉(zhuǎn)發(fā)表的“組播組地址”，如果匹配上，則判斷接收報文的入接口是否就是“到組播源的接口”，如果是，表面數(shù)據(jù)是安全無誤的，可以轉(zhuǎn)發(fā)，如果接收報文的入接口不是“到組播源的接口”，則丟棄報文。

所以，組播轉(zhuǎn)發(fā)表有四要素：“組播源”、“組播組”、“到組播源的接口”、“出接口列表”，其中組播源和組播組作為匹配對象，是個組合，通常表示為（S,G）。其中，S是Source首字母，表示組播源；G是Group的首字母，表示組播組。如下圖的Router-X的組播轉(zhuǎn)發(fā)表項為：（10.1.1.1, 255.1.1.1）, GE1/0/0, {GE2/0/0, GE3/0/0}。

IP組播轉(zhuǎn)發(fā)流程

IP組播轉(zhuǎn)發(fā)流程如下圖所示。需要關(guān)注的地方在于查表轉(zhuǎn)發(fā)環(huán)節(jié)（其他環(huán)節(jié)在本系列的前1~7帖中已描述，不再贅述）。

查表轉(zhuǎn)發(fā)流程：

步驟1 判斷報文的目的MAC是否為組播MAC，如果不是，則做單播轉(zhuǎn)發(fā)；是則繼續(xù)下一步驟。

步驟2 判斷報文的協(xié)議類型是否為IP，如果不是，則進入其他轉(zhuǎn)發(fā)流程；是則繼續(xù)下一步驟。

步驟3 檢查報文的長度、IP地址、Checksum字段是否正確，如果不正確，則丟棄報文，否則繼續(xù)下一步驟。

步驟4 判斷是否為組播IP地址，如果不是組播則丟棄報文，是則進入繼續(xù)下一步驟。

步驟5 檢查入接口是否使能IP組播，如果不是則丟棄報文，是則繼續(xù)下一步驟。

步驟6 在組播FIB（MFIB）表（如果是公網(wǎng)的報文，查公網(wǎng)MFIB表，如果是VPN報文，則查對應(yīng)VPN的MFIB表）查找是否存在匹配的（S，G）表項：

? 如果存在匹配的（S，G）表項，并且接收該報文的接口與轉(zhuǎn)發(fā)表項的入接口一致，則繼續(xù)步驟7的處理。特殊地，對于Register狀態(tài)的出接口，表明本設(shè)備為源DR但還沒收到RP的Register-Stop消息，這時需要將收到的組播上送CPU（的組播協(xié)議模塊），將組播報文封裝在注冊消息發(fā)送給RP。

? 如果存在匹配的（S，G）表項，但入接口不一致，將報文上送CPU處理。CPU進行RPF檢查：對照單播路由表，若到組播源的接口與(S,G)表項的入接口一致，則說明（S，G）表項正確，報文來源路徑錯誤，將報文丟棄；否則說明（S，G）表項已過時，于是根據(jù)單播路由表更新（S，G）表項中的入接口，并刷新轉(zhuǎn)發(fā)表。然后再檢查收到報文的接口是否就是更新后的接口，是則繼續(xù)步驟7的處理，否則將其丟棄。

? 如果不存在匹配的（S，G）表項，有兩種場景：

一種場景是本路由器是源DR，收到組播源發(fā)送的第1個組播報文，此時還沒有（S,G）表項，需要將報文上送CPU處理，將報文封裝成Register消息發(fā)給RP，同時CPU下發(fā)出接口為空的（S,G）表項，等收到RP的注冊報文再添加出接口。如果注冊失敗，則為了減少上報對CPU的負擔(dān)，后續(xù)的組播數(shù)據(jù)流就會進行轉(zhuǎn)發(fā)，但是因（S,G）表項出接口為空，實際上是把報文丟棄了。

另一種場景是組播組的第1個報文從RP向接收者方向發(fā)送時，由于共享樹上（除RP外）的路由器只有（*，G）表項，沒有(S,G)表項，此時收到的組播報文也上送CPU處理，CPU生成(S,G)表項，其出接口列表從（*，G）表項拷貝。接著CPU對報文進行RPF檢查，如果檢查失敗則丟棄報文，否則繼續(xù)步驟7的處理。

步驟7 檢查匹配的（S,G）表項是否有對應(yīng)的組成員，即檢查對應(yīng)的出接口列表是否為空，如果為空，則報文丟棄；，否則繼續(xù)下一步驟。

步驟8 檢查報文的入接口與（S,G）表項的入接口是否一致，如果不一致則丟棄報文，否則繼續(xù)下一步驟。

步驟9 進行組播復(fù)制等后續(xù)處理，如上行TM進行板間組播復(fù)制，下行TM進行板內(nèi)組播復(fù)制。詳細處理過程在本系列的前1~7帖中已描述，不再贅述，如您遺忘了，快戳下方的鏈接復(fù)習(xí)一下吧：）

本系列漫談一個報文的路由器之旅，您將看到：

0、開篇引言（轉(zhuǎn)發(fā)全景圖）（點擊可打開鏈接）

1、交換與尋址轉(zhuǎn)發(fā)（點擊可打開鏈接）

2、報文收發(fā)、解析與封裝（點擊可打開鏈接）

3、流量控制（反壓、隊列、限速） （點擊可打開鏈接）

4、QoS基礎(chǔ)（上篇） （點擊可打開鏈接）

5、QoS基礎(chǔ)（下篇） （點擊可打開鏈接）

6、QoS處理流程 （點擊可打開鏈接）

7、轉(zhuǎn)發(fā)層面的其他處理（組播復(fù)制、NAT、包過濾、策略路由等）（點擊可打開鏈接）

8、協(xié)議報文之旅（點擊可打開鏈接）

9、IP單播轉(zhuǎn)發(fā)流程（點擊可打開鏈接）

10、L2橋接轉(zhuǎn)發(fā)流程（點擊可打開鏈接）

11、IP組播轉(zhuǎn)發(fā)流程（本貼）

12、MPLS轉(zhuǎn)發(fā)流程

迫不及待想看到全部的技術(shù)帖么？莫急莫急，猛戳閱讀原文，開啟您個人的路由器探秘之旅吧！

常見的各品牌路由器默認IP地址匯總清單

在實際生活中，人們難免會遇到需要對路由器進行一番配置，但又不知道設(shè)備的默認IP地址的情況。如果是自家的路由器，大不了硬重置（長按reset鍵）；但如果是別人的，恰巧他們又不知道該如何重新設(shè)定各種賬號密碼或參數(shù)，問題就比較大條了。為了化解這種尷尬，感興趣的網(wǎng)友可以先行預(yù)習(xí)下各品牌的默認管理IP（不然就老實去翻看設(shè)備底部的標簽吧）。

通常情況下，設(shè)備的底部都會貼上一張顯示本地局域網(wǎng)管理IP（比如192.168.1.1）的標簽，但如果設(shè)備放在難以觸及的地方、或者銘牌字跡模糊甚至丟失的話，大家不妨從“ipconfig”命令著手。

默認網(wǎng)關(guān)（Default Gateway）即上層路由的IP地址。

在包括Windows在內(nèi)的系統(tǒng)中，均支持在終端上運行“ipconfig”命令。（當(dāng)然，如果有耐心的話，你也可以只通過鼠標，一步步地點擊到網(wǎng)絡(luò)連接中查看當(dāng)前參數(shù)）。

下面是各常見品牌路由器的默認IP清單：

如果您使用的設(shè)備品牌不在上述列表中，也可以試著訪問下RouterIPAddress.com或SetupRouter.com。

如果還不小心忘記了設(shè)備的默認賬號與登錄密碼，也不妨去RouterPasswords.com或PortForward.com試下運氣。

當(dāng)然，在完成設(shè)置之后，我們還是建議你修改掉默認的賬號或管理密碼，以免因某些漏洞而被黑客攻擊利用。


【NE探秘】一個報文的路由器之旅-(8)IP單播轉(zhuǎn)發(fā)流程【原創(chuàng)】

嗨，親愛的朋友們，NE探秘系列技術(shù)帖又與您相約了，有沒有很期待？

本系列的前1~7帖介紹了一個報文在轉(zhuǎn)發(fā)層面的處理流程，該流程中最重要的處理就是轉(zhuǎn)發(fā)流程。不同業(yè)務(wù)有不同的轉(zhuǎn)發(fā)流程，本系列后面幾帖將分別介紹各類業(yè)務(wù)的轉(zhuǎn)發(fā)流程，本帖介紹IP單播的轉(zhuǎn)發(fā)流程，包括IPv4單播和IPv6單播。

一個報文的路由器之旅

——（8）IP單播轉(zhuǎn)發(fā)流程

IP單播轉(zhuǎn)發(fā)流程

端到端的IPv4單播轉(zhuǎn)發(fā)過程

以大家熟悉的以太幀為例，先來回顧下IP單播端到端的轉(zhuǎn)發(fā)流程。

下圖是個最簡單的IP轉(zhuǎn)發(fā)場景，某局域網(wǎng)的主機A發(fā)送報文給另一局域網(wǎng)的主機B，中間經(jīng)過一臺路由器，那么這臺路由器就是PC-A的網(wǎng)關(guān)。

由主機PC-A向主機PC-B發(fā)送IP報文，那么該報文的目的IP地址就是PC-B的IP地址，源IP地址就是主機PC-A的IP地址，目標MAC地址就是其網(wǎng)關(guān)路由器Port1的MAC地址，源MAC地址就是PC-A的MAC地址。

路由器轉(zhuǎn)發(fā)過程：

1、路由器收到這個報文，發(fā)現(xiàn)其目的MAC為本機Port1端口的，表明需要本機來進行進一步解析（如果目的MAC不是本機，表明直接進行二層轉(zhuǎn)發(fā)，不需要再解析幀的其他內(nèi)容了）；

2、路由器進一步解析報文，得知該幀所承載的協(xié)議類型為IPv4（協(xié)議類型值=0x800），即需要進行IPv4轉(zhuǎn)發(fā)；

3、查IP轉(zhuǎn)發(fā)表（FIB表），得知該報文并不是發(fā)給自己的，而是需要送往出端口Port2，因此，路由器不再繼續(xù)分析IP頭后面的內(nèi)容。

4、路由器將目的MAC更換成PC-B的MAC，將源MAC更換為出接口Port2的MAC，并將報文從Port2發(fā)送出去。

路由器的IPv4轉(zhuǎn)發(fā)全流程

IPv4轉(zhuǎn)發(fā)全流程如下圖所示。需要關(guān)注的地方在于查表轉(zhuǎn)發(fā)和獲取封裝信息兩個環(huán)節(jié)（其他環(huán)節(jié)在本系列的前1~6貼中已描述，不再贅述）。

1）查表轉(zhuǎn)發(fā)詳細流程

流程說明：

步驟1、判斷報文的目的MAC是否等于本機MAC，如果不是，則做L2轉(zhuǎn)發(fā)；是則繼續(xù)下一步驟。

步驟2、判斷報文的協(xié)議類型是否為IPv4（例如以太幀，eth_type = 0x800），如果不是，則進入其他轉(zhuǎn)發(fā)流程；是則繼續(xù)下一步驟。

步驟3、檢查報文的長度、IP地址、Checksum字段是否正確，如果不正確，則丟棄報文，否則繼續(xù)下一步驟。

步驟4、判斷目的IP地址是否為單播地址，如果不是單播則其他轉(zhuǎn)發(fā)處理，是則進入繼續(xù)下一步驟。

步驟5、用目的IP地址查FIB表得到的下一跳IP、出接口等信息（如果是公網(wǎng)的報文，查公網(wǎng)FIB表，如果是VPN報文，則查對應(yīng)VPN的FIB表）。

如果是負載分擔(dān)，會查到多份這樣的信息，于是根據(jù)負載分擔(dān)哈希算法選取其中的一份。

如果是FRR（FastReroute）狀態(tài)，則會根據(jù)出接口狀態(tài)做主備路由選擇，如果出接口正常工作，則會選擇主路由；否則選擇FRR備份路由。

如果出接口為Trunk接口，會再根據(jù)Trunk負載分擔(dān)哈希算法，選擇Trunk成員口中的其中一個作為最終的出接口。

步驟6、如果使能了URPF檢查，則用源IP地址查FIB表，如果命中，對于松散的URPF檢查只要出接口為真實的外部接口則檢查通過（對于出接口為CPU、NULL接口、TE接口、IPv4 Tunnel接口則松散的URPF檢查不通過）；對應(yīng)嚴格的URPF檢查，用報文的入端口信息與源IP地址查FIB表得到的出口信息進行比較，相等則通過，不等則丟棄（對于入接口為VLAN子接口，出接口為入端口信息，同時出接口VLANID也要等于入口的VLANID，則檢查才會通過）。

說明：

URPF（Unicast Reverse Path Forwarding），是一種單播逆向路由查找技術(shù)，用來預(yù)防偽造源地址攻擊的手段。之所以稱為逆向，是針對正常的路由查找而言的。一般情況下路由器接收到報文，獲取報文的目的地址，針對目的地址查找路由。如果找到了進行正常的轉(zhuǎn)發(fā)，否則丟棄該報文。

URPF的實現(xiàn)原理：通過獲取報文的源地址和入接口，以源地址為目的地址，在轉(zhuǎn)發(fā)表中查找源地址對應(yīng)的接口是否與入接口匹配。如果不匹配認為源地址是偽裝的，丟棄該報文。通過這種方式，能有效地防范網(wǎng)絡(luò)中通過修改源地址而進行的惡意攻擊行為的發(fā)生。

然而，有的場景（例如負載分擔(dān)）同一目的地址在路由表中存在有多條路由表項，同一目的IP地址的報文發(fā)送的接口不唯一，即非對稱路由。此時若應(yīng)用URPF時，報文會異常丟棄。因此，URPF出現(xiàn)了嚴格模式和松散模式。嚴格模式要求接口匹配；而松散模式，不檢查接口是否匹配，只要路由表項中存在針對源地址的路由，數(shù)據(jù)報文就通過URPF檢查。

步驟7、如果目的IP為非本機IP，則報文頭的TTL減1，并重新計算并修改Checksum值，繼續(xù)執(zhí)行后續(xù)的CAR等公共處理。如果目的IP為本機（查表發(fā)現(xiàn)下一跳為127.0.0.1），則直接送入上行TM部件。

之后的處理中，交換網(wǎng)根據(jù)出接口信息（出接口信息包含了目的單板和目的出接口）信息將報文發(fā)送到正確的下行單板。

2）獲取封裝信息

到了下行，下行包轉(zhuǎn)發(fā)引擎PFE用下一跳IP或目的IP和VLANID查ARP表項，獲取目的MAC信息，根據(jù)出接口信息查出接口表項獲取端口MAC。因為，路由器需要將報文的目的MAC更換成下一跳設(shè)備的MAC，將源MAC更換成自己出接口的MAC。

如果查ARP表項沒有命中，則啟動ARP學(xué)習(xí)功能，過程如下：

1） 發(fā)送ARP請求報文，此報文的目的MAC為廣播地址，目的地址為下一跳IP，源IP為自己的IP。

2）由于是MAC廣播報文，在局域網(wǎng)內(nèi)的設(shè)備或主機都能收到，因此下一跳設(shè)備也能收到。于是下一跳設(shè)備解析報文發(fā)現(xiàn)目的IP為自己，便發(fā)送ARP回應(yīng)報文，里面攜帶了自己的MAC地址。

3）路由器收到回應(yīng)報文，得到下一跳的MAC地址，添加到ARP表項中。

通過ARP學(xué)習(xí)后，重新查ARP表項獲取下一跳MAC信息，便可繼續(xù)后續(xù)的處理。

3）出口檢查和封裝

對于目的IP為本機的，在出口處理模塊處上送到接口板CPU，再上送給主控板CPU。

對于目的地址非本機的，則在出接口處理模塊時，根據(jù)需要進行MTU檢查。如果報文長度不超過MTU，則將報文發(fā)送給接口卡。接口卡用待發(fā)送的數(shù)據(jù)幀內(nèi)容計算幀檢驗序列FCS，然后對數(shù)據(jù)幀加封裝幀間隙、前導(dǎo)碼、幀開始界定符和FCS，并將數(shù)據(jù)幀轉(zhuǎn)換成光/電信號，再發(fā)送到出接口線路上。

如果報文長度超過MTU，則判斷報文頭DF位，如果DF位置0，則分片后再發(fā)送給接口卡；若DF置1，表示報文源端不允許該報文分片，所以將報文做CP-CAR檢查后上送接口板CPU，再上送主控板CPU，以便回應(yīng)ICMP Too-Big消息給源端。

IPv6單播轉(zhuǎn)發(fā)流程

IPv6轉(zhuǎn)發(fā)流程與IPv4基本相同，不同點在于：

- 所查的表項不同，IPv4查FIBv4表，而IPv6查的是FIBv6表；IPv4查ARP表，而IPv6則是查鄰居表。

- IPv6 MTU檢查時，超過接口IPv6 MTU時不進行分片，而是上送CPU并返回ICMPv6 Too-big消息給源端（這符合IPv6協(xié)議標準）。

本系列漫談一個報文的路由器之旅，您將看到：

0、開篇引言（轉(zhuǎn)發(fā)全景圖）（點擊可打開鏈接）

1、交換與尋址轉(zhuǎn)發(fā)（點擊可打開鏈接）

2、報文收發(fā)、解析與封裝（點擊可打開鏈接）

3、流量控制（反壓、隊列、限速）（點擊可打開鏈接）

4、QoS基礎(chǔ)（上篇）（點擊可打開鏈接）

5、QoS基礎(chǔ)（下篇）（點擊可打開鏈接）

6、QoS處理流程（點擊可打開鏈接）

7、轉(zhuǎn)發(fā)層面的其他處理（組播復(fù)制、NAT、包過濾、策略路由等）（點擊可打開鏈接）

8、協(xié)議報文之旅（點擊可打開鏈接）

9、IP單播轉(zhuǎn)發(fā)流程（本帖）

10、L2橋接轉(zhuǎn)發(fā)流程

11、IP組播轉(zhuǎn)發(fā)流程

12、MPLS轉(zhuǎn)發(fā)流程

迫不及待想看到全部的技術(shù)帖么？莫急莫急，猛戳閱讀原文，開啟您個人的路由器探秘之旅吧！

兩個路由器ip地址沖突怎么解決？

問：兩個路由器IP地址沖突怎么解決？家里路由器A、路由器B兩個無線路由器，路由器A連接寬帶能夠正常上網(wǎng)，把路由器B連接到路由器A上，總是提示IP地址沖突，請問這個問題應(yīng)該怎么解決。

答：兩個路由器連接上網(wǎng)時，由于2個路由器的IP地址都是：192.168.1.1，這時候就會存在IP地址沖突的問題。解決辦法就是修改路由器B的IP地址的，如何路由器B的IP地址？和路由器A、B之間的連接有關(guān)系的，下面進行詳細的介紹。一、路由器A的LAN連接路由器B的WAN

如果是路由器A的LAN口（1、2、3、4）連接路由器B的WAN口，這時候路由器B的IP地址要修改為與路由器A的不在同一個網(wǎng)段。有用戶反映不明白，路由器B與路由器A的IP地址不在同一個網(wǎng)段是什么意思，下面舉例進行說明。

路由器A的LAN連接路由器B的WAN

如果路由器A的IP地址是：192.168.1.1或者192.168.0.1，那么路由器B的IP地址可以修改為：192.168.2.1，192.168.3.1，192.168.4.1，192.168.5.1等等。

修改方法：

在路由器B的設(shè)置界面，點擊“網(wǎng)絡(luò)參數(shù)”——>“LAN口設(shè)置”——>“IP地址”修改為：192.168.2.1——>點擊“保存”，之后會提示重啟路由器。

路由器B的IP地址修改為：192.168.2.1

溫馨提示：路由器B重啟之后，需要在瀏覽器中輸入修改后的IP（本例是：192.168.2.1）重新登錄到路由器B的設(shè)置界面的。二、路由器A的LAN連接路由器B的LAN

如果路由器A的LAN（1、2、3、4）口連接路由器B的LAN（1、2、3、4）口，這時候需要是路由器B的IP地址，與路由器A的IP地址在同一個網(wǎng)段，下面舉例說明。

路由器A的LAN連接路由器B的LAN

（1）、如果路由器A的IP地址是：192.168.1.1，則路由器B的IP地址可以修改為：192.168.1.2，192.168.1.3，192.168.1.4，192.168.1.5，最大可以修改為：192.168.1.254。

（2）、如果路由器A的IP地址是：192.168.0.1，則路由器B的IP地址可以修改為：192.168.0.2，192.168.0.3，192.168.0.4，192.168.0.5，最大可以修改為：192.168.0.254。

總結(jié)：也就是路由器A與路由器BIP地址的前3段要保持一致，最后一段不一樣。

修改方法

在路由器B的設(shè)置界面，點擊“網(wǎng)絡(luò)參數(shù)”——>“LAN口設(shè)置”——>“IP地址”修改為：192.168.1.200——>點擊“保存”，之后會提示重啟路由器。

路由器B的IP地址修改為：192.168.1.200

溫馨提示：路由器B重啟之后，需要在瀏覽器中輸入修改后的IP（本例是：192.168.1.200）重新登錄到路由器B的設(shè)置界面的。

以上就是兩個路由器IP地址沖突的解決辦法，大家應(yīng)該先確定路由器A和路由器B之間的連接，然后在修改一下路由器B的IP地址即可。

在修改路由器B的IP地址的時候需要注意，路由器A的LAN連接路由器B的WAN時，路由器B的IP地址修改為與路由器A的IP地址不在同一個網(wǎng)段。路由器A的LAN連接路由器B的LAN時，路由器B的IP地址要修改為與路由器A的IP地址在同一個網(wǎng)段。

新手必看！快速知道自己路由的IP地址

我們在對無線路由器進行設(shè)置時，通過瀏覽器訪問它的后臺，就需要用戶輸入一個路由器的IP地址。但是，每個路由器的IP地址并不是相同的，目前還沒有統(tǒng)一的路由器IP地址。往往對于新手來說，找到這一地址是一件很困難的事兒。其實，無線路由器的IP地址通過電腦很容易被發(fā)現(xiàn)，我們這就教給大家兩招，幫助網(wǎng)絡(luò)新手快速找到無線路由器的IP地址。

方法一：命令提示符

首先，我們按住鍵盤上的“Windows”鍵(一般在ctrl和alt之間)再按R鍵，就會出來“運行”窗口。在運行窗口中，輸入“cmd'”，然后點擊確定就會打開“命令提示符”。打開命令提示符以后，我們繼續(xù)使用鍵盤輸入“ipconfig”，按下回車，就會看到命令提示符中閃現(xiàn)出了一片信息。我們在這些信息中找到“默認網(wǎng)關(guān)”那一欄，這里顯示的就是無線路由器的IP地址。

方法二：網(wǎng)絡(luò)和共享中心

如果看著輸入這些指令有點兒“頭暈”的感覺，我們還可以在“網(wǎng)絡(luò)和共享中心”中找到無線路慪氣的IP地址。在開始操作之前，請用戶確認目前電腦已經(jīng)通過無線或者有線連接到無線路由器。第一步，先在桌面右下角的系統(tǒng)托盤中，單機聯(lián)網(wǎng)的圖標，然后在最下方打開“網(wǎng)絡(luò)和共享中心”。打開后，我們找到“本地連接”這一欄信息，單機“本地連接”打開。

“本地連接狀態(tài)”信息就會呈現(xiàn)在大家眼前，下一步我們點擊“詳細信息”。“詳細信息”界面將可以看到所有關(guān)于自己網(wǎng)絡(luò)的細節(jié)，無線路由器的IP地址同樣存在于“默認網(wǎng)關(guān)”的那一欄文字中。這樣一來，我們就能夠知道自己家中無線路由器的IP地址啦!不過，需要提醒大家的是，路由器IP地址必須自己記錄下來，并不支持復(fù)制功能。


網(wǎng)絡(luò)小錦囊|如何設(shè)置路由器的IP地址（以TP-Link為例） 1

登錄路由器，在瀏覽器中輸入路由器的LAN口的IP地址，在彈出的對話框中填寫路由器的管理用戶名和密碼后進入管理頁面。

若路由器為默認設(shè)置，則其管理地址為192.168.1.1，用戶名與密碼均為admin（可以在路由器背后的說明上面找到）

2

登陸路由器成功以后， 在左邊框中選擇“網(wǎng)絡(luò)參數(shù)”→“WAN口設(shè)置”，然后在右邊框中的“WAN口連接類型”選擇“PPPoE”。“上網(wǎng)賬號”和“上網(wǎng)口令”中填入寬帶賬戶的用戶名和密碼。

未完待續(xù)

運營商發(fā)行的大量路由器包含高危漏洞，大部分“問題路由器”IP位于中國

微信號：freebuf

據(jù)統(tǒng)計，全球的運營商向大眾網(wǎng)民發(fā)行了至少70萬臺ADSL路由器，但不幸的是，這些路由器存在高危漏洞，進而很可能會造成大規(guī)模路由器攻擊活動。值得一提的是，大多數(shù)的“問題路由器”IP地址都位于中國。

多項安全漏洞

知名安全研究員Kyle Lovett幾個月前在多不同廠商的ADSL路由器中發(fā)現(xiàn)了安全漏洞。然而，這些路由器的制造或發(fā)行公司竟然一樣——運營商。

這些路由器中的大部分都包含目錄遍歷漏洞，這些路由器存在一個webproc.cgi組件，黑客利用該組件可以竊取受害用戶的重要數(shù)據(jù)。可以肯定的是這些投入使用的路由器的數(shù)量非常龐大，并且未來受害用戶將更多。當(dāng)然，這些“問題路由器”從2011年就開始發(fā)行了。

這些設(shè)備和路由器賣給不同國家的成千上萬個互聯(lián)網(wǎng)用戶。有關(guān)這些路由器最糟糕的事情是，大多數(shù)這些路由器中都包含一個config.xml文件，攻擊者完全可以利用路由器中的組件取得其控制權(quán)。config.xml里面包含了路由器的所有配置信息，包括管理員連接網(wǎng)絡(luò)所需的密碼，以及其他類似ISP連接用戶名和密碼賬戶，并包含客戶端和服務(wù)器的TR-069憑證。

這些路由器使用的算法非常弱，正是這一點使得攻擊者可以輕易拿到絕對控制權(quán)。拿到控制器后，攻擊者做的第一件事就是以管理員身份登錄，并修改路由器設(shè)置。所以，針對這種情況，DNS劫持攻擊將會是攻擊者最常用的方式之一。

所有路由器中存在的漏洞并非一樣。60%的路由器都存在一個隱藏的服務(wù)賬號，而且該帳號還使用了弱密碼。另外，其他一些路由器中則存在后門、活動內(nèi)存快照漏洞（內(nèi)存中可能包含一些重要信息，包括私人數(shù)據(jù)）等。

安全研究人員Lovett借助設(shè)備漏洞搜索引擎SHODAN發(fā)現(xiàn)了2500萬的SOHO設(shè)備存在漏洞（或已被入侵），而其中大多數(shù)的IP地址都位于中國。

參考來源securityaffairs，有適當(dāng)修改，轉(zhuǎn)載請注明來自FreeBuf黑客與極客（FreeBuf.COM

QQ空間的小伙伴請在微信搜索“齊賽科技網(wǎng)”加關(guān)注哦~今天，網(wǎng)絡(luò)已經(jīng)成為我們?nèi)粘Ｉ钪斜夭豢缮俚幕A(chǔ)元素之一，因此當(dāng)網(wǎng)絡(luò)出現(xiàn)故障時，我們希望第一時間解決這些故障，而登錄路由器的Web管理界面正是解決問題較為有效的方法之一。不過大多數(shù)用戶通常記不住路由器的Web管理地址（相信該地址大多數(shù)用戶都不會修改，因此通常就是路由器出廠時的默認IP地址），總是從192.168.X.X來不斷嘗試，以求猜中。

其實想查看路由器的IP地址信息很簡單，借助Windows系統(tǒng)的命令提示符即可找到——在命令提示符窗口中輸入ipconfig，在顯示的信息中，默認網(wǎng)關(guān)的地址通常就是路由器的Web管理地址。通過ipconfig查詢路由器IP地址

當(dāng)然，如果你的網(wǎng)絡(luò)已經(jīng)斷開（你的終端無法與路由器ping通，或者路由器的DHCP已經(jīng)關(guān)閉），那么你就需要查詢路由器的默認IP地址，然后為終端設(shè)備手工配置同網(wǎng)段的IP地址。那么如何查詢路由器的默認IP地址呢？通常隨機附帶的說明書上會有，但相信大多數(shù)用戶的路由器說明書早已找不到了，因此我們特別為大家匯總了一些常見路由器的默認IP地址，希望可以幫助大家快速解決網(wǎng)絡(luò)故障。(內(nèi)容比較多，建議大家保存圖片之后再瀏覽）

一些常見路由器的默認IP地址

下圖是個最簡單的IP轉(zhuǎn)發(fā)場景，某局域網(wǎng)的主機A發(fā)送報文給另一局域網(wǎng)的主機B，中間經(jīng)過一臺路由器，那么這臺路由器就是PC-A的網(wǎng)關(guān)。

由主機PC-A向主機PC-B發(fā)送IP報文，那么該報文的目的IP地址就是PC-B的IP地址，源IP地址就是主機PC-A的IP地址，目標MAC地址就是其網(wǎng)關(guān)路由器Port1的MAC地址，源MAC地址就是PC-A的MAC地址。

路由器轉(zhuǎn)發(fā)過程：

1、路由器收到這個報文，發(fā)現(xiàn)其目的MAC為本機Port1端口的，表明需要本機來進行進一步解析（如果目的MAC不是本機，表明直接進行二層轉(zhuǎn)發(fā)，不需要再解析幀的其他內(nèi)容了）；

2、路由器進一步解析報文，得知該幀所承載的協(xié)議類型為IPv4（協(xié)議類型值=0x800），即需要進行IPv4轉(zhuǎn)發(fā)；

3、查IP轉(zhuǎn)發(fā)表（FIB表），得知該報文并不是發(fā)給自己的，而是需要送往出端口Port2，因此，路由器不再繼續(xù)分析IP頭后面的內(nèi)容。

4、路由器將目的MAC更換成PC-B的MAC，將源MAC更換為出接口Port2的MAC，并將報文從Port2發(fā)送出去。

路由器的IPv4轉(zhuǎn)發(fā)全流程

IPv4轉(zhuǎn)發(fā)全流程如下圖所示。需要關(guān)注的地方在于查表轉(zhuǎn)發(fā)和獲取封裝信息兩個環(huán)節(jié)（其他環(huán)節(jié)在本系列的前1~6貼中已描述，不再贅述）。

（1）查表轉(zhuǎn)發(fā)詳細流程

流程說明：

步驟1：判斷報文的目的MAC是否等于本機MAC，如果不是，則做L2轉(zhuǎn)發(fā)；是則繼續(xù)下一步驟。

步驟2：判斷報文的協(xié)議類型是否為IPv4（例如以太幀，eth_type = 0x800），如果不是，則進入其他轉(zhuǎn)發(fā)流程；是則繼續(xù)下一步驟。

步驟3：檢查報文的長度、IP地址、Checksum字段是否正確，如果不正確，則丟棄報文，否則繼續(xù)下一步驟。

步驟4：判斷目的IP地址是否為單播地址，如果不是單播則其他轉(zhuǎn)發(fā)處理，是則進入繼續(xù)下一步驟。

步驟5：用目的IP地址查FIB表得到的下一跳IP、出接口等信息（如果是公網(wǎng)的報文，查公網(wǎng)FIB表，如果是VPN報文，則查對應(yīng)VPN的FIB表）。

如果是負載分擔(dān)，會查到多份這樣的信息，于是根據(jù)負載分擔(dān)哈希算法選取其中的一份。

如果是FRR（FastReroute）狀態(tài)，則會根據(jù)出接口狀態(tài)做主備路由選擇，如果出接口正常工作，則會選擇主路由；否則選擇FRR備份路由。

如果出接口為Trunk接口，會再根據(jù)Trunk負載分擔(dān)哈希算法，選擇Trunk成員口中的其中一個作為最終的出接口。

步驟6：如果使能了URPF檢查，則用源IP地址查FIB表，如果命中，對于松散的URPF檢查只要出接口為真實的外部接口則檢查通過（對于出接口為CPU、NULL接口、TE接口、IPv4 Tunnel接口則松散的URPF檢查不通過）；對應(yīng)嚴格的URPF檢查，用報文的入端口信息與源IP地址查FIB表得到的出口信息進行比較，相等則通過，不等則丟棄（對于入接口為VLAN子接口，出接口為入端口信息，同時出接口VLANID也要等于入口的VLANID，則檢查才會通過）。

?說明：

URPF（Unicast Reverse Path Forwarding），是一種單播逆向路由查找技術(shù)，用來預(yù)防偽造源地址攻擊的手段。之所以稱為逆向，是針對正常的路由查找而言的。一般情況下路由器接收到報文，獲取報文的目的地址，針對目的地址查找路由。如果找到了進行正常的轉(zhuǎn)發(fā)，否則丟棄該報文。

URPF的實現(xiàn)原理：通過獲取報文的源地址和入接口，以源地址為目的地址，在轉(zhuǎn)發(fā)表中查找源地址對應(yīng)的接口是否與入接口匹配。如果不匹配認為源地址是偽裝的，丟棄該報文。通過這種方式，能有效地防范網(wǎng)絡(luò)中通過修改源地址而進行的惡意攻擊行為的發(fā)生。

然而，有的場景（例如負載分擔(dān)）同一目的地址在路由表中存在有多條路由表項，同一目的IP地址的報文發(fā)送的接口不唯一，即非對稱路由。此時若應(yīng)用URPF時，報文會異常丟棄。因此，URPF出現(xiàn)了嚴格模式和松散模式。嚴格模式要求接口匹配；而松散模式，不檢查接口是否匹配，只要路由表項中存在針對源地址的路由，數(shù)據(jù)報文就通過URPF檢查。

步驟7：如果目的IP為非本機IP，則報文頭的TTL減1，并重新計算并修改Checksum值，繼續(xù)執(zhí)行后續(xù)的CAR等公共處理。如果目的IP為本機（查表發(fā)現(xiàn)下一跳為127.0.0.1），則直接送入上行TM部件。

之后的處理中，交換網(wǎng)根據(jù)出接口信息（出接口信息包含了目的單板和目的出接口）信息將報文發(fā)送到正確的下行單板。

（2）獲取封裝信息

到了下行，下行包轉(zhuǎn)發(fā)引擎PFE用下一跳IP或目的IP和VLANID查ARP表項，獲取目的MAC信息，根據(jù)出接口信息查出接口表項獲取端口MAC。因為，路由器需要將報文的目的MAC更換成下一跳設(shè)備的MAC，將源MAC更換成自己出接口的MAC。

如果查ARP表項沒有命中，則啟動ARP學(xué)習(xí)功能，過程如下：

1） 發(fā)送ARP請求報文，此報文的目的MAC為廣播地址，目的地址為下一跳IP，源IP為自己的IP。

2）由于是MAC廣播報文，在局域網(wǎng)內(nèi)的設(shè)備或主機都能收到，因此下一跳設(shè)備也能收到。于是下一跳設(shè)備解析報文發(fā)現(xiàn)目的IP為自己，便發(fā)送ARP回應(yīng)報文，里面攜帶了自己的MAC地址。

3）路由器收到回應(yīng)報文，得到下一跳的MAC地址，添加到ARP表項中。

通過ARP學(xué)習(xí)后，重新查ARP表項獲取下一跳MAC信息，便可繼續(xù)后續(xù)的處理。

（3）出口檢查和封裝

對于目的IP為本機的，在出口處理模塊處上送到接口板CPU，再上送給主控板CPU。

對于目的地址非本機的，則在出接口處理模塊時，根據(jù)需要進行MTU檢查。如果報文長度不超過MTU，則將報文發(fā)送給接口卡。接口卡用待發(fā)送的數(shù)據(jù)幀內(nèi)容計算幀檢驗序列FCS，然后對數(shù)據(jù)幀加封裝幀間隙、前導(dǎo)碼、幀開始界定符和FCS，并將數(shù)據(jù)幀轉(zhuǎn)換成光/電信號，再發(fā)送到出接口線路上。

如果報文長度超過MTU，則判斷報文頭DF位，如果DF位置0，則分片后再發(fā)送給接口卡；若DF置1，表示報文源端不允許該報文分片，所以將報文做CP-CAR檢查后上送接口板CPU，再上送主控板CPU，以便回應(yīng)ICMP Too-Big消息給源端。

IPv6單播轉(zhuǎn)發(fā)流程

IPv6轉(zhuǎn)發(fā)流程與IPv4基本相同，不同點在于：

- 所查的表項不同，IPv4查FIBv4表，而IPv6查的是FIBv6表；IPv4查ARP表，而IPv6則是查鄰居表。

- IPv6 MTU檢查時，超過接口IPv6 MTU時不進行分片，而是上送CPU并返回ICMPv6 Too-big消息給源端（這符合IPv6協(xié)議標準）。

濟南博賽網(wǎng)絡(luò)技術(shù)有限公司是一家集IT產(chǎn)品銷售、高端IT技術(shù)服務(wù)、技術(shù)培訓(xùn)為一體的綜合性高新技術(shù)企業(yè)，與全球多家IT企業(yè)建立了長期合作伙伴關(guān)系，在產(chǎn)品技術(shù)服務(wù)領(lǐng)域、高端IT認證培訓(xùn)領(lǐng)域以及產(chǎn)品銷售方面都有深層次的合作。
基于SDN的大型IP網(wǎng)絡(luò)BGP路由優(yōu)化方案

基于SDN的大型IP網(wǎng)絡(luò)BGP路由優(yōu)化方案

摘要：針對IP骨干網(wǎng)路由規(guī)模大、路徑多、重疊度高而易繞轉(zhuǎn)的問題，在分析傳統(tǒng)BGP路由選路機制缺陷的基礎(chǔ)上，采用SDN控制技術(shù)，提出了一種支持傳統(tǒng)路由設(shè)備和OpenFlow設(shè)備的路由反射優(yōu)化方法，并給出了具體實現(xiàn)算法及部署方案。典型應(yīng)用場景的測試結(jié)果表明，國際訪問時延平均縮短了30%，驗證了方法的有效性。

關(guān)鍵詞：軟件定義網(wǎng)絡(luò)；OpenFlow；邊界網(wǎng)關(guān)協(xié)議；OpenDaylight

中圖分類號：TN915.41

文獻標識碼：A

doi: 10.11959/j.issn.1000-0801.2016112

Route optimization method for BGP based on

SDN in large-scale IP network

TANG Hong, ZHU Huahong, CAO Weihua, ZOU Jie

Guangzhou Research Institute of China Telecom Co.,Ltd., Guangzhou 510630, China

Abstract: Aiming at rotation problem of route because of large-scale, multi-path, overlap in IP backbone networks, an optimization method for route reflection supported by both traditional routing devices and OpenFlow devices based on SDN controller technology was proposed. At first, the defects of traditional BGP routing mechanism was analyzed in detail. Then, a specific algorithm implementation and deployment scenarios were given. Test results of typical application scenarios demonstrate the validity of the proposed method. The average delay of international access reduces by 30%.

Key words: software defined networking, OpenFlow, border gateway protocol, OpenDaylight

1 引言

近年來，隨著產(chǎn)業(yè)變革和新技術(shù)的發(fā)展，互聯(lián)網(wǎng)迅速成為影響社會經(jīng)濟發(fā)展、改善人民生活品質(zhì)的重要基石。互聯(lián)網(wǎng)應(yīng)用不斷豐富，寬帶用戶數(shù)高速增長，尤其是“寬帶中國”戰(zhàn)略進一步促進了寬帶網(wǎng)絡(luò)能力的躍升，網(wǎng)絡(luò)流量每年以60%的速度高速增長，給IP骨干網(wǎng)運營帶來巨大的挑戰(zhàn)。互聯(lián)網(wǎng)路由條目數(shù)不斷增加，但受限于傳統(tǒng)分布式的路由算法以及匱乏的整體網(wǎng)絡(luò)拓撲，大量的重疊路由導(dǎo)致流量繞轉(zhuǎn)、用戶感知下降等問題。因此，隨著骨干網(wǎng)規(guī)模的增加及流量的增長，如何優(yōu)化路由選路策略成為一個重要而有價值的研究課題。

軟件定義網(wǎng)絡(luò)（software defined networking，SDN）技術(shù)[1]為骨干網(wǎng)路由優(yōu)化提供了有效手段，但骨干網(wǎng)設(shè)備數(shù)量多、改造成本高，全網(wǎng)設(shè)備的升級替換較為困難，需要考慮兼容現(xiàn)有設(shè)備能力的解決方案。本文在分析現(xiàn)有路由反射器選路機制缺陷的基礎(chǔ)上，提出了一種基于源和目的地址的路由反射優(yōu)化方法，并給出了骨干網(wǎng)部署方案。最后，在典型應(yīng)用場景下進行測試，驗證了方法的有效性。

2 傳統(tǒng)路由反射器路由選路機制

邊界網(wǎng)關(guān)協(xié)議（border gateway protocol，BGP）[2]是一種自治系統(tǒng)間的動態(tài)路由發(fā)現(xiàn)協(xié)議，它的基本功能是在自治系統(tǒng)間自動交換無環(huán)路的路由信息，通過交換帶有自治系統(tǒng)號（AS）序列屬性的路徑可達信息，構(gòu)造自治區(qū)域的拓撲圖，從而消除路由環(huán)路并實施用戶配置的路由策略。在大規(guī)模網(wǎng)絡(luò)中，通過部署路由反射器來減少對等體連接關(guān)系，1所示。路由反射器收到多個指向同一IP 地址前綴但下一跳不同的路由信息，路由反射器按照BGP路由選擇機制來確定最優(yōu)路由，也就是選擇下一跳，然后轉(zhuǎn)發(fā)給客戶機和非客戶機。選路的規(guī)則如下[3]：

（1）如果next-hop無法到達，則不考慮；

（2）首選具有最大weight的路由（Cisco特有）；

（3）如果路由具有相同weight，則使用本地優(yōu)先級最高的路由；

（4）如果具有相同本地優(yōu)先級，則首選來自本身路由器的BGP路由；

（5）如果沒有來自本身路由器上的BGP路由，則選擇AS長度最短的路由；

（6）如果所有的路由具有相同的AS長度，則選擇具有最低origin code的路由；

（7）如果origin code相同，則選擇MED值最小的路由；

（8）如果MED相同，則首選外部路由，而不是內(nèi)部路由；

（9）如果仍然相同，選擇最近的IGP鄰居的路由；

（10）如果仍然相同，選路由器ID最小的路由；

（11）如果仍然相同，選cluster_list最短的路由。

因此，從客戶機角度看，經(jīng)過路由反射器選擇后的下一跳可能不是最佳選擇——只是距離路由反射器最近的路由，而不是源和目的地址間距離最近的路由，導(dǎo)致次優(yōu)路由的產(chǎn)生，2所示。

圖2中，上海客戶機和廣州客戶機1都有ICP的路由prefix 1，并將該條路由向路由反射器進行通告。路由反射器根據(jù)BGP選路規(guī)則進行選路，當(dāng)（1）~（8）的屬性都相同，無法判斷時，根據(jù)規(guī)則（9）選擇距離自身IGP最近的上海客戶機作為下一跳反射給所有客戶機，導(dǎo)致廣州客戶機2接入的用戶經(jīng)上海訪問prefix 1，造成路由繞轉(zhuǎn)。

3 基于源和目的地址的路由反射方法

3.1 基于源和目的地址的路由反射方法

傳統(tǒng)路由反射器的選路規(guī)則在（9）中是從路由反射器自身角度計算到下一跳的IGP最短距離，因此所有的客戶機都將收到同樣的路由，對于某些客戶機來說，該路由并非最優(yōu)路徑。在很多情況下，可能導(dǎo)致流量的繞轉(zhuǎn)，造成時延增大，用戶感知下降。針對該問題，IETF也有相關(guān)草案，路由器支持add-path功能[4]，反射器反射多條路由，由客戶機自行計算最佳路由。考慮目前互聯(lián)網(wǎng)路由數(shù)量超過50萬條[5]，且波動較大，因此，對反射器的性能要求較高，客戶機需要接收的路由條目也較多，實際應(yīng)用中實施困難。為此，對該條選路規(guī)則進行修改，路由反射器反射路由時，對不同的客戶機計算客戶機到下一跳的IGP最短距離，從而選擇源和目的地址間的路徑最短路由。基于OpenFlow技術(shù)[6]，在網(wǎng)絡(luò)中部署OpenFlow控制器，對不同的設(shè)備下發(fā)不同的流表實現(xiàn)最優(yōu)路徑的選擇。圖3為OpenFlow 1.3[7]的流表結(jié)構(gòu)，對于相同的路由前綴，針對不同的客戶機計算其與各下一跳之間的IGP距離，選擇距離最小的下一跳作為最優(yōu)路由下發(fā)流表。

然而，在骨干網(wǎng)中，仍然存在大量傳統(tǒng)路由設(shè)備，對OpenFlow的支持有限。為了在現(xiàn)網(wǎng)中實現(xiàn)該方法，依然需要考慮基于BGP對網(wǎng)絡(luò)設(shè)備進行控制。控制器主要包含狀態(tài)信息采集、數(shù)據(jù)中心、策略管理、網(wǎng)絡(luò)建模、統(tǒng)一計算以及指令適配模塊，具體4所示。

狀態(tài)信息采集模塊采集IP骨干網(wǎng)拓撲及網(wǎng)絡(luò)基礎(chǔ)設(shè)施和互聯(lián)網(wǎng)業(yè)務(wù)路由、業(yè)務(wù)流量流向和業(yè)務(wù)質(zhì)量等信息數(shù)據(jù)，同時將這一系列的大數(shù)據(jù)入庫到數(shù)據(jù)中心；統(tǒng)一計算模塊從BGP路由表中選出上述選路規(guī)則中（1）~（8）全相同的路由條目，同時計算設(shè)備間IGP metric矩陣，并對不同的客戶機計算下一跳IGP最短的最優(yōu)路徑；經(jīng)路由仿真模塊驗證策略后，最后進行統(tǒng)一下發(fā)。主要算法實現(xiàn)如下所示。

步驟1 從當(dāng)前BGP路由表查找選路規(guī)則（1）~（8）中路由屬性相同（如local-preference、MED、AS path length）的路由，即經(jīng)過路由反射器可能產(chǎn)生非優(yōu)選的路由。

步驟2 將步驟1中查到的路由數(shù)據(jù)復(fù)制到數(shù)據(jù)表BGP prefix中（先清空BGP prefix中已有數(shù)據(jù)，再寫入）。

步驟3 由于BGP路由更新頻繁，為了便于比較更新的路由，數(shù)據(jù)表prefixSnap用于存放以前采用步驟1獲取的路由。將BGP prefix表中的prefix與數(shù)據(jù)表prefixSnap中的prefix進行比較，如果相同，說明路由沒有更新，不做處理；如果不同，則將BGP prefix表中的prefix增量更新到數(shù)據(jù)表prefixSnap中。

步驟4 采集當(dāng)前網(wǎng)絡(luò)中IGP拓撲信息，生成設(shè)備間IGP metric矩陣。

步驟5 獲取當(dāng)前控制器的客戶機列表igpDevMetric，為了便于比較更新的拓撲，peerIpMetricSnap用于存放以前采集的客戶機列表。將igpDevMetric與peerIpMetricSnap進行比較，如果相同，說明拓撲沒有更新，不做處理；如果不同，則將igpDevMetric增量更新到peerIpMetricSnap中。

步驟6 獲取peerIpMetricSnap中的客戶機列表，針對每個客戶機，分別以該客戶機為根節(jié)點，基于IGP metric矩陣，采用SPF算法，對數(shù)據(jù)表prefixSnap中的相同prefix計算根節(jié)點到各下一跳的metric，將metric最小的下一跳作為該prefix的優(yōu)選路由。

步驟7 無論是否需要進行配置下發(fā)，都將上述最優(yōu)路由進行統(tǒng)計，并將其放入數(shù)據(jù)表WorkStatus中。

3.2 網(wǎng)絡(luò)部署方案

軟件定義網(wǎng)絡(luò)技術(shù)為傳統(tǒng)IP的優(yōu)化提供了重要手段，然而，IP網(wǎng)絡(luò)全面實現(xiàn)軟件自主定義還有很長的過程。首先是技術(shù)的成熟度還不適合大規(guī)模現(xiàn)網(wǎng)運營的要求，如高可靠性、高安全性以及電信級SLA要求；其次，現(xiàn)網(wǎng)設(shè)備的技術(shù)支持能力也成為應(yīng)用推廣的關(guān)鍵。考慮到骨干網(wǎng)仍然以傳統(tǒng)網(wǎng)絡(luò)設(shè)備為主及新技術(shù)引入的可能風(fēng)險，網(wǎng)絡(luò)中的部署方案以增量疊加為主：在網(wǎng)絡(luò)中部署SDN控制器，支持OpenFlow和BGP，對傳統(tǒng)設(shè)備采用BGP的更新方式，對OpenFlow設(shè)備下發(fā)流表進行控制。其部署方案5所示。

控制器與路由反射器、相關(guān)的客戶機建立IBGP鄰居關(guān)系，并僅接收路由反射器反射的路由，同時獲取IGP metric矩陣信息。結(jié)合BGP路由數(shù)據(jù)庫及鏈路狀態(tài)數(shù)據(jù)庫，提取多路徑路由，計算源到路由接收段之間的SPF計算，針對不同的客戶機提取最優(yōu)路徑，經(jīng)校驗路由可達后分別對不同的客戶機反射相關(guān)路由，或者下發(fā)流表，具體算法見第3.1節(jié)中的描述。客戶機同時收到傳統(tǒng)路由反射器及控制器的路由，根據(jù)BGP選路信息可以進一步得到最佳路徑，放入路由表。該部署方案的好處在于，如果控制器發(fā)生故障或者計算錯誤，可以直接退出服務(wù)，原有IP地址仍然起效，不會對網(wǎng)絡(luò)運營造成巨大影響。為了更好地對全網(wǎng)路由進行維護和監(jiān)控，系統(tǒng)提供了相關(guān)的展示功能，6所示。

路由表中的數(shù)據(jù)可以按“路由前綴”（prefix字段）、歸屬AS（destAS字段）、next-hop進行查詢及顯示，方便人員進行操作。

4 測試結(jié)果分析

SDN控制器主要是一個軟件實體，目前主流的開源控制器主要有NOX、POX、Ryu等。本文提出的控制器主要基于OpenDaylight開源平臺[8]實現(xiàn)，采用OSGI框架和Java開發(fā)，南向支持SNMP、BGP、OpenFlow等協(xié)議，北向提供RESTful接口[9]，便于實現(xiàn)開放性。

測試的典型場景5所示，大量ICP會在多地接入骨干網(wǎng)，例如從上海、廣州兩地的ASBR均擁有ICP的路由，經(jīng)骨干網(wǎng)路由反射器后只優(yōu)選一條下一跳為上海節(jié)點的路由進行反射，導(dǎo)致廣州接入段的用戶需要繞轉(zhuǎn)到上海節(jié)點訪問ICP，造成時延增加，用戶體驗下降。尤其在國際網(wǎng)絡(luò)環(huán)境下，繞轉(zhuǎn)的距離將大幅度增加，從而裂化訪問質(zhì)量。在骨干網(wǎng)（100多臺路由器，50萬多條互聯(lián)網(wǎng)路由）中部署SDN控制器，采用本文所提方法采集全網(wǎng)拓撲信息和路由數(shù)據(jù)，針對廣州客戶機2，計算出到達ICP的最優(yōu)路徑為廣州客戶機1，于是對廣州客戶機2下發(fā)下一跳為廣州客戶機1的ICP路由，實現(xiàn)路由最優(yōu)化，降低單向訪問時延約15 ms，7所示。進一步地，國際訪問時延平均可降低30%。測試結(jié)果表明，本文方法可實現(xiàn)路由端到端優(yōu)化，提高互聯(lián)網(wǎng)訪問質(zhì)量，驗證了方法的可行性。

5 結(jié)束語

SDN作為一種優(yōu)化和簡化網(wǎng)絡(luò)操作的體系結(jié)構(gòu)方式，具有更大的靈活性和敏捷性，為基礎(chǔ)互聯(lián)網(wǎng)設(shè)施提供了智能化選擇，成為當(dāng)前網(wǎng)絡(luò)領(lǐng)域最熱門和最具發(fā)展前途的技術(shù)之一。本文針對BGP的缺陷導(dǎo)致IP骨干網(wǎng)路由不佳、流量繞轉(zhuǎn)問題，提出了一種基于SDN的路由反射方法，并給出了網(wǎng)絡(luò)規(guī)模部署方案。測試結(jié)果表明，新方法可減少流量繞轉(zhuǎn)情況，國際互聯(lián)網(wǎng)訪問質(zhì)量可大幅度提升，證明了方法的有效性。然而，SDN作為一項系統(tǒng)工程，仍有大量的技術(shù)研發(fā)及實例化工作，后續(xù)將進一步完善控制器功能，實現(xiàn)網(wǎng)絡(luò)的高質(zhì)量運營。

參考文獻：

[1]張朝昆, 崔勇, 唐翯祎, 等. 軟件定義網(wǎng)絡(luò)（SDN）研究進展[J]. 軟件學(xué)報, 2015, 26(1): 62-81.

ZHANG C K, CUI Y, TANG H Y, et al. State-of-the-art survey on software-defined networking (SDN)[J]. Journal of Software, 2015, 26(1): 62-81.

[2]李道豐, 王高才, 王志偉, 等. 標準模型下可證明安全的BGP路由屬性保護機制[J]. 計算機學(xué)報, 2015, 38(4): 859-871.

LI D F, WANG G C, WANG Z W, et al. Provable secure mechanism for BGP path protection in the standard model[J]. Chinese Journal of Computers, 2015, 38(4): 859-871.

[3]徐建鋒, 朱華虹. 改進BGP實現(xiàn)大型復(fù)雜IP網(wǎng)絡(luò)的負載均衡[J]. 電信科學(xué), 2004, 20(10): 15-19.

XU J F, ZHU H H. Load sharing implementation in large complicated IP networks by improving BGP[J]. Telecommunications Science, 2004, 20(10): 15-19.

[4]SCUDDER J, RETANA A, WALTON D, et al. Advertisement of multiple paths in BGP[EB/OL]. [2012-12-30]. http://xueshu.baidu.com/s?wd=Advertisement+of+Multiple+Paths+in+BGP&rsv_bp=0&tn=SE_baiduxueshu_c1gjeupa&rsv_spt=3&ie=utf-8&f=8&rsv_sug2=1&sc_f_para=sc_tasktype%3D%7BfirstSimpleSearch%7D&rsv_n=2.

[5]辛喆. 一種基于SDN的IP骨干網(wǎng)流量調(diào)度方案的研究與實現(xiàn)[D]. 北京: 北京郵電大學(xué), 2015.

XIN Z. Research and realization of IP backbone network traffic scheduling program based on OpenFlow[D]. Beijing: Beijing University of Posts and Telecommunications, 2015.

[6]左青云, 陳鳴, 趙廣松, 等. 基于OpenFlow的 SDN技術(shù)研究[J]. 軟件學(xué)報, 2013, 24(5): 1078-1097.

ZUO Q Y, CHEN M, ZHAO G S, et al. SDN technology research based on OpenFlow[J]. Journal of Software, 2013, 24(5): 1078-1097.

[7]徐秋伊. 基于SDN的路由映射算法的設(shè)計與實現(xiàn)[D]. 北京: 北京郵電大學(xué), 2015.

XU Q Y. Design and realization of route mapping algorithm based on SDN[D]. Beijing: Beijing University of Posts and Telecommunications, 2015.

[8]AHMED S, MARTINI B, GHARBAOUI M, et al. Orchestration algorithms for network-assisted virtual machine migrations using OpenDaylight controller[C]// 2015 2nd International Conference on Electrical Information and Communication Technology (EICT), December 10-12, 2015, Khulna, Bangladesh. New Jersey: IEEE Press, 2015.

[9]WEI Z, LI L, MIN L, et al. REST API design patterns for SDN northbound API[C]// 2014 28th International Conference on Advanced Information Networking and Applications Workshops (WAINA), May 13-16, 2014, Victoria, BC, USA. New Jersey: IEEE Press, 2014: 358-365.