10.ip mroute -- 多播路由緩存管理 10.1.縮寫 mroute、mr 10.2.對象 這個命令的操作對象是多播路由緩存條目，這個緩存是由一個用戶空間的多播路由監控進程(例如pimd或者mrouted)建立的。 目前，由於受和多播路由引擎接口的限制，還不能通過ip命令修改多播路由對象，因此我們只能查看。 10.3.命令 show或者list 10.畲骉TL是32netadm@amber:~ # ip tunnel add Cisco mode sit remote 192.31.7.104 local 192.203.80.1 ttl 32 11.4.ip tunnel show -- 列出現有的通道 縮寫：show、list、sh、ls、l 參數 無 輸出格式 kuznet@amber:~ $ ip tunnel ls CiscoCisco: ipv6/ip remote 192.31.7.104 local 192.203.80.142 ttl 32 kuznet@amber:~ $ 輸出的第一部分是通道的設備名，接著是通道模式。下面就是設置通道時的各個參數。 統計信息 kuznet@amber:~ $ ip -s tunl ls CiscoCisco: ipv6/ip remote 192.31.7.104 local 192.203.80.142 ttl 32 RX: Packets Bytes Errors CsumErrs OutOfSeq Mcasts 12566 1707516 0 0 0 0 TX: Packets Bytes Errors DeadLoop NoRoute NoBufs 13445 1879677 0 0 0 0 kuznet@amber:~ $ 以上輸出結果裡面的數字和使用ip -s link show的輸出是一樣的，但是每個標志都是特定於通道的。 CsumErrs 對於打開校驗和檢驗的GRE通道，這個數字是由於校驗和錯誤而丟棄的數據包數量。 OutOfSeg 在打開順序功能的GRE通道內，由於順序錯誤而丟棄的數據包數量。 Mcasts 在GRE通道上接收到的多播數據包的數量。 DeadLoop 由於通道是回環到自己而沒有傳輸的數據包數目。 NoRoute 由於到對端沒有路由而沒有被傳輸的數據包數目。 NoBufs 由於內核不能分配緩沖區而沒有被傳輸的數據包數目。 12.ip monitor和rtmon -- 狀態監視 ip命令可以用於連續地監視設備、地址和路由的狀態。這個命令選項的格式有點不同，命令選項的名字叫做monitor，接著是操作對象： ip monitor [ file FILE ] [ all OBJECT-LIST ] OBJECT-LIST是一些被監控的對象，它可以包括link、address和route。如果沒有給出file參數，ip命令就打開RTNETLINK，在上面監聽，並把狀態的變化輸出到標准輸出設備。 如果使用了file參數，ip命令就不是在RTNETLINK上監聽，而是打開由file參數指定的包含RTNETLINK信息的二進制文件，把解析的結果顯示出來。這種歷史文件可以有工具產生。這個工具具有和ip monitor命令的語法類似的命令行。理想的情況是，在網絡配置命令起動之前運行rtmon命令(當然，你可以在任意的時間起動rtmon，它會記錄從起動開始的狀態變化)。你可以在起動腳本中插入以下命令行： rtmon file /var/log/rtmon.log 如果我們執行如下命令： [root@nixe0n root]ip route add dev eth0 to 61.133.4.7 via 211.99.114.65[root@nixe0n root]ip route del dev eth0 to 61.133.4.7 然後，我們使用ip monitor命令分析/var/log/rtmon.log會得到如下輸出結果： [root@nixe0n root]ip monitor file /var/log/rtmon.log rTimestamp: Wed Nov 6 20:25:54 2002 733331 us1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:002: eth0: mtu 1500 qdisc pfifo_fast link/ether 00:01:4f:00:15:f1 brd ff:ff:ff:ff:ff:ffTimestamp: Wed Nov 6 20:25:58 2002 33700 us61.133.4.7 via 211.99.114.65 dev eth0 Timestamp: Wed Nov 6 20:25:59 2002 924124 usDeleted 61.133.4.7 via 211.99.114.65 dev eth0 [root@nixe0n root] 13.rtacct -- 路由范圍和策略傳播 在使用OSPF或者BGP協議的路由器上，其路由表可能會很大。如果我們需要對其進行歸類或者計算通過每條路由的數據包，就需要保留很多信息。更糟糕的是，如果我們需要區別的不止是數據包的目的地址，還要包括它們的源地址，這個任務就更為復雜了，幾乎無法解決。 對於這個問題，Cisco IOS Release 12.0 Quality of Service Solutions Configuration Guide: Configuring QoS Policy Propagation via Border Gateway Protocol提出了一個解決方案，就是把策略從路由協議遷移到轉發引擎。基本上，通過BGP的Cisco策略遷移(Cisco Policy Propagation via BGP)就是基於此種方式，它使路由器保留所有和轉發引擎關系緊密的RIB(Routing Information Base，路由信息庫)，以便策略路由規則能夠監查所有的路由屬性，包括ASPATH的信息和團體(community)字符串。 而Linux把這分為由用戶空間監控維護的路由信息庫(Routing Infomation Base,RIB)，和內核層的轉發信息庫(Forwarding Infomation Base,FIB)。 這是我們的幸運，因為還有另外的解決方案，而這個方案允許更為靈活的策略和更為豐富的語義。 換句話說，可以在用戶空間根據路由的屬性把它們歸類，例如：BGP路由的ASPATH、團體(community)；OSPF路由的標記和它們的范圍。而管理員手工添加路由時，也知道它們的屬性。按照這個標准劃分的集合(我們把它們叫做realm)數量就很少了，因此按照路由的源地址和目的地址進行完全的分類就可以管理了。 因此，每個路由都可以被分配到一個范圍(realm)中。一般這是有路由監控進程作的，不過對於靜態路由，也可以使用ip route命令手工處理。 在某些情況下（例如路由監控進程不理解realm）為了方便，漏掉的realm可以由路由策略規則補齊。 內核使用如下算法計算每個數據包的源范圍(realm)和目的范圍(realm)： If route has a realm, destination realm of the packet is set to it. If rule has a source realm, source realm of the packet is set to it. If destination realm was not get from route and rule has destination realm, it is also set. If at least one of realms is still unknown, kernel finds reversed route to the source of the packet. If source realm is still unknown, get it from reversed route. If one of realms is still unknown, swap realms of reversed routes and apply step 2 again. 這個過程完成後，我們就知道了數據包的源范圍和目的范圍。如果某些還是未知，它就會被設置為0(realm unknown) 范圍(realm)主要還是由TC(Traffic Control)的路由類別(route classifier)使用，我們可以使用路由類別把數據包分配到給不同的流量類(trafffic class)，為數據包計數，以及為它們制定調度策略。 相對於TC，使用realm為進入的數據包計數就簡單多了，但這是一個非常有用的應用。內核可以根據realm收集總結數據包統計信息。在用戶空間，我們可以使用工具rtacct查看這些信息。例如： kuznet@amber:~ $ rtacct russiaRealm BytesTo PktsTo BytesFrom PktsFrom russia 20576778 169176 47080168 153805 kuznet@amber:~ $ 結果表示，這個路由器收到153805個來自russia地區的數據包，並且向russia轉發了169176個數據包。russia范圍由ASPATH(路徑自治系統)在俄羅斯的路由組成。 15.參考 T. Narten, E. Nordmark, W. Simpson. ``Neighbor Discovery for IP Version 6 (IPv6)'', RFC-2461.S. Thomson, T. Narten. ``IPv6 Stateless Address Autoconfiguration'', RFC-2462.F. Baker. ``Requirements for IP Version 4 Routers'', RFC-1812.R. T. Braden. ``Requirements for Internet hosts -- communication layers'', RFC-1122.``Cisco IOS Release 12.0 Network Protocols Command Reference, Part 1'' and ``Cisco IOS Release 12.0 Quality of Service Solutions Configuration Guide: Configuring Policy-Based Routing'',http://www.cisco.com/univercd/cc/td/doc/prodUCt/software/ios120.A. N. Kuznetsov. ``Tunnels over IP in Linux-2.2'',在：FTP://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz.A. N. Kuznetsov. ``TC Command Reference'',在：ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz.``Cisco IOS Release 12.0 Quality of Service Solutions Configuration Guide: Configuring QoS Policy Propagation via Border Gateway Protocol'',http://www.cisco.com/univercd/cc/td/doc/product/software/ios120.R. Droms. ``Dynamic Host Configuration Protocol.'', RFC-2131
