企业官网建设流程全解析

1. 先把RIP摆到正确的位置上

RIP协议这四个字，放在今天的技术栈里多少带点"考古"的味道，但凡是在H3C设备上做过基础实验、接过分支机构的老设备、或者准备网络方向认证的人，都绕不开它。我在刚接触网络设备那阵子，第一个让我在命令行里敲出错、盯着屏幕排查半小时的协议不是OSPF，就是RIP——明明network命令配得"看起来没毛病"，对端就是一条路由都学不到。后来才发现问题出在一个特别朴素的细节上：H3C上的network后面跟的东西，跟我脑子里想的完全不是一回事。

这篇内容就是把这个从零到跑通、从跑通到排错的过程，按我自己的实操顺序拆开讲一遍。RIP是距离矢量路由协议里最简单的一种，用跳数当度量，最大有效跳数15，16跳就认为不可达；它靠UDP 520端口收发报文，周期性广播或组播自己的整张路由表。这些基础参数决定了它的性格：配置门槛低、逻辑直观、资源占用小，但收敛慢、规模上不去、对环路敏感。它的价值不在于"先进"，而在于"够简单、够通用"——两三个网段的小型组网、和老设备对接、临时搭个实验环境验证互通性，用RIP往往比上一套OSPF更快出结果。

适合读这篇的人大概分三类：刚上手H3C Comware命令行、想借RIP熟悉接口/路由/协议三者关系的新手；手里有小型网络、需要在静态路由和动态路由之间做选择的一线维护人员；以及需要把RIP的原理和配置细节讲清楚、自己先得跑一遍的人。下面我按"H3C设备上RIP到底怎么配、为什么要这么配、配完学不到路由该怎么查"这条线来展开，命令都是在Comware V7上实测过的写法，不同版本可能有个别参数差异，但主干逻辑是通的。

2. RIP的核心机制与H3C上的配置逻辑

2.1 距离矢量算法：一张靠邻居口述拼出来的地图

RIP的路由学习过程，本质上是一场"传话游戏"。每台路由器并不了解整张网络拓扑，它只知道两件事：自己直连哪些网段（跳数0），以及邻居告诉它"我这儿到某个网段要几跳"。收到邻居的更新后，它把跳数加1，如果这个值比自己路由表里已有的更小，就更新；如果更新记录来自同一个邻居，干脆无条件覆盖。整套决策逻辑就这么点内容，没有任何链路状态数据库，也没有SPF计算。

这种"道听途说"的模型带来两个直接后果。第一是收敛慢，一台路由器要等到别人主动告诉它，才知道远处出了故障；第二是容易产生环路，因为信息在邻居之间来回传播时没有全局视野。也正因为这两个先天缺陷，RIP才发展出了水平分割、毒性逆转、触发更新、抑制时间这几套补丁。理解了这个背景，你在H3C上看到的那些undo rip split-horizon、rip poison-reverse、timer命令就不再是孤立的知识点，而是针对具体缺陷打的补丁。

提示：不要把RIP当成"简化版OSPF"来理解。它不是OSPF的删减版，而是另一条技术路线上的产物，设计目标就是"在极小规模、极低算力条件下把路由跑起来"，评价标准完全不同。

2.2 network命令的真实语义：不是在宣告网段

这是新手在H3C上踩的第一个大坑，也是我自己当年卡最久的地方。很多资料会把network 10.0.0.0解释成"宣告10.0.0.0这个网段"，于是新手很自然地写成network 10.1.1.0 255.255.255.0，设备直接报错或者行为不符预期。

准确的语义是：在这个IP地址所属的网段上，把所有接口都使能RIP。network后面跟的是有类自然网段，不是子网。H3C会拿这个地址去匹配设备上每个接口的IP，凡是落在该网段内的接口，全部启用RIP收发。所以network 10.0.0.0会把设备上所有10.x.x.x的接口一次性拉进RIP，哪怕你有10.1.1.0/24和10.1.2.0/24两个子网，一条命令全都覆盖了。

这个设计带来的正面效果是配置极简，负面效果是容易误伤——你只想让互联口跑RIP，结果一个network 0.0.0.0把接终端的业务口也全开了，更新报文往用户侧广播出去。我的习惯是：能精确到具体主类网段就不写0.0.0.0；实在需要精确控制某个子网，就配合silent-interface把不该收发的接口静音，而不是靠network去卡范围。

# H3C Comware V7 上启用RIPv2并关闭自动汇总 system-view sysname R1 rip 1 version 2 undo summary network 10.0.0.0 network 172.16.0.0 quit

注意rip 1里的1是进程号，本地有意义，两台设备不必一致。这一点和BGP的AS号、OSPF的进程号都不是一回事，别混了。

2.3 四个定时器决定了你要等多久

RIP的周期性更新不是随便拍的时间，背后全是工程折中。H3C默认的四个定时器如下：

这里最值得说的是收敛时间的来源。假设R1和R3之间的链路断了，R2要等180秒老化才会察觉，再加上120秒抑制期，从故障发生到路由彻底消失，最坏情况接近300秒。五分钟，业务侧早就炸了。这就是RIP不能上核心网的根本原因，不是"跳数不够"这一个理由，收敛速度才是硬伤。

触发更新能缓解一部分问题：链路状态变化时不等30秒周期，立刻发一次更新。但触发更新解决的是"好消息传得快"，坏消息（路由失效）依然依赖老化定时器。所以即便开了触发更新，RIP的收敛仍然是分钟级。

注意：不要在两端配置不同的定时器。RIP的定时器不参与协商，两端不一致会导致老化判断错乱，表现为路由莫名其妙地反复出现和消失。要改就全网统一改。

2.4 自动汇总：新手最容易踩的那颗雷

RIPv2默认开启自动汇总，在主类网段边界上把明细路由汇总成有类网络发出去。这个特性的初衷是减小路由表规模——毕竟RIP的报文最长512字节，每条路由占20字节，一个报文最多装25条，表一大就要拆包。

但它在实验和实际组网里制造的麻烦远比节省的带宽多。典型场景：设备上有172.16.1.0/24、172.16.2.0/24、172.16.3.0/24三个子网，RIP默认会把它们汇总成172.16.0.0/16告诉邻居。对端看到的是"到172.16.0.0/16，下一跳是你"，那么它转发去172.16.2.5的报文也会一股脑丢过来，哪怕实际路径不是这样。多出口环境下，这就是黑洞路由的温床。

所以我的配置模板里，undo summary几乎是标配，除非我明确知道这个网络就是单一出口、汇总是我想要的。关掉之后，每个子网带着自己的掩码单独传播，路由表变长，但下一跳准确。

另外还有个细节：RIPv1本身不支持携带掩码，所以它天然只能按有类网络处理；RIPv2才通过路由条目里的Subnet Mask字段支持VLSM。这也是为什么现在一上手就该直接上v2。

# 查看自动汇总是否生效，对比开启与关闭后的路由表差异 display rip 1 database display ip routing-table protocol rip

3. 三台路由器跑通RIPv2的完整实操

3.1 拓扑与地址规划

我习惯用一条链式拓扑做RIP的第一个实验，三台路由器首尾相接，每台挂一个环回口模拟业务网段。链路型拓扑能直观看出跳数的累加，也能顺手验证水平分割和自动汇总。

R1 ---- 10.1.1.0/24 ---- R2 ---- 10.1.2.0/24 ---- R3 | | | Loop0 Loop0 Loop0 172.16.1.0/24 172.16.2.0/24 172.16.3.0/24

地址规划表：

选172.16.x.x做环回口是刻意为之：172.16.0.0/16是B类私有地址，三个/24子网正好落在同一个主类网络内，能完美触发RIPv2的自动汇总。这比用192.168.x.x更容易暴露问题——192.168.1.0/24和192.168.2.0/24本身就是不同的C类网络，根本不会互相汇总。

3.2 基础配置逐个下发

三台设备的配置结构完全一样，只是地址不同。以R2为例，其余两台照葫芦画瓢：

system-view sysname R2 interface GigabitEthernet1/0/1 ip address 10.1.1.2 24 quit interface GigabitEthernet1/0/2 ip address 10.1.2.1 24 quit interface LoopBack0 ip address 172.16.2.1 24 quit rip 1 version 2 undo summary network 10.0.0.0 network 172.16.0.0 quit

这里有两个值得停一下的地方。

第一个是version 2。H3C的RIP进程默认工作在v1，不显式改版本，后面的undo summary、认证这些v2专属特性都用不上。我见过不止一次"配了半天认证没生效"，最后一查是版本还停在1。

第二个是network 10.0.0.0这一条把设备上所有10.x.x.x接口一次性拉进来了。在R2上，GE1/0/1和GE1/0/2同时被使能，这是我要的效果。但如果某台设备上有接用户终端的10网段接口，就会被误伤，那时候要用silent-interface处理，后面第4章会讲。

三台都配完，正常情况下等30秒左右，各台设备就能学到邻居的路由。

3.3 关闭自动汇总前后的对比

这一步是整个实验最有价值的环节，建议务必亲手对比一次。先把undo summary注释掉（即恢复默认的自动汇总），在R1上看路由表：

[R1] display ip routing-table protocol rip

你会看到R1只学到了172.16.0.0/16这一条，而不是172.16.2.0/24和172.16.3.0/24两条明细。原因很直接：R2在向外发布时，把172.16.2.0/24和它从R3学来的172.16.3.0/24，统统按主类边界汇总成了172.16.0.0/16。R1收到这一条之后，认为整个172.16.0.0/16都该往R2送，172.16.3.x的报文也就只能走R2——这次恰好是对的，因为拓扑是链式的，没有第二条路。但如果R1还连着另一台路由器、能直接到172.16.3.0/24，汇总就会让它选错出口。

把undo summary加回去，再清一次RIP进程或者等路由刷新：

[R1] reset rip 1

重新看，路由表里会出现：

度量那一列是RIP区别于其他协议最直观的地方：直连0跳，隔一台路由器1跳，隔两台2跳。没有任何带宽、延迟的加权，就是简单的跳数累加。你从R1上tracert 172.16.3.1，中间的跳数也正好对得上。

提示：reset rip 1会清空RIP进程的路由表并重新学习，实验环境里用很方便；生产环境慎用，清完到重新收敛这段时间是断的。

3.4 接口认证的配置与验证

RIP本身没有任何认证机制，RIPv2才补上了明文和MD5两种。配置位置不在RIP进程下，而是在接口下，这点和很多人对OSPF的直觉不同。

# R1 和 R2 的互联口两端都要配 interface GigabitEthernet1/0/1 rip authentication-mode md5 rfc2453 plain H3c@2024 quit

rfc2453表示使用标准的32字节MD5摘要（RFC 2453定义），H3C还提供usual模式，用16字节非标准摘要。两种模式两端必须一致，一端rfc2453一端usual，认证必然失败，而且失败时路由直接不学，日志里可能只有一行不起眼的提示。密钥我建议统一口径，明文密码在配置里显示为明文还是密文取决于plain/cipher参数，实验环境用plain方便对照，实际组网里按管理规范来。

验证认证是否生效，最直接的办法是看RIP的统计信息：

display rip 1 statistics interface GigabitEthernet1/0/1

如果认证失败，输出里通常能看到丢弃报文的计数在增长。另一种办法是临时开调试，注意调试信息量大，配完就关：

terminal monitor terminal debugging debugging rip 1 packet undo debugging rip 1 packet

3.5 验证命令与输出解读

跑完整个实验，我常用的验证命令有这么几条，建议按顺序都过一遍，形成肌肉记忆：

display rip 1 database这条命令特别值得单独说。它的输出分两部分，前面是"Peer"区域，列出每个邻居发来的路由及其度量；后面是"Routes on the interfaces"区域，列出本地哪些接口使能了RIP。新手排查"为什么没学到路由"，第一步就该看这里——如果Peer区域压根是空的，说明报文没收到（版本、认证、链路问题）；如果Peer里有路由但全局路由表没有，说明是被过滤或者被更优路由覆盖了。这一个区分就能省掉大量瞎猜。

4. 环路防护与性能调优的几个实用手段

4.1 水平分割与毒性逆转怎么选

水平分割的规则很朴素：从某个接口学到的路由，不再从同一个接口发回去。它解决的是两台路由器之间的"乒乓"问题——R1告诉R2"我能到172.16.3.0/24"，R2如果原样回告R1"我能到172.16.3.0/24（2跳）"，R1一看3跳比自己原来的还大，不会更新，但如果原来那条路由刚好失效了，R1就可能信了这条假消息，形成环路。

H3C的接口下默认开启水平分割，一般不用动。毒性逆转是水平分割的加强版：不光不把路由发回去，还主动发一条"我到这个网段16跳"的消息，明确告诉对方这条路走不通。配置上：

interface GigabitEthernet1/0/1 rip poison-reverse quit

两者的取舍在于带宽和收敛速度：毒性逆转能让邻居更快知道路由失效，但每次更新报文都变大（多出那些16跳的条目）。在接口少、路由条目少的环境里，我倾向开启毒性逆转，收敛体验更好；如果路由表大、链路带宽紧张，保持默认的水平分割就够。

注意：水平分割在点到点链路上开不开都行，但在NBMA或者帧中继这种多路访问环境里，水平分割可能因为"从同一物理接口学到又从同一接口发出去"而误伤其他邻居，这类场景需要评估是否关闭。

4.2 silent-interface：把面向终端的口静音

前面提过network命令会按主类网段把接口批量拉进来。如果某台路由器上有个接口接的是用户终端，它也会周期性地往这个接口广播RIP更新，一来浪费带宽，二来暴露网络结构，三来终端可能被这些报文困扰。

解决办法是silent-interface，被静音的接口只收不发：

rip 1 silent-interface GigabitEthernet1/0/3 quit

注意语义是"抑制RIP报文的收发"，不是"关闭接口"也不是"禁止该网段被发布"。被静音的接口所连的直连网段，依然会通过其他接口发布出去——这正好是我们想要的效果。

如果不想逐个接口写，H3C也支持silent-interface all，然后对需要正常跑RIP的接口再undo silent-interface。这个反向操作的写法在接口多的设备上更省事，但前提是你得清楚哪些接口是真正要跑邻居的，别一口气全静音了。

4.3 度量修改与路由过滤

RIP调优的空间不大，但两个手段必须会：改度量、做过滤。

改度量用rip metricin和rip metricout，注意这两个值都是在原有跳数上增加的量，不是直接设定。比如邻居发来的路由原本是1跳，接口上配了rip metricin 3，本地收到后记为4跳。这个细节坑过不少人，以为配了3就是3跳。

interface GigabitEthernet1/0/2 rip metricout 2 quit

metricout的作用是让从该接口发出去的所有路由都加上指定跳数，常用于让某条链路"看起来更远"，从而被优先选为备份路径。RIP本身没有带宽概念，想在两条链路之间做流量偏置，就只能靠这种人为加跳数的办法。

过滤用filter-policy配合ACL或前缀列表，可以控制哪些路由进表、哪些路由发布：

ip prefix-list PL_DENY_1723 index 10 deny 172.16.3.0 24 ip prefix-list PL_DENY_1723 index 20 permit 0.0.0.0 0 less-equal 32 rip 1 filter-policy ip-prefix PL_DENY_1723 import quit

这段的效果是拒绝接收172.16.3.0/24这条路由，其余放行。前缀列表的序号和匹配顺序要留神，RIP的filter-policy默认行为是"没匹配上就拒绝"，跟ACL的默认放行正好相反，这个反直觉的点我吃过亏，配完记得用display ip routing-table protocol rip核对一遍。

5. 常见故障排查实录

5.1 一条路由都学不到

这是最高频的问题，排查顺序我一般按"物理→接口→进程→版本→认证"五层往下走，一层层排除比乱试快得多。

先看接口物理状态和协议状态，display interface brief里两个都是UP才算通；再看接口IP是否在同一网段、是否被network覆盖。这里有个隐蔽的坑：接口配了IP但network写的是另一个主类网段，接口就不会被拉进RIP，display rip 1 interface里根本看不到它。第三步看两端版本，一端v1一端v2，v1用广播255.255.255.255、v2用组播224.0.0.9，互相收不到对方的报文，表现就是双方都学不到任何东西。第四步看认证，模式或密钥不一致时同样是零路由。第五步才是看调试信息。

还有一种情况值得单列：两台设备之间的互联口地址配成了不同子网，比如一端10.1.1.1/24另一端10.1.1.2/30，接口能UP，但RIP认为不在同一网段，不会建立邻居关系。

5.2 路由学到了但明细不对

这类问题的典型表现是"能ping通一部分地址，另一部分不通"，或者"路由表里只有一条汇总路由"。八成是自动汇总没关。前面第3.3节已经演示过对比，处理办法就是在RIP视图下补一条undo summary。

另一种可能是路由被更优的静态路由覆盖了。display ip routing-table 172.16.3.0能看到这条目的地址的候选路由和优先级，RIP默认优先级是100，静态路由是60，静态优先。如果之前为了临时打通配过静态路由忘记删，RIP学到的路由永远进不了主表。

5.3 认证配置的两个高频坑

第一个坑是配置位置。RIP认证配在接口下，不在rip 1视图下。新手照着某些资料在进程下敲rip authentication-mode，命令根本不存在。

第二个坑是摘要类型不一致。md5 rfc2453和md5 usual生成的摘要长度不同，两端不匹配就认证失败。这个失败还挺隐蔽，路由不是"时通时断"，而是压根不学，容易误判成别的问题。我的做法是全网点统一用rfc2453，配置模板固化下来，不给自己留选择的余地。

第三个容易被忽略的是密钥长度和特殊字符。某些版本对密钥长度有上限，超长会被截断，两端如果一端输入被截断、一端没有，也会失败。用简洁的密钥，别在实验环境里玩特殊字符。

5.4 故障速查表

提示：排查RIP问题时，reset rip 1+display rip 1 database这套组合能快速把状态归零重来。但一定要在确认没有业务流量的时段操作，清进程意味着短暂断网。

6. 我在实际配置中攒下的几点体会

RIP这个协议的配置量很小，真正的功夫全在几个"反直觉"的细节上。第一个是network的语义，我至今认为它是H3C RIP入门最大的认知门槛，把它理解成"在接口上启用协议"而不是"宣告网段"，后面所有配置行为就都顺了。第二个是RIP的默认版本是v1，任何涉及v2特性的配置，第一件事先确认version 2有没有敲。

第三个体会跟实验习惯有关。我建议每配完一组RIP，都用display rip 1 database和display ip routing-table protocol rip两条命令对照着看——前者是RIP进程自己认为的路由，后者是最终生效的路由。这两张表不一致的地方，就是问题所在：要么被过滤，要么被更优路由压着，要么压根没进主表。养成这个对照习惯，排查效率能提高一大截。

第四个是关于场景判断的。RIP适合的是那种"网段不超过十个、链路不复杂、对收敛时间不敏感"的环境，一旦网络里出现多出口、环状拓扑或者对故障切换有秒级要求，就不该再在RIP上做优化了，换协议比调RIP划算得多。我在一个分支点做过对比，同样的拓扑换成OSPF之后，链路断开到路由切换的时间从接近三分钟降到几秒，配置量也没有想象中多。RIP的定位就是"够用就好"，认清这一点，比把它研究到极致更有价值。

最后分享一个实用的小习惯：实验环境里我习惯给每台设备的RIP进程配一个固定的进程号（比如都用1），并且在配置文件顶部加一行注释记录本次实验的拓扑和目的。过几天回头看，一眼就能想起当时在验证什么，比翻聊天记录高效得多。这类细节看着不起眼，但积累下来，就是新手和老手之间最实在的差距。