IP多播技術介紹(一)

一、組播的協議結構

根據協議的做用範圍，組播協議分爲主機-路由器之間的協議，即組播成員管理協議，以及路由器-路由器之間協議，主要是各類路由協議。組成員關係協議包括 IGMP（互連網組管理協議）；組播路由協議又分爲域內組播路由協議及域間組播路由協議兩類。域內組播路由協議包括 PIM-SM、PIM-DM、DVMRP 、MOSPF等協議，域間組播路由協議包括 MBGP、MSDP 等協議。同時爲了有效抑制組播數據在二層網絡中的擴散，引入了 GARP、CGMP、IGMP Snooping 等二層組播協議。

經過 IGMP 和二層組播協議，在路由器和交換機中創建起直聯網段內的組成員關係信息，具體地說，就是哪一個接口下有哪一個組播組的成員。域內組播路由協議根據 IGMP 維護的這些組播組成員關係信息，運用必定的組播路由算法構造組播分發樹，在路由器中創建組播路由狀態，路由器根據這些狀態進行組播數據包轉發。域間組播路由協議根據網絡中配置的域間組播路由策略，在各自治系統（AS，Autonomous System）間發佈具備組播能力的路由信息以及組播源信息，使組播數據能在域間進行轉發。

二、組播地址結構

IP組播地址用於標識一個 IP 組播組。IANA 把 D 類地址空間分配給組播使用，範圍從 224.0.0.0 到 239.255.255.255。以下圖所示（二進制表示），IP 組播地址前四位均爲「1110」。以下圖所示：

IANA 把224.0.0.0 到 224.0.0.255 範圍內的地址所有都保留給了路由協議和其餘網絡維護功能。該範圍內的地址屬於局部範疇，不論生存時間字段（TTL）值是多少，都不會被路由器轉發；D類保留地址的完整的列表能夠參見RFC1700。

224.0.1.0 到 238.255.255.255 地址範圍做爲用戶組播地址，在全網範圍內有效。其中233/8 爲 GLOP 地址。GLOP 是一種自治系統之間的組播地址分配機制，將 AS 號直接填入組播地址的中間兩個字節中，每一個自治系統均可以獲得 255 個組播地址；

239.0.0.0 到 239.255.255.255 地址範圍爲本地管理組播地址（administratively scoped addresses），僅在特定的本地範圍內有效。

當 IP 層收到組播數據報文時，根據組播目的地址查找組播轉發表，對報文進行轉發。

三、組播地址到二層地址的映射

IANA 將 MAC 地址範圍 01:00:5E:00:00:00 ~ 01:00:5E:7F:FF:FF 分配給組播使用，這就要求將28位的 IP 組播地址空間映射到 23 位的 MAC 地址空間中，具體的映射方法是將組播地址中的低 23 位放入 MAC 地址的低 23 位，以下圖所示。

因爲 IP 組播地址的後 28 位中只有 23 位被映射到 MAC 地址，這樣會有 32 個 IP 組播地址映射到同一 MAC 地址上。

四、組播成員概念

一個多播會話的多播源並不必定要成爲接收它發送的流量的組中的成員。事實上，典型網絡中，源並不知道那些主機是組員，接收者任什麼時候候都能自由加入和離開組。若是源和全部的組員共享一個LAN，那麼就不須要其它協議。若是發送的多播流量須要通過大型的網路，則路由器必須經過某種方法獲知鏈接的網絡中是否有組員，若是有，是哪一個組的成員。當一個路由器知曉有一個多播會話時，它會向其所屬的子網查詢是否有主機要加入這個接收組。會向子網中全部系統地址224.0.0.1發送查詢，或它能夠向組內正在查詢的某一特定地址發送。若是有一個或多個主機迴應，那麼這個路由器會將會話的數據包轉到正確的子網中。

路由器週期性地向子網發送查詢，若是子網中仍有組員，那麼它們會響應全部的查詢，若是沒有主機響應，那麼路由器就認爲子網中全部的主機都已經離開這個組。因而中止向這個子網轉發數據包。

若是主機想加入組，則主機直接向路由器發送一個請求加入消息，路由器收到請求後，立刻把多播流量轉發到這個子網中。

當一臺主機退出一個組時，能夠向路由器發送退出通知，路由器收到主機退出通知後，立刻向這個子網發送一個查詢，詢問是否還有剩餘的組員。若是沒有響應，則判定該子網中沒有組員，因而中止向這個子網轉發組播流量。

主機發送的退出通知，能夠提升路由協議的效率，若是路由器知道它鏈接的任何子網中沒有任何組員，那麼它能夠把本身從多播樹中剪除。

若是網絡中有多個路由器時，好比，兩臺路由器鏈接一個子網，它們通過不一樣的路由收到同一源的多播流，若是一臺路由器或一條路由失效，組員則能繼續從另外一臺路由器收到多播流量，通常狀況下，兩臺路由器同時向子網轉發相同的多播數據流會影響網絡質量。路由器經過路由協議可以彼此知道對方的存在。所以，保證只有一臺路由器向同一子網轉發多播數據流的方法是在多播路由協議中加入指定路由器功能。查詢者負責多播流的轉發。其它路由器只進行監聽。只有當查詢者失效纔開始轉發多播數據流。

五、因特網組管理協議（IGMP）

IGMP是主機和路由器間的「語言」。全部要加入多播組的主機和全部鏈接到有多播主機的子網中的路由器都必須使用IGMP。這是一種和ICMP有不少相信之處的控制協議。IGMP消息被封裝在IP包頭中（協議號爲2），IGMP包頭中的TTL參數總設爲1。如今有兩種版本，IGMPv1在RFC1112中描述，IGMPv2在RFC2236中描述。

5.1 IGMPv2的主機功能

主機使用IGMPv2有3類消息：

l Membership Report消息

l Version Membership Report消息

l Leave Group消息

Membership Report消息用於指示一臺主機但願加入一個組，這個消息在一臺主機第一次加入組時發送，有時也用來響應本地路由器發出的Membership Query消息。

Membership Report消息IP包頭裏的目的地址是這個組的地址，爲了保證本地的路由器可以收到Membership Report消息，主機在短期內發出一個或兩個複製的報告，在RFC2236中建議這個時間間隔爲10s。

若是主機在它的計地器超時前收到一個Membership Report消息，它將再也不向這個組發送Membership Report消息。經過這種方法來節省網絡資源。

Version Membership Report消息是IGMPV2主機向後兼容的。IGMPV2用於檢測和支持其子網中的IGMPV1主機和路由器。

Leave Group消息是主機用來通知本地的路由器主機將退出該組。這個消息包含退出的組的地址。但與Membership Report消息不一樣的是，Leave Group消息是發向子網中全部路由器地址224.0.0.2的。是由於只有子網中的多播路由器須要知道主機已經退出，而其它組成員不須要知道。RFC2236推薦只在退出的成員爲最後一個發出Membership Report消息來響應查詢消息的主機時才發出Leave Group消息的。

5.2 IGMPv2的路由功能

路由器發送IGMP消息只有查詢一種類型，在IGMPV2中，有兩類查詢：

l General Query消息

l Group-Specific Query消息

General Query消息是路由器用來查詢其鏈接的全部子網是否有組員存在。並在子網中沒有組員時檢測，查詢默認的時間間隔爲60s。General Query消息被髮送到子網中全部系統224.0.0.1地址。若是一臺路由器在3次查詢時間間隔裏沒有收到一個特定子網中的Membership Report消息，那麼這個路由器將宣佈這個子網中沒有組成員。

Group-Specific Query消息，是當主機在正常狀況下退出組時會發送一個Leave Group消息，當路由器收到Leave Group消息時，必須判斷子網中是否有組員存在，爲了達到這個目的，路由器發送一個Group-sperific Query消息，與Greneral Query消息不一樣的是，它包含組的地址，而且用組的地址做爲目的地址。爲了防止Group-Specific Query消息被丟棄或破壞，路由器會每隔1s分別發送兩個Group-Specific Query消息。

當支持多播的路由器首先在子網中被激活，它認爲本身是查詢者時，會立刻發送General Query消息。

查詢者是負責向子網發送全部General Query和Group-Specific Query消息的路由器，當子網中有多臺路由器時，須要選舉查詢者，有較小IP地址的路由器成爲查詢者，因此子網中現有的路由器在收到新路由器的General Query消息後，就檢查源地址。若是它的IP地址值更小，則會繼續發送查詢，當新的路由器收到其中一個查詢，並發現這臺路由器有較小的IP地址時，它就變成非查詢者。

若是非查詢者在一段時間內沒有收到查詢者的查詢，那麼它認爲查詢者已經不存在了，並充當這個角色。

5.3 IGMPv1

l IGMPv1沒有Leave Group消息

l IGMPv1沒有Group-Specfic Query消息

l IGMPv1不在查詢消息中規定最大響應時間

l IGMPv1沒有查詢者選舉的過程

在某些狀況下，IGMPv1和IGMPv2可能同時存在一個子網中

l 某些組員運行IGMPv1，而另外一些運行IGMPv2

l 某些組員運行IGMPv2，而路由器運行IGMPv1

l 路由器運行IGMPV2，而某些組員運行IGMPV1

l 一臺路由器運行IGMPv1，而子網中的另外一臺路由器運行IGMPv2。

若是同一子網中同時有版本1和版本2的成員，若是一個版本2成員聽到路由器的查詢，隨後又收到同一組中版本1的Membership Report消息，那麼它就再也不發送本身的Membership Report消息。版本1的主機則忽略版本2的消息。

若是一臺主機運行版本2,而本地路由器運行版本1,那麼IGMPv1路由器將忽略版本2的消息。因此版本2的主機收到版本1的查詢後，將用版本1的Membership Report消息來進行響應。

若是版本2的路由器收到版本1的Membership Report消息，它會將全部的組員按版本1對待。路由器忽略Leave Group消息，也不發送Group-Specific Query。

5.4 IGMPv3

IGMPv3正在開發，IGMPv3中主要增長了Group-and-Source-Specific Query消息。它用來識別源地址。也對Membership Report和Leave Group消息進行了修改。

5.5 IGMP消息格式

IGMPv1消息格式

l Version(版本)：IGMP版本1。版本0在RFC-988中說明，它如今已經廢棄。

l Type(類型)：有兩種與主機相關的IGMP報文：

n 1=主機成員請求

n 2=主機成員報告

l Unused(未用):未用字段，在發送時爲零，接收時被忽略。

l Group Address(組地址)：主機成員請求報文在被髮送時組地址字段爲零，被接收時忽略該字段。主機成員報告報文中，組地址字段爲被報告組的IP主機組地址。

IGMPv2消息格式

l Type(類型)

有3種 IGMP 消息和主機與路由器的交互有關：

Membership Query(成員關係查詢)其值爲0x11，用於多播路由器發現子網中的成員。其有兩個成員關係查詢的子類型，General Membership Query(通常查詢)，用於瞭解一個組中是否有成員在相鄰的網絡中,將組地址設置爲0.0.0.0。Group-Specific Query(特定組查詢)，用於瞭解在相鄰的網絡中特定的組是否有成員,將組地址設置爲要查詢的組的地址。這兩個消息由組地址進行區分，成員查詢消息則相似於"Query"。

Version 2 Membership Report(版本2成員關係報告)其值爲0x16。用於告知路由器子網中至少有一個組員存在。

Leave Group（離開組）其值爲0x17，通知路由器其退出組。

Version 1 Membership Report(版本 1 成員報告)其值爲0x12。爲了和IGMP v1兼容

l 最大的響應時間

最大的響 應時間域僅在成員關係查詢中有效。規定了在發送一個迴應報文時最大的容許時間，(其單位爲1/10秒)。在全部其它的消息中，會由發送者置爲0，而接收者則忽略該域。

改變該設置能夠容許IGMPv2 路由器調整離開延時"leave latency" (最後一個成員離開組的時刻和通知路由協議該處已不在存在成員時的這一段時間。)

l 校驗字

校驗字是IGMP消息長度(IP包的整個有效負載)的16位檢測。該域設爲0，在計算校驗字時將該域包在一塊兒進行計算。當傳送包的時候，必須計算該校驗字並插入到該域中去。當接收包的時候，該校驗字必須在處理該包以前進行檢驗。

l 組地址

在General Query成員查詢消息中，發送一個一般的查詢時組地址域應設爲0，當發送一個Group-Specific特定組查詢時，則應設置組的地址。 在Membership Report成員報告或Leave Group離開組的消息中，組的地址域保留了要報告或要離開的地址。

l 其它域

注意IGMP 消息可能會大於8個字節，尤爲是未來向後兼容的IGMP版本。有一點必須注意，一個IGMPv2 的實如今處理包的時候必須忽略第一個8位字節。可是，IGMP的校驗老是在整個IP的有效負載上進行計算的，而不是正好在首先的8字節上。

組播路由器使用IGMP 來了解在他們全部的鄰接物理網絡上哪一個組擁有成員。 組播路由器保留有一個組播組成員的列表，和一個針對每一個成員的定時器。 "Multicast group memberships" 指在一個指定的鄰接網絡上至少有一個成員存在的組播組，而不是全部成員的列表。 考慮到其全部的鄰接網絡，一個組應該是兩個角色中的一個：查詢者或非查詢者。在每一個物理網絡上僅能有一個查詢者。在每一個鄰接的網絡上，開始時全部的路由器都作爲一個查詢者。若是一個組播路由器從一個擁有低IP地址的路由器聽到了查詢消息，則在該網絡上它必須做爲一個非查詢者。若是一個路由器沒有從其餘的路由器那聽到查詢消息（在查詢週期內），則會繼續作爲一個查詢者。 該路由器做爲一個查詢者周其性的在每一個鄰接的（查詢週期）網絡上發出一般的查詢消息，請求獲得成員信息。在開始時，路由器應該發送 [初始查詢計數] 間隔短的通常查詢消息，從而能夠快速的可靠的肯定成員信息。通常查詢的組地址爲0，發給全部系統的組播組 (224.0.0.1),有最大的查詢響應時間 [Query Response Interval]。

當一個主機接收到了普通的查詢，它會給每一個組(有查詢請求到達並有成員存在的端口，包括全部系統平臺的組)都設一個延時定時器，每個定時器都設爲一個不一樣的隨機值，該值由主機上所能有的最高時鐘頻率產生，範圍從0,到查詢包中所定義的最大響應時間。當一個主機接收到了一個特定組的查詢，則會將延時定時器設爲從0到最大響應時間的一個隨機值。若是定時器已經運行了，則若是所要求的最大響應時間小於當前運行的定時值所剩部份時，重置該定時器。當組的定時器到時後，主機組播一個版本2的成員報告到該組中，其IP 中 TTL的值爲1。如主機接收到了另外一個主機的報告(版本爲1或2)，而其自己的定時器尚未到時，則它會中止其特定組的定時器，且不發送報告，這樣就減小了重複的報告。

當路由器接收到了報告，它就會把該組報告加入到一個組播組成員列表中，而且會爲其成員關係設一個值爲組成員生存週期的定時器 。重複的報告會致使該定時器的刷新。若是在定時器到時以前沒有接收到一個特定組的報告，路由器則會假定沒有本地的成員，它也再也不須要在鄰接的網絡上爲該組轉發組播消息了。

當一個主機加入了一個組播組，則應該當即發送一個非請求的版本2的成員關係報告給組，以防它是網絡上該組的第一個成員。初始的成員報告可能會丟失或會受到損害，爲了防止此種狀況，推薦在短的間隔時間內報告一次或兩次(非請求報告間隔)。(一種簡單的方法能夠解決該問題。即經過發送版本號爲2的初始成員報告，就好象是從一個組接收到了特定組查詢的消息同樣，並設置適當的定時器)。

當一主機離開一個組播組，若是它是最後一個主機，除它外沒有其它的機器來報告成員關係了，則它應該發送一條離開組的消息 給全部路由器，地址爲組播組(224.0.0.2)，如它並非最後一個回答查詢的主機，它能夠不發送消息，就好象另外一個在子網中的成員同樣。這樣也能夠減小了一些數據流量。一個沒有足夠存儲器的主機不能記住是否它是最後一個主機，它離開一個組時，它老是會發送一條離開組的消息。爲了和早期的版本標準的兼容，路由器應接收該條離開組的消息。離開組消息發佈給全部的路由器組，由於其它的組成員沒必要知道一個主機是否離開了該組，但它不會破壞該離開組的消息。

當查詢者在其接口上接收到了組成員離開組的消息以後，它發送 [最後成員查詢計數 ] 特定組成員查詢 消息[最後成員查詢間隔] 給正離開的組。這些特定組查詢有最大的響應時間(設爲最後成員查詢間隔)。若是在最後查詢的響應時間以後，沒有報告者接到消息，路由器則會假定該組沒有本地的成員。在該時間內，任一個查詢者到非查詢者的傳送都會忽略，一個路由器會繼續發送特定組的查詢。

對於接收端口上沒有組成員時，非查詢者必須忽略離開組的消息，而查詢者則是應該忽略離開組的消息。當查詢者接收發一個特定組查詢消息，若是它的組成員定時器大於[最後成員查詢計數] 消息中所定義的最大響應時間，它會將其組成員計數 爲該值。

5.6 LAN組成員管理

IGMP 組播成員管理機制是針對第三層設計的，在第三層，路由器能夠對組播報文的轉發進行控制，只要進行適當的接口配置和對 TTL 值的檢測就能夠了。可是在不少狀況下，組播報文要不可避免地通過一些二層交換設備，尤爲是在局域網環境裏。若是不對二層設備進行相應的配置，則組播報文就會轉發給二層交換設備的全部接口，這顯然會浪費大量的系統資源。在交換網絡上控制多播的方法四種:

l 手工配置的交換式多播樹

l GMRP

l ICMP監聽

l CGMP

一、手工配置的交換式多播樹

是在交換機的橋接表裏加一個靜態的條目，在思科設備上被稱內容可尋址存儲器（CAM）表。以下圖所示，組員在交換端口2/三、2/四、2/19上，面路由器端口在1/1上，組地址爲239.0.5.10,這個IP地址將形成多播的MAC地址爲0100.5E00.050A，把這個信息手式輸入交換機的CAM表中。手工配置擴展性很差。並且不能跨路VLAN的邊界。

二、GARP多播組註冊協議（GMRP）

是一個IEEE802.1p中規定的開放協議，它讓MAC層的多播組地址動態地在交換上註冊和取消。GARP 組播註冊協議（GMRP）是通用屬性註冊協議（GARP）的一種應用，主要提供一種相似於 IGMP 探查技術的受限組播擴散功能。GMRP 和 GARP 都是由 IEEE 802.1P 定義的工業標準協議。

GMRP 容許網橋和終端站向鏈接到相同局域網段的 MAC 網橋動態註冊組成員信息，而且這些信息能夠被傳播到支持擴展過濾服務（extended filtering services）的橋接局域網中的全部網橋系統。 GMRP 的操做基於 GARP 所提供的服務。

GMRP 軟件運行在交換機和主機上。在主機上運行的 GMRP 和 IGMP 一同使用。主機 GMRP 軟件衍生爲主機第三層 IGMP 控制數據包的第二層 GMRP 版本。交換機接收來自主機第二層 GMRP 和第三層 IGMP 的流量。交換機使用接收的 GMRP 流量來限制主機 VLAN 的第二層組播。其實在全部狀況下，均可以使用 IGMP 探查技術來限制第二層組播，而不須要爲主機安裝或配置該軟件。

當有某臺主機想加入一個 IP 組播組時，它須要發送一個 IGMP join 信息，該信息衍生爲一個 GMRP join 信息。一旦收到 GMRP join 信息，交換機就會將收到該信息的端口加入到適當的組播組。交換機將 GMRP join 信息發送到 VLAN 中全部其它主機上，其中一臺主機做爲組播源。當組播源發送組播信息時，交換機將組播信息只經過先前加入到該組播組的端口發送出去。此外交換機會週期性發送 GMRP 查詢，若是主機想留在組播組中，它就會響應 GMRP 查詢，在該狀況下，交換機沒有任何操做；若是主機不想留在組播組中，它既能夠發送一個 leave 信息也能夠不響應週期性 GMRP 查詢。一旦交換機在計時器（leave all timer）設按期間收到主機 leave 信息或沒有收到響應信息，它便從組播組中刪除該主機。

三、IGMP 監聽（ IGMP Snooping）

主機發出 IGMP 成員報告消息，這個消息是給路由器的；在 IGMP 成員報告通過交換機時，交換機對這個消息進行監聽並記錄下來，造成組成員和接口的對應關係；

交換機在收到組播數據報文時，根據組成員和接口的對應關係，僅向具備組成員的接口轉發組播報文。

IGMP 監聽能夠解決二層環境中的組播報文氾濫問題，但要求交換機具備提取第三層信息的功能；其次，要求交換機對全部的組播報文進行監聽和解讀，這會產生不少的無效工做；此外，組播報文監聽和解讀工做也會佔用大量的 CPU 處理時間。

四、CGMP

思科組管理協議（CGMP）主要用來限定只向與 IP 組播客戶機相連的端口轉發 IP 組播數據包。這些客戶機自動加入和離開接收 IP 組播流量的組，交換機根據請求動態改變其轉發行爲。CGMP 主要提供如下服務：

l 容許只將 IP 組播數據包轉發到鏈接 IP 組播客戶機的那些端口。

l 經過限制沒必要要的 IP 組播流量，節省了網絡帶寬。

l 不須要改變終端主機系統。

l 不會產生爲交換網絡中的每一個組播組建立獨立 VLAN 的額外開銷。

路由器和交換機都必須配置運行CGMP，但是隻有路由器才產生CGMP包，交換機上的CGMP的處理只是讀取這些包，有兩種CGMP包：

l Join包由路由器發出，告訴交換機向多播組中加入一個或多個組員

l Leave包由路由器發出，告訴交換機從多播組中刪除一個或多個組員，或刪除整個組。

這兩種類型的包有相同的格式，包的目的地址老是爲保留的MAC地址0100.0cdd.dddd.激活CGMP功能的交換機會偵聽這個地址。

這兩種包裏的基本信息是一個或多個MAC地址對：

l 組目的地址（GDA）

l 單播源地址（USA）

承載CGMP包的幀的源MAC地址就是發起路由器的MAC地址，目的地址就是保留的MAC地址0100.0cdd.dddd，只有路由器才能產生CGMP包，在幀中，這個包由SNAP頭封裝。SNAP頭的OUI部分設爲0x00000c,類型爲0x2001。

類型	GDA	USA	功能
Join	0	路由器的MAC	肯定端口爲一多播路由器端口
Join	組的MAC	組員的MAC	肯定多播組，並把成員的端口加入到組中
Leave	組的MAC	組員的MAC	從一個組中刪除成員的端口
Leave	組的MAC	0	從CAM中刪除組
Leave	0	路由器MAC	從CAM中刪除全部與路由器端口相關的組和端口
Leave	0	0	從全部交換機上刪除全部的組

報文格式以下

l Version老是設爲0x1，表示版本1

l Type用於定義這個包的爲join(0x0)，仍是leave（0x1）

l Reserved老是設爲0

l Count用於定義這個包中有多少個GDA/USA對。

l GDA爲組目的地十，當這個參數爲非0地，它定義了一個多播MAC地址，當這個參數爲0時，它表示全部可能的組

l USA爲單播源地址，當這個參數爲非0時，它表示發起路由器的MAC地址或組成員的MAC地址，當其爲0時，它表示全部的組成員和發起路由器。

六、組播路由

與單播報文的轉發相比，組播報文的轉發相對複雜。一方面，組播路由類型與單播路由不一樣，是點到多點的一棵路由樹；另外一方面組播報文轉發的處理過程也有所不一樣。

6.1組播路由的分類

組播路由能夠分爲兩大類：信源樹（Source Tree）和共享樹（Shared Tree）。

信源樹是指以組播源做爲樹根，將組播源到每個接收者的最短路徑結合起來構成的轉發樹。因爲信源樹使用的是從組播源到接收者的最短路徑，所以也稱爲最短路徑樹（shortest path tree，SPT）。對於某個組，網絡要爲任何一個向該組發送報文的組播源創建一棵樹。

共享樹以某個路由器做爲路由樹的樹根，該路由器稱爲聚集點（Rendezvous Point，RP），將 RP 到全部接收者的最短路結合起來構成轉發樹。使用共享樹時，對應某個組，網絡中只有一棵樹。全部的組播源和接收者都使用這棵樹來收發報文，組播源先向樹根發送數據報文，以後報文又向下轉發到達全部的接收者。

信源樹的優勢是能構造組播源和接收者之間的最短路徑，使端到端的延遲達到最小；可是付出的代價是，在路由器中必須爲每一個組播源保存路由信息，這樣會佔用大量的系統資源，路由表的規模也比較大。

共享樹的最大優勢是路由器中保留的狀態數能夠不多，缺點是組播源發出的報文要先通過 RP，再到達接收者，經由的路徑一般並不是最短，並且對 RP 的可靠性和處理能力要求很高。

6.2報文轉發過程

單播報文的轉發過程當中，路由器並不關心組播源地址，只關心報文中的目的地址，經過目的地址決定向哪一個接口轉發。在組播中，報文是發送給一組接收者的，這些接收者用一個邏輯地址標識。路由器在接收到報文後，必須根據源和目的地址肯定出上游（指向組播源）和下游方向，把報文沿着遠離組播源的方向進行轉發。這個過程稱做 RPF（Reverse Path Forwarding，逆向路徑轉發）。

RPF 執行過程當中會用到原有的單播路由表以肯定上游和下游的鄰接結點。只有當報文是從上游鄰接結點對應的接口（稱做 RPF 接口）到達時，才向下遊轉發。RPF 的做用除了能夠正確地按照組播路由的配置轉發報文外，還能避免因爲各類緣由形成的環路，環路避免在組播路由中是一個很是重要的問題。RPF 的主體是 RPF 檢查，路由器收到組播報文後，先對報文進行 RPF 檢查，只有檢查經過才轉發，不然丟棄。RPF 檢查過程以下：

l 路由器在單播路由表中查找組播源或 RP 對應的 RPF 接口（當使用信源樹時，查找組播源對應的 RPF 接口，使用共享樹時查找 RP 對應的 RPF 接口），某個地址對應的 RPF 接口是指從路由器向該地址發送報文時的出接口；

l 若是組播報文是從 RPF 接口接收下來的，則 RPF 檢查經過，報文向下遊接口轉發；

l 不然，丟棄該報文。

6.3 域內組播路由協議

與單播路由同樣，組播路由也分爲域內和域間兩大類。域內組播路由目前已經討論的至關成熟，在衆多的域內路由協議中，DVMRP（距離矢量組播路由協議）、PIM-DM（密集模式協議無關組播）和PIM-SM（稀疏模式協議無關組播）是目前應用最多的協議。

一、DVMRP（Distance Vector Multicast Routing Protocol）

DVMRP 是第一個在 MBONE 上獲得廣泛使用的組播路由協議，它在 RIP 協議的基礎上擴充了支持組播的功能。DVMRP 協議首先經過發送探測消息來進行鄰居發現，以後經過路由交換來進行單播尋徑和肯定上下游依賴關係。

DVMRP 採用逆向路徑組播（RPM）算法進行組播轉發。當組播源第一次發送組播報文時，使用截斷逆向路徑組播（truncated RPM）算法沿着源的組播分發樹向下轉發組播報文。當葉子路由器再也不須要組播數據包時，它朝着組播源發送剪枝消息，對組播分發樹進行剪枝，藉此除沒必要要的通訊量。上游路由器收到剪枝消息後將收到此消息的接口置爲剪枝狀態，中止轉發數據。剪枝狀態關聯着超時定時器，當定時器超時時，剪枝狀態又從新變爲轉發狀態，組播數據再次沿着這些分支流下。另外，當剪枝區域內出現了組播組成員時，爲了減小反應時間，下游沒必要等待上游剪枝狀態超時，而是主動向上游發送嫁接報文，以使剪枝狀態變爲轉發狀態。可見，DVMRP 是由數據觸發驅動，創建組播路由表，而路由樹的創建過程能夠歸納爲「擴散與剪枝」（Broadcast and Prune）。轉發特色能夠歸納爲「被動接受，主動退出」。

另外，在多路訪問網絡中，當有兩個或多個的組播路由器時，網絡上可能會重複轉發包。爲了防止這種狀況出現，在多路訪問網絡上，DVMRP 爲每一個源選擇了一個惟一的轉發器。

DVMRP有7種包的類型：

l DVMRP Probe

l DVMRP Report

l DVMRP Prune

l DVMRP Graft

l DVMRP Graft Acknowledgement

l DVMRP Ask Neighbors2

l DVMRP Neighbors2

全部包的目的地址都是224.0.0.4,這個地址是保留的「全部DVMRP路由器」。

DVMRP有多個版本，版本1在RFC1075中描述，最新的版本3在一具internet草案9中描述。

DVMRP路由器啓動的第一步就是用Probe包去發現鄰居，每一個Probe包都有以下消息：

l 一組描述發起路由器DVMRP能力的標誌，做用是爲了與這個協議較早的版本兼容

l 一個生成ID，用於檢測鄰居狀態的變化

l 一組發起路由器收到Probe包的鄰居地址。

這些信息中，最基本的是這一組鄰居的地址，當一個DVMRP路由器收到一個probe包時 ，它記錄下這個發起路由器的地址和接收這個包的網絡接口。

發現鄰居後，路由器繼續發送probe包來進行保持，probe包每隔10s發送一個，若是在35s內沒有收到probe包，那麼這個鄰居就被宣告死亡。

DVMRP採用了RIP的許多變量來對外告知路由表和直連的子網，路由經過DVMRP Report消息從「全部DVMRP路由器」地址224.0.0.4對外告知，路由更新每60s發送一次，這個時間聞到稱爲路由報告間隔。若是一條路由在140s內沒有更新，那麼這條路由還將繼續保持兩個報告間隔（120s）。在這段時間內，這條路由在對外宣告時設置的度量爲無限。當保持時間也過時後，這條路由將從路由表中被刪除。

度量與每一條路由相關，是跳數的總和。若是設爲32跳，意味着跳數無限。不過，路由器能夠把度量設成1~63,1~31表示可達源，33~63表示依賴路由。

當多個上游路由器鏈接到一個多路訪問的網絡中時，只有指定的前轉器才能向下遊轉發包，節省了網絡資源。當兩個或多個路由器在一個多路訪問的網絡中交換路由信息時，它們能夠告訴對方誰離多播源更近。那麼，這臺路由器就成指定前轉器。以下圖所示。若是這教些路由器到達多播源的距離相等，則共享網絡中有較低IP值的路由器成爲指定的前轉器。

DVMRP消息的IP包頭的協議爲2,這一協議號與IGMP相同，IGMP是DVMRP開始階段的遺物，原來是這個協議的一個子集。

DVMRP消息頭

每個DVMRP消息都是以其開始的。

Type是IGMP的類型號，對於全部的DVMRP消息均設爲0x13。RFC1075中，這部分定義爲4bit版本和4bit類型，版本爲0x1，類型爲0x3，版本1中的這8bit值爲0x13,與版本3相同，使得版本3能向後兼容。

校驗和（chechsum）是標準的IP風格的校驗和，爲一個16bitDVMRP消息補碼和的補碼

次要版本(minor version)和主要版本(major version)對於全部的DVMRP消息分別設爲0xFF和0x03。

編碼(code)定義了DVMRPv3消息的消息類型。

Code	DVMRP Message Types
1	Probe
2	Report
3	Ask Neighbors
4	Neighbors
5	Ask Neighbors 2
6	Neighbors 2
7	Prune
8	Graft
9	Graft Ack

DVMRP Probe（探測）消息格式

有4種功能

l 它們讓路由器經過發起路由器列出全部檢測到的DVMRP路由器，互相知道彼此的位置

l 它們可讓DVMRP路由器互相通告彼此的功能

l 在有多條通路均可以到達下游組員時，它們能夠選出指定前轉器

l 它們每10s發送一次，具備保持存活的功能，若是35s內沒有聽到鄰居的Probe消息，這個鄰居將宣佈死亡。

DVMRP Probe消息字段信息以下：

能力（capabilities）:佔用了包頭中保留的8bit，probe消息是DVMRP中惟一一個修改了包頭中參數的消息。下表列出了能力標識值和它們表明的意思，若是一個標識設爲1,則發起路由器支持相關的能力。

Bit	Flag	Capability
0	L	這個路由器是葉路由器
1	P	這個路由器理解剪除
2	G	這個路由器發送生成ID
3	M	這個路由器能處理mtrace請求
4	S	這個路由器支持DVMRP MIB.
5	N	這個路由器理解 Prune、Graft、Graft Ack 消息中附加掩碼
6, 7	U	未使用

階段ID（generation ID）是一個不會減小的32bit數字，用於檢測路由器的重啓。當檢測到一個生成ID有變化是，任何從這個發起路由器發出的剪除消息均爲無效，並被清除。

鄰居地址(Neighbor address)列出了發起路由器收到的發出probe消息的鄰居的地址。

DVMRP Route Report （路由報告）消息格式

Route Report消息每60秒發送一個，其格式以下圖所示。這條消息由一組或多組網絡掩碼構成，對於每個掩碼，有對應的一個或多個網絡地址和相應的度量值。但實際中，這個長度是可變的。

掩碼（Mask）：網絡掩碼，網絡掩碼的第一個八位組老是設爲255,因此只有後3個八位組在掩碼參數裏， 這個參數意味着DVMRP路由不能收斂於掩碼小於8的地址。

源網絡（source net）：是源網絡地址，它的前綴長度同前面的掩碼相對應，源網絡的長度根據前面的掩碼長度而變化。

度量（metric）：是發起這個報告的路由器和源網絡間全部接口的量度之和。這個量度是跳數之和。32表示無限跳數，但量度的取值範圍是1~63。路由器經過向上遊路由器宣告一條毒性反轉路由（其度量值是接收到的度量值加上無窮大32），來向上遊路由器通告路由相關性，於是度量值33~63表示下游相關性。

DVMRP Prune（剪除）消息格式

源主機地址（source host address）：爲發起主機的IP地址

組地址（group address）：爲將被剪除的組的IP地址

剪除生存週期（prune lifetime）：是以s爲單位的上游路由器保存剪除狀態的時間，這個值或者是這個組中收到的下游剪除消息中的最小值。或者是在沒有下游剪除消息的狀況下使用的默認的存活時間2小時

源網絡掩碼（source network mask）：將被剪除的多播組源網絡的掩碼，這個參數是可選的，僅當上遊鄰居在probe消息中代表它支持網絡掩碼時才包括這個參數。

DVMRP Graft（嫁接）消息格式

源主機地址（source host address）：是發起主機的IP地址

組地址（group address）：是需接入的組的IP地址

源網絡掩碼（source network mask）：爲將被接入的多播組源網絡的掩碼，這個參數是可選的，僅當上遊鄰居在probe消息中代表它支持網絡掩碼時才包括這個參數。

DVMRP Graft Acknowledgement（嫁接確認）消息格式

除了頭中的編碼參數不一致外，格式同Graft消息同樣。

DVMRP Ask Neighbors2（詢問鄰居2）消息格式

此消息是兩個用於排錯的消息中的一個消息，數字2用於與做廢的Ask Neighbors消息區別開來，Ask Neighbors2消息是一個發向一個特定目的地的單播。當路由器收到Ask Neighbors2消息時，它應用單播消息Neighbors2向消息發起者應答，這個消息僅是一個DVMRP消息頭，其編碼設爲0x5。

DVMRP Neighbors2（詢問鄰居2）消息格式

DVMRP發送Neighbors2來響應Ask Neighbors2消息，這條消息是向Ask Neighbors2消息的發送者發送的單播，這個消息列出了路由器的能力和發送者的各邏輯端口的地址，對於列出的每一個端口，均規定了這個接口的DVMRP參數，面且所知道的這個接口上的DVMRP鄰居也列出了。

各參數定義以下：

能力（capabilities）：定義了發起路由器的DVMRP能力，這一參數與prune消息中的能力參數相同。

Bit	Flag	Description
0	Tunnel （隧道）	經過隧道到達鄰居
1	Source Route（源路由）	隧道使用IP源地址路由
2	Reserved （保留）	未使用
3	Reserved （保留）	未使用
4	Down （關閉）	操做狀態關閉
5	Disabled （禁用）	管理的狀態關閉
6	Querier （查詢）	對接口查詢
7	Leaf （葉）	這個接口沒有下游的鄰居

本地地址（local address）：是這個路由器的上一個接口的地址，若是這個接口被宕掉或禁用，那麼它和一個單一的鄰居地址相對應，這個鄰居地址爲0.0.0.0

度量（metric）：定義這個接口的DVMRP的度量

閾值（threshold）：定義了接口管理性定界閾值

鄰居計數（Nbr count）：定義了這個接口上列出的鄰居的數目。

鄰居（neighbor）:知道這個接口上的DVMRP鄰居路由器的IP地址

標識（flags）：用於描述這個接口上的可選參數。

在路由器上可使用show ip dvmrp route命令查看其路由表：

R5#sh ip dvmrp route

DVMRP Routing Table - 6 entries

10.1.1.0/24 [0/3] uptime 00:47:56, expires 00:02:47

via 10.2.5.2, Serial1/0.705

10.1.2.0/24 [0/3] uptime 00:47:56, expires 00:02:47

via 10.2.5.2, Serial1/0.705

10.2.1.0/24 [0/2] uptime 00:47:56, expires 00:02:47

via 10.2.5.2, Serial1/0.705

10.2.2.0/24 [0/3] uptime 00:47:56, expires 00:02:46

via 10.1.2.1, FastEthernet0/0

10.2.3.0/24 [0/2] uptime 00:47:57, expires 00:02:46

via 10.1.2.1, FastEthernet0/0

10.2.4.0/24 [0/2] uptime 00:47:57, expires 00:02:46

via 10.1.2.1, FastEthernet0/0

使用debug命令進行測試：

R5#debug ip dvmrp detail

DVMRP debugging is on

R5#debug ip dvmrp pruning

DVMRP debugging is on

R5#

*Nov 4 22:58:59.603: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 22:59:10.603: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 22:59:21.603: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 22:59:32.603: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 22:59:43.603: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 22:59:50.327: DVMRP(0): Received Report on FastEthernet0/0 from 10.1.2.1

*Nov 4 22:59:52.283: DVMRP(0): Received Report on Serial1/0.705 from 10.2.5.2

*Nov 4 22:59:53.627: DVMRP(0): Building Report for FastEthernet0/0

*Nov 4 22:59:53.647: DVMRP(0): Delay Report on FastEthernet0/0

*Nov 4 22:59:53.647: DVMRP(0): 2 unicast, 0 MBGP, 2 DVMRP routes advertised

*Nov 4 22:59:53.647: DVMRP(0): Building Report for Serial1/0.705

*Nov 4 22:59:53.667: DVMRP(0): Delay Report on Serial1/0.705

*Nov 4 22:59:53.667: DVMRP(0): 2 unicast, 0 MBGP, 3 DVMRP routes advertised

*Nov 4 22:59:53.671: DVMRP(0): Send Report on FastEthernet0/0 to 224.0.0.4

*Nov 4 22:59:53.671: DVMRP(0): Send Report on Serial1/0.705 to 224.0.0.4

*Nov 4 22:59:54.627: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:00:05.627: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:00:16.627: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:00:27.627: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:00:38.627: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:00:49.627: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:00:50.947: DVMRP(0): Received Report on FastEthernet0/0 from 10.1.2.1

*Nov 4 23:00:52.343: DVMRP(0): Received Report on Serial1/0.705 from 10.2.5.2

*Nov 4 23:00:54.635: DVMRP(0): Building Report for FastEthernet0/0

*Nov 4 23:00:54.655: DVMRP(0): Delay Report on FastEthernet0/0

*Nov 4 23:00:54.655: DVMRP(0): 2 unicast, 0 MBGP, 2 DVMRP routes advertised

*Nov 4 23:00:54.655: DVMRP(0): Building Report for Serial1/0.705

*Nov 4 23:00:54.667: DVMRP(0): Delay Report on Serial1/0.705

*Nov 4 23:00:54.667: DVMRP(0): 2 unicast, 0 MBGP, 3 DVMRP routes advertised

*Nov 4 23:00:54.667: DVMRP(0): Send Report on FastEthernet0/0 to 224.0.0.4

*Nov 4 23:00:54.691: DVMRP(0): Send Report on Serial1/0.705 to 224.0.0.4

*Nov 4 23:01:00.647: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:01:11.647: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:01:22.647: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:01:33.647: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:01:44.647: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:01:51.247: DVMRP(0): Received Report on FastEthernet0/0 from 10.1.2.1

*Nov 4 23:01:52.379: DVMRP(0): Received Report on Serial1/0.705 from 10.2.5.2

*Nov 4 23:01:54.707: DVMRP(0): Building Report for FastEthernet0/0

*Nov 4 23:01:54.727: DVMRP(0): Delay Report on FastEthernet0/0

*Nov 4 23:01:54.727: DVMRP(0): 2 unicast, 0 MBGP, 2 DVMRP routes advertised

*Nov 4 23:01:54.727: DVMRP(0): Building Report for Serial1/0.705

*Nov 4 23:01:54.747: DVMRP(0): Delay Report on Serial1/0.705

*Nov 4 23:01:54.751: DVMRP(0): 2 unicast, 0 MBGP, 3 DVMRP routes advertised

*Nov 4 23:01:54.751: DVMRP(0): Send Report on FastEthernet0/0 to 224.0.0.4

*Nov 4 23:01:54.751: DVMRP(0): Send Report on Serial1/0.705 to 224.0.0.4

*Nov 4 23:01:55.707: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:02:06.711: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:02:17.711: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:02:28.711: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:02:39.711: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:02:50.711: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:02:52.271: DVMRP(0): Received Report on FastEthernet0/0 from 10.1.2.1

*Nov 4 23:02:53.407: DVMRP(0): Received Report on Serial1/0.705 from 10.2.5.2

*Nov 4 23:02:55.711: DVMRP(0): Building Report for FastEthernet0/0

*Nov 4 23:02:55.731: DVMRP(0): Delay Report on FastEthernet0/0

*Nov 4 23:02:55.731: DVMRP(0): 2 unicast, 0 MBGP, 2 DVMRP routes advertised

*Nov 4 23:02:55.731: DVMRP(0): Building Report for Serial1/0.705

*Nov 4 23:02:55.751: DVMRP(0): Delay Report on Serial1/0.705

*Nov 4 23:02:55.755: DVMRP(0): 2 unicast, 0 MBGP, 3 DVMRP routes advertised

*Nov 4 23:02:55.755: DVMRP(0): Send Report on FastEthernet0/0 to 224.0.0.4

*Nov 4 23:02:55.755: DVMRP(0): Send Report on Serial1/0.705 to 224.0.0.4

*Nov 4 23:03:01.711: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:03:12.711: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:03:23.711: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:03:34.711: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:03:45.711: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:03:53.283: DVMRP(0): Received Report on FastEthernet0/0 from 10.1.2.1

*Nov 4 23:03:54.431: DVMRP(0): Received Report on Serial1/0.705 from 10.2.5.2

*Nov 4 23:03:56.711: DVMRP(0): Building Report for FastEthernet0/0

*Nov 4 23:03:56.731: DVMRP(0): Delay Report on FastEthernet0/0

*Nov 4 23:03:56.731: DVMRP(0): 2 unicast, 0 MBGP, 2 DVMRP routes advertised

*Nov 4 23:03:56.735: DVMRP(0): Building Report for Serial1/0.705

*Nov 4 23:03:56.755: DVMRP(0): Delay Report on Serial1/0.705

*Nov 4 23:03:56.755: DVMRP(0): 2 unicast, 0 MBGP, 3 DVMRP routes advertised

*Nov 4 23:03:56.755: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:03:56.755: DVMRP(0): Send Report on FastEthernet0/0 to 224.0.0.4

*Nov 4 23:03:56.759: DVMRP(0): Send Report on Serial1/0.705 to 224.0.0.4

*Nov 4 23:04:07.711: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:04:18.711: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:04:29.711: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:04:40.711: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:04:51.711: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:04:54.271: DVMRP(0): Received Report on FastEthernet0/0 from 10.1.2.1

*Nov 4 23:04:54.479: DVMRP(0): Received Report on Serial1/0.705 from 10.2.5.2

*Nov 4 23:04:57.731: DVMRP(0): Building Report for FastEthernet0/0

*Nov 4 23:04:57.751: DVMRP(0): Delay Report on FastEthernet0/0

*Nov 4 23:04:57.751: DVMRP(0): 2 unicast, 0 MBGP, 2 DVMRP routes advertised

*Nov 4 23:04:57.751: DVMRP(0): Building Report for Serial1/0.705

*Nov 4 23:04:57.771: DVMRP(0): Delay Report on Serial1/0.705

*Nov 4 23:04:57.775: DVMRP(0): 2 unicast, 0 MBGP, 3 DVMRP routes advertised

*Nov 4 23:04:57.775: DVMRP(0): Send Report on FastEthernet0/0 to 224.0.0.4

*Nov 4 23:04:57.775: DVMRP(0): Send Report on Serial1/0.705 to 224.0.0.4

*Nov 4 23:05:02.731: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:05:13.731: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:05:24.731: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:05:35.731: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:05:46.731: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:05:55.247: DVMRP(0): Received Report on FastEthernet0/0 from 10.1.2.1

*Nov 4 23:05:55.563: DVMRP(0): Received Report on Serial1/0.705 from 10.2.5.2

*Nov 4 23:05:57.759: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:05:58.759: DVMRP(0): Building Report for FastEthernet0/0

*Nov 4 23:05:58.779: DVMRP(0): Delay Report on FastEthernet0/0

*Nov 4 23:05:58.779: DVMRP(0): 2 unicast, 0 MBGP, 2 DVMRP routes advertised

*Nov 4 23:05:58.779: DVMRP(0): Building Report for Serial1/0.705

*Nov 4 23:05:58.799: DVMRP(0): Delay Report on Serial1/0.705

*Nov 4 23:05:58.803: DVMRP(0): 2 unicast, 0 MBGP, 3 DVMRP routes advertised

*Nov 4 23:05:58.803: DVMRP(0): Send Report on FastEthernet0/0 to 224.0.0.4

*Nov 4 23:05:58.803: DVMRP(0): Send Report on Serial1/0.705 to 224.0.0.4

*Nov 4 23:06:08.759: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:06:19.759: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:06:30.759: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:06:41.759: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:06:52.759: DVMRP(0): Aging routes, 0 entries expired

*Nov 4 23:06:56.279: DVMRP(0): Received Report on FastEthernet0/0 from 10.1.2.1

*Nov 4 23:06:56.647: DVMRP(0): Received Report on Serial1/0.705 from 10.2.5.2

*Nov 4 23:06:59.771: DVMRP(0): Building Report for FastEthernet0/0

*Nov 4 23:06:59.791: DVMRP(0): Delay Report on FastEthernet0/0

*Nov 4 23:06:59.791: DVMRP(0): 2 unicast, 0 MBGP, 2 DVMRP routes advertised

*Nov 4 23:06:59.791: DVMRP(0): Building Report for Serial1/0.705

*Nov 4 23:06:59.811: DVMRP(0): Delay Report on Serial1/0.705

*Nov 4 23:06:59.811: DVMRP(0): 2 unicast, 0 MBGP, 3 DVMRP routes advertised

*Nov 4 23:06:59.815: DVMRP(0): Send Report on FastEthernet0/0 to 224.0.0.4

*Nov 4 23:06:59.815: DVMRP(0): Send Report on Serial1/0.705 to 224.0.0.4

*Nov 4 23:07:03.771: DVMRP(0): Aging routes, 0 entries expired