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
