目录
RIPv1及RIPv2
RFC1058 (Routing Information Protocol)描述了 RIPv1， RIPv1 是一个典型的有类路 由协议(Classful Routing Protocol).。RIPv1不支持VLSM,这使得它只能够在特定的网络环境中提供路由信息服务，与之相关的一个非常重要的因素是，RIPvl的Response报 文中所携带的路由信息只有IP地址(目的网络地址)而没有目的网络掩码，这就使得 RIPvl在部署了 VLSM的网络中工作时会出现问题。
如图展示了一个部署了 VLSM的网络，R1连接着主类网络172.16.0.0/16的一个 子网——172.16.1.0/24, R3连接着该主类网络的另一个子网——172.16.3.0/24。如此一来, 172.16.0.0/16这个B类地址的两个子网被192.168.12.0/24及192.168.23.0/24这两个C类 网络地址段“隔开” 了，这种网络又被称为“不连续的主类网络”。现在网络管理员将在 Rl、R2 及 R3 上部署 RIPv1.
RIPv1是有类路由协议，运行RIPvl的路由器所泛洪的Response报文中，路由信息 是不携带目的网络掩码的，这就存在一个问题：如果R1要向外通告172.16.1.0/24这个 子网，路由的目的网络地址是多少？对方收到这个路由而又缺少网络掩码信息，它该如 何判断目标网络的掩码？ RIPvl定义了一套路由发送及更新规则，关于这些规则的描述 超出了本书的范围。如果RIPvl路由器处于主类网络边界，当它将一个主类网络的子网 路由通告到另一个主类网络时，会将前者自动汇总成主类路由进行通告。
在本例中，R1处于主类网络172.16.0.0/16及192.168.12.0/24的边界，因此当它向 192.168.12.0/24网络通告172.16.1.0/24这个子网路由时，会将该子网路由汇总成主类路 由：172.16.0.0 （注意R1将该路由通过Response报文通告给R2时是不携带目的网络掩 码的）。R2收到这条路由更新后，为172.16.0.0附上该地址的缺省掩码，也就是 255.255.0.0,因此最终R2将172.16.0.0/16路由加载到路由表中，该路由的下一跳为R1。
值得注意的是，R1及R3都处于主类网络边界，因此它们向R2发送的Response报 文都将包含172.16.0.0路由（而且没有目的网络掩码信息），这将使得R2收到这两份 Response报文后，将两条路由都加载到路由表中，如此一来，R2的路由表中的 172.16.0.0/16路由将在R1及R3这两个下一跳执行等价负载分担。这造成的一个直接结 果是R2转发到达172.16.3.0/24的数据包时，有可能会将其送往R1从而导致通信故障。 这就是RIPvl面对不连续的主类网络时存在的问题。解决这个问题的方法有几个，最为 推荐的方法是使用RIPv2而不是RIPv1。
RFC2453 （RIP Version 2）描述了 RIPv2,其改进点包括使用组播的方式发送RIP报文；支持无类路由选择；在Response报文携带的路由信息中增加目的网络掩码；支持报 文认证；增加下一跳特性；增加路由标记功能；支持手工路由汇总等。
相较于RIPv1， RIPv2最显而易见的改进点之一是该协议为无类路由选择协议，支持 VLSM。
报文发送方式
RIPv1使用广播的方式发送协议报文，这些报文的目的IP地址为255.255.255.255, 这是一个广播IP地址，一个设备发送的广播报文将在设备所处的广播域中泛洪，这使得 与其同处一个广播域的其他设备都将收到这个报文，并且耗费资源去处理这些报文—— 即使有些设备并不需要这些报文，例如广播域中的主机、服务器以及其他并未运行RIP 的设备等，这些设备收到一个RIPv1报文后，需要将其进行层层解封装，直至看到报文 的目的UDP端口号，然后发现本地并未侦听UDP520端口才会将该报文丢弃。
RIPv2则釆用组播地址224.0.0.9作为协议报文的目的IP地址，所有的RIPv2设备 都会侦听该组播地址。釆用这种方式发送协议报文，可以减少对广播域中其他设备的 影响。
报文认证
RIPv2支持报文认证功能，这使得RIP路由信息的交互更加安全。缺省时，RIP 路由信息的交互是缺乏安全性的，一旦设备的某个接口激活了 RIP,该接口即开始周 期性地发送Response报文及侦听RIP报文，如果接口上收到Response报文，RIP只 进行简单的校验，例如检査报文的源IP地址与自己的接口 IP地址是否在相同网段等, 随后就将所收到的Response报文中的路由信息学习过来，这显然是存在一定的安全隐 患的。
在图所示的网络中，R1及R2之间交互着RIP路由，现在R3连接到了交换机 上，并且开始在广播域中泛洪Response报文，这些伪造的Response报文中携带着大量 垃圾路由，这将造成R1及R2的路由出现紊乱，或者路由表被大量垃圾路由填充，设备 资源也将被大量消耗。
RIPv2给出了解决方案：RIP报文认证。通过在R1及R2的接口上激活RIP认证并 在两端配置相同的认证口令，可使RIP报文的交互更为安全，只有当接口上收到的RIP 报文中相关认证字段匹配本地配置的认证口令，该报文才被认为是有效的，否则被认为 是非法报文并被丢弃。
RIP认证是基于报文的，以简单（Simple）认证方式为例，路由器接口上配置RIP 报文认证后，该接口发送的RIP报文将会携带认证信息，如图所示。认证信息会占用报文的第一个路由项（该路由项的地址族标识符为0xFFFF）,此时一个Response报文可携带的最大路由条目数量从25条变成24条。
以华为AR2200路由器为例，支持以下几种RIP认证方式：
简单认证；
MD5认证（IETF标准）；
MD5认证（私有标准）。
下一跳字段
RIPv2定义了“下一跳”字段，使得路由器在多路访问的网络上可以避免次优路径现象。如图所示的网络中，R1、R2及R3连接在同一台以太网交换机上，R1和R3运行了RIPv2，但是R2并不支持RIP。R2直连着2.0.0.0/8，为了让R1能够访问这个网段，我们在R1上部署静态路由：
ip route-static 2.0.0.0 8 192.168.123.2
现在为了让R3也能够访问2.0.0.0/8，而且能够通过RIP学习到去往网段的路由，R1将静态路由引入到RIP。如此一来，R3就能够通过RIP学习到2.0.0.0/8路由，然而由于该条路由是学习自R1的，因此R3将这条路由加载到路由表时，认为R1是其到达该网段下一跳。这显然并非是最优的方案，因为从R3到达2.0.0.0/8的数据包将首先被转发给R2，再由R1转发到R2，这实际上存在次优路径的。为什么R3不直接将数据发往R2呢？这是因为对于距离矢量路由协议而言，路由的通告者就被视为该路由的下一跳。
说明：在同一个网络拓扑结构中，如果存在两种不同的路由协议，由于不同的路由协议的机理各有不同，对于路由的理解也是不相同，这就是在网络中造成了路由信息的隔离。在路由协议的边界设备上，将某种路由协议的路由信息引入到另一种路由协议中，这个操作称为路由引入（Route Importation）或者路由重分发（Route Redistribution）。例如一台路由器如果既配置了静态路由，又运行了RIP，那么其路由表中的静态路由对于RIP而言是外部路由，缺省时RIP域内的设备对于这些静态路由是无感知的，如果在该路由器上将静态路由引入到RIP，那么RIP域内的其他设备便能通过RIP学习到这些外部路由，这个操作就是路由引入。
RIPv2增加了“下一跳”字段来解决这个问题，当R1将2.0.0.0/8路由通过RIP通告给R3时，Response报文除了携带该路由的目的网络地址、目的网络掩码、度量值，还会设置“下一跳”字段，该字段的值为R1自己到达目标网络2.0.0.0/8的直连下一跳地址，也就是直连网段中的192.168.123.2（R2的接口地址）。
在大多数情况下，当RIP路由器发送路由更新时，路由的“下一跳”字段为0.0.0.0，其他RIP路由器接收到该路由更新后，将路由的通告者视为到达目的网段的下一跳。而在本场景中，R1通过设置这个字段来告知路由接收者到达目的网段的具体下一跳地址，从而规避次优路径的问题。如此一来，R3收到这个Response报文后，将路由2.0.0.0/8加载进路由表，而路由的下一跳设置为192.168.123.2（该地址直连可达）。当R3收到去往该网段的数据包时，便会将其直接转发给R2，而不会经由R1去转发。
路由标记
RIPv2增加了 “路由标记(Route Tag)”字段，使得从外部被引入RIP的路由能够携 带特定的标记信息。我们将一系列连续的RIP路由器构成的网络称为RIP域，RIP域内 的路由器通过network命令向RIP发布的路由将会被整个域内的RIP路由器学习到，这 些路由的“路由标记”字段值将被设置为0。当一条外部路由，例如静态路由、OSPF或 BGP路由等，被重分发到RIP时，RIP可以为该路由设置路由标记，此时执行重分发操 作的路由器将向RIP域中泛洪用于描述该外部路由的Response报文，而在该Response 报文中，被引入的外部路由会携带由网络管理员设置(或者协议自动设置)的路由标记， 域内的RIP路由器学习到该路由后都能看到该标记，并且可以基于该标记执行路由策略 等操作。
路由汇总
路由汇总是非常重要的一种思想，对网络优化的贡献是巨大的。一个大规模的网络 中，路由器为了维护大量的路由信息不得不耗费过多的设备资源，为了减小设备的负担, 同时保证网络中路由的可达性，部署路由汇总是非常推荐的解决办法。路由汇总指的是 同一个网段内的不同子网路由在向外通告时汇总成一条路由的行为。路由汇总主要用于 减小网络设备的路由表规模，进而减小网络中的路由更新的流量及设备资源消耗。在一 个大型的网络中路由汇总几乎是必须考虑的一种网络优化手段。
以如图所示的网络为例，R1 连接着 172.16.1.0/24、172.16.2.0/24 及 172.16.3.0/24 等大量网段，如果R1将这些网段的路由信息通过RIP统统通告给R2,那么R2的路由 表将立即变得“臃肿”，而且为了更新这些路由又得占用掉不少链路带宽。仔细一看不难发现该网络是可以通过部署路由汇总来进行优化的。
如果我们在R1上部署路由汇总，如图2-27所示，使R1不再通告172.16.0.0/16的 子网路由给R2,而是通告汇总路由172.16.0.0/16,那么R2的路由表将极大程度地被精 简，当R2转发到达这些子网的报文时，可以使用这条汇总路由来指导转发。当然，需要谨记的是，部署路由汇总的前提是IP地址规划具备一定的合理性，如果网络中的IP 地址规划非常紊乱且没有规律，那么路由汇总的部署势必存在极大的障碍。
RIP支持路由自动汇总，所谓路由自动汇总指的是如果RIP路由器处于主类网络边界，当它将一个主类网络的子网路由通告到另一个主类网络时，自动将该子网路由汇总成主类网络路由，只将主类网络路由通告给直连RIP路由器的行为。值得注意的是，RIP路由自动汇总只能将明细路由汇总成主类网络路由，这在某些场景下会存在“颗粒度过大"的问题。
RIPv1及RIPv2对于路由自动汇总的支持情况有所不同：
•在RIPv1中，路由自动汇总功能缺省已被激活，而且不能被关闭；
•在RIPv2中，路由自动汇总功能缺省已被激活，但是可以通过命令关闭。
以RIPv2为例，我们看看路由自动汇总的执行过程。在图2-27中，R1及R2运行了RIPv2,R1激活了RIP路由自动汇总功能，172.16.1.0/24、172.16.2.0/24等子网的主类网络地址及掩码长度是172.16.0.0/16,而R1的GE0/0/0接口的主类网络地址及掩码长度是10.0.0.0/8,显然R1处于两个主类网络的边界，因此当其向R2通告172.16.0.0/16的子网路由时，R1将会执行路由自动汇总，将这些明细路由汇总成主类网络路由172.16.0.0/16通告给R2。在路由汇总的执行过程中，只要存在一条明细路由，则该明细路由对应的主类网络汇总路由便会被通告，而如果所有的明细路由都失效，则RIP不再通告对应的汇总路由。
RIP路由自动汇总对本地始发的RIP路由生效，也对其他路由器通告的RIP路由生效。如图所示，如果在R1上关闭自动汇总功能，而R2激活该功能，则R1将向R2通告所有明细路由，R2收到这些路由后，将它们加载到自己的路由表，当其向R3通告这些路由时，由于激活了路由自动汇总功能，因此它仅向R3通告汇总路由172.16.0.0/16。
路由自动汇总功能使用起来的确颇为方便，然而正如此前所讲，该功能在某些场景中应用时可能存在问题。如下图所示，Rl、R2及R3三台路由器均运行RIPv2,其中R1及R3均处于主类网络边界。R1左侧连接着172.16.1.0/24、172.16.2.0/24……172.16.31.0/24这一系列子网，当它从GE0/0/0接口发送关于这些子网的RIP路由更新时，会将这些子网路由汇总成主类路由172.16.0.0/16再进行通告，遗憾的是R3同样会执行这个动作，它也会向R2通告172.16.0.0/16汇总路由，如此一来，R2将分别从R1及R3收到172.16.0.0/16路由的RIP更新。由于这两条汇总路由均从RIP获取，因此R2会根据度量值进行路由优选，如果它们的度量值相等，则R2会执行路由等价负载分担，也就是把这两条路由都加载到路由表中，这就会发生问题，因为到达172.16.32.0/24等子网的流量很有可能会被转发给R1从而造成流量丢失。
造成这个问题的原因是路由自动汇总所产生的汇总路由的“颗粒度太大”，换句话说是汇总路由的掩码不够精确。而如果在R1及R3上关闭自动汇总，所有的明细路由又都会被全部通告给R2,R2的路由表将立即变得臃肿，这当然也不是我们希望看到的。那么如果希望减小设备路由表规模的同时，解决上面提到的颗粒度问题，该如何操作？
答案是使用RIP手工路由汇总，也就是在R1及R3上首先关闭路由自动汇总，然后使用手工汇总来指定RIP通告的精确汇总路由。手工汇总的方式可以自定义汇总路由的目的网络地址及网络掩码，而不受地址类别的限制，如图所示。R1关闭RIP路由自动汇总后部署RIP路由手工汇总，使得它向R2通告汇总路由：172.16.0.0/19(与此同时明细路由将被抑制)；而R3也关闭RIP路由自动汇总并向R2通告另一条汇总路由：172.16.32.0/19。这两条汇总路由都精确地“囊括”了相应的明细路由，并且不会在R2上形成冲突，完美地解决了此前遇到的问题。
