企业官网建设流程全解析

前一阵子帮朋友处理一个网络故障，现象特别典型：单位内网其他业务都正常，唯独财务系统访问服务器时通时不通，延迟从 1ms 一路飙到几百上千毫秒，核心路由器 CPU 冲到 90% 以上。登录设备一看路由表，同一个网段一会儿指向下一跳 A，一会儿又指向下一跳 B，来回横跳。懂行的人应该已经猜到了——这就是典型的“路由环路”。

这个主题在计算机网络里几乎是所有教材的必考内容，《计算机网络（谢希仁版）》动态路由章节、408 统考里都反复出现，但真正的问题在于：书里只讲了几行字的“环路”，实际网络里却是从“间歇性丢包”到“全网瘫痪”的一连串故障。这篇文章我就把路由环路这件事彻底讲透，包括它怎么形成、不同协议下有什么特征、现场怎么快速定位和止血，以及你在模拟器里可以怎么亲手复现一次。不管你是被此类故障折磨过的运维新人，还是准备期末考试的学生，这篇文章都能给你一套能直接用的方法论。

1. 路由环路是怎么形成的

1.1 先看一个最简单的逻辑模型

理解路由环路，先从最简单的两台路由器开始。假设路由器 R1 和 R2 之间存在一条链路，R1 有一条去往网段 X 的直连路由，R2 从 R1 学到“去 X 走 R1”。这很正常，流量 R2 交给 R1，R1 直连送达 X。

但如果 R1 与网段 X 之间的链路突然断了，而 R1 还没来得及把这个变化告诉 R2，问题就来了。R2 的路由表里仍然写着“去 X 走 R1”，于是它把发往 X 的报文交给 R1；R1 呢，自己到 X 已经不通了，但它的路由表里可能还残留着一条从 R2 学来的、经由 R2 去 X 的旧路由。于是 R1 又把报文原路退回给 R2。R2 再投给 R1，R1 再退给 R2——数据包就在两台设备之间来回踢皮球。

这有点像你让一个快递员送包裹去某个地址，地址已经搬迁了，他问隔壁邻居，邻居说“你问前面那个人”，前面那个人又说“你问后面那个人”，最后包裹只能在一个小圈子里来回转，永远送不到收件人手里。

好在 IP 报文头里有一个 TTL（Time To Live）字段，每经过一台路由器就减 1，减到 0 时报文被丢弃，并回送一个 ICMP 超时消息。所以环路不会让数据包无限循环下去，但在 TTL 归零之前，这个报文会在环路里反复消耗链路带宽、占用设备 CPU，这才是环路最恶心的地方。

1.2 动态路由协议为什么会“自己骗自己”

看到这里你可能有个疑问：动态路由协议不是会定时交换路由信息吗？为什么链路断了，R2 还不知道？答案是：路由收敛需要时间，而在收敛完成之前，网络中不同设备各自掌握的信息是不一致的。正是这种“信息不一致”制造了环路。

以 RIP 为例，这是最容易理解也最容易踩坑的协议。RIP 的度量值是跳数，最大 15 跳，16 跳代表不可达。假设拓扑是 R1—R2—R3，网段 A 在 R1 后面。初始状态：R2 从 R1 学到“去 A 跳数 1”，R3 从 R2 学到“去 A 跳数 2”。一切正常。

现在 R1 与 R2 之间的链路断了。R2 不会立刻删除去 A 的路由，而是要等老化计时器超时。在这期间，R3 还在周期性地向 R2 通告“我去 A 是 2 跳”——注意，R3 的这条路由本来就是从 R2 学来的，但 R2 此刻并不知道自己已经失去了 A。

接下来就进入经典的“计数到无穷”过程：R2 暂时没有更优的路径，等到旧路由超时删除后，它会接受 R3 通告的“去 A 经 R3，2 跳”。然后 R2 再把这个路由通告给 R3，跳数变成 3；R3 发现自己原来的 2 跳“更好”，按理说不应该更新，但如果 R3 的旧路由也已经老化，它就会接受这个 3 跳的路径，再通告回 R2 变 4 跳……如此往复，跳数一路涨到 16，协议才判定这条路由彻底不可达。

RIP 为了防环，其实做了不少设计。我把常用机制整理成一个表，大家复习时可以对照着看：

这里最重要的结论是：RIP 的防环机制是“尽力而为”，不是“绝对无环”。真正网络里多个计时器错位、更新顺序颠倒、配置错误叠加在一起，环路照样会出现，只是表现形式不同。

2. 不同协议下的环路特征

2.1 RIP 环境：15 跳的“死亡倒计时”

RIP 网络里的环路有一个非常鲜明的特征：你看路由表时，会发现某个网段的跳数在持续变大。比如上一秒看到[120/2]，过三十秒变成[120/3]，再过三十秒变成[120/4]，直到涨到 16 然后整条路由消失。

RIP 的设计本身就很“原始”：周期更新默认 30 秒，用 UDP 520 端口发广播或组播，跳数就是唯一的度量标准。它根本不知道网络拓扑长什么样，只知道“我听邻居说的，邻居说远不远”。因此一旦发生故障，所有路由器都只能靠“听说”来更新自己的认知，而这种认知链条一断裂，环路就容易钻空子。

实际运维踩坑最多的地方是两类：一是接口上有人手动关了水平分割，以为能加速路由收敛，结果把最重要的防环屏障拆了；二是错误地宣告了 network 网段，导致设备把不该通告的路由发给了邻居，比如把内网管理网段通告进了生产网段，两台设备同时掌握一条“次优路径”，环路就在包里打转。记住一句话：RIP 网络的任何一处配置变更，都要确认“这条路由最终会不会被通告回来源方向”。

2.2 OSPF 和 EIGRP：看似无环，环都藏在策略里

很多人觉得 OSPF 和 EIGRP 算法先进，不会产生环路，这个想法平时没事，但一到重分发和区域边界就能把人坑到哭。

OSPF 在同一个区域内是严格无环的，因为每台路由器都拥有完全一致的链路状态数据库，SPF 算法算出来的是一棵无环的最短路径树。但区域之间依赖 ABR 生成和通告路由，一旦区域间汇总错误、虚链路配置不当，或者两台 ABR 对同一网段的通告逻辑不一致，就可能出现流量在两个 ABR 之间来回绕行的“次优路径”，本质上和环路的表现一模一样。还有一类常见配置：多条默认路由从两个边界设备同时下发到骨干区域，下发的路由被另一台边界设备学回去，形成默认路由互指。

EIGRP 的 DUAL 算法通过可行后继机制保证无环，但前提是拓扑表里有合法的可行后继。当所有路径都失效时，路由进入 active 状态，设备会向邻居发起查询，如果查询报文的响应顺序和内容有问题，收敛期间照样会出现暂时性环路。不过说实话，EIGRP 网络里真正的环路，绝大多数还是重分发造成的。尤其是“双向重分发”这个操作：把 RIP 的路由引到 OSPF，再把 OSPF 的路由引回 RIP，两边边界设备同时操作，不加任何过滤和标记，路由就可能在两个协议之间来回倒腾。我见过一个真实的案例，核心交换机上跑 OSPF，下面接的设备跑 RIP，双点双向重分发后，一台接入交换机的默认路由一会儿指向核心 A，一会儿指向核心 B，每次切换都伴随大面积丢包。表面看是“路由振荡”，本质上就是重分发制造的“策略环”。

3. 定位路由环路的标准排查流程

3.1 从现象反推故障类型

路由环路在现象层面并不难认，难的是你要在第一眼判断出“这是环路”，而不是误当成链路质量问题或设备性能问题。我习惯先看三个指标：丢包形态、设备 CPU、路由表稳定性。

重点说一下延迟忽高忽低这个特征。环路里的数据包每次经过一台路由器，TTL 就减 1，数据包在环路里兜的圈子越大，时延就越大。而且这个过程不是均匀增加的——同一台 PC 发出的报文，第一个包可能兜了 5 跳，第二个包可能兜了 13 跳，延迟完全不可预测，用户体感就是“卡得要死，但偶尔又能通”。

3.2 三板斧：traceroute、路由表、抓包

确认环路靠三个工具基本就够，我按排查顺序给你捋一遍。

第一板斧是 traceroute。Windows 下用tracert -d，Linux 下建议用traceroute -I -n，因为很多设备不响应 UDP 高位端口，用 ICMP 更可靠。当输出里连续几跳的 IP 地址在两三台设备之间反复出现，比如“R2、R3、R2、R3、R2、R3”，最后以* * *超时结束，基本可以断定这就是环路。TTL 是逐跳递减的，所以你能看到它兜了一圈又一圈，直到耗尽。

第二板斧是路由表。以思科设备为例，重点看show ip route、show ip protocols、show ip rip database。环路出现时，你会看到同一个前缀在不同时间点从不同接口学到，metric 数值变化异常。比如 RIP 路由的 metric 从 2 跳到 3、跳到 4，这说明设备正在“计数到无穷”。华为设备对应看display ip routing-table、display rip 1 route。这里有个细节：如果路由表中的 AD（管理距离）相同、metric 却在持续变大，几乎可以锁定是动态协议环路；如果 AD 不同，则可能是静态与动态策略互相覆盖造成的“策略环”。

第三板斧是抓包。Wireshark 在链路两端的端口上做镜像抓包，重点看两类报文：业务数据流和路由协议报文。业务数据流要看 IP 头里的 TTL 字段，如果同一源地址的报文反复出现、TTL 逐包递减，说明它在环路里不断打转；路由协议报文更直接，RIP 报文里同一个网段的 metric 在一次又一次更新中不断变大，这就是环路形成过程的实锤。顺带说一句，二层的交换环路看 STP 状态和端口计数器，三层路由环路就看 TTL 和路由协议报文，两者不要搞混。

3.3 抓包的两个关键位置和一个关键字段

很多同学第一次抓环路抓不到，不是因为抓包姿势不对，而是抓错了地方。环路是动态路由设备之间的事情，数据帧在环内的两台或多台设备之间打转，你在终端侧、接入交换机侧去抓，大概率什么都看不到，因为那些“回转”的流量根本没有到达你的抓包点。

第一个关键位置是环内两台设备之间的链路上。比如你怀疑 R2 和 R3 之间在互指，就把抓包端口镜像在 R2—R3 这条链路上，这样才能看到同一个报文反复穿梭。

第二个关键位置是环内设备的入接口和出接口，分别抓一遍，对照看同一报文的到达顺序，很快就能判断流量在哪两个设备之间来回。

关键字段则是 IP 头里的 TTL。正常转发路径上，TTL 每一跳只减 1，一路平稳递减。当你在抓包里看到同一个源地址、同一个目的地址的报文，TTL 从 255 快速降到 240、230，甚至出现多个 TTL 值交替出现，那就别犹豫了，这是在环路里消耗生命。

4. 动手复现：模拟器里制造一次路由环路

4.1 实验拓扑与基础配置

纸上谈兵再多，不如亲手复现一次。这个实验用 GNS3 或 EVE-NG 做最合适，没有真机环境的话 Packet Tracer 也可以，只不过 RIP 的实现细节有差异，但看现象足够了。

拓扑很简单：三台路由器 R1、R2、R3 串联，R1 和 R3 后面分别接一台 PC，模拟两个业务网段。地址规划如下：

• R1—R2 互联：192.168.12.0/24，R1 为 .1，R2 为 .2
• R2—R3 互联：192.168.23.0/24，R2 为 .2，R3 为 .3
• R1 连接 PC1 网段：192.168.1.0/24
• R3 连接 PC3 网段：192.168.3.0/24

三台设备都启用 RIPv2，关闭自动汇总。以思科 IOS 为例，R1 的关键配置：

interface GigabitEthernet0/0 ip address 192.168.12.1 255.255.255.0 no shutdown ! interface GigabitEthernet0/1 ip address 192.168.1.1 255.255.255.0 no shutdown ! router rip version 2 no auto-summary network 192.168.1.0 network 192.168.12.0

R2：

interface GigabitEthernet0/0 ip address 192.168.12.2 255.255.255.0 no shutdown ! interface GigabitEthernet0/1 ip address 192.168.23.2 255.255.255.0 no shutdown ! router rip version 2 no auto-summary network 192.168.12.0 network 192.168.23.0

R3 同理，宣告 192.168.23.0 和 192.168.3.0。配置完成后，PC1 去 ping PC3 应该能通，R1 的路由表里能看到192.168.3.0/24 [120/2] via 192.168.12.2，说明流量路径是 R1—R2—R3，跳数 2。

4.2 制造故障，亲眼看到环路

这里我给你两条路线，一条快速见效，一条看协议的本质。

快速路线：直接模拟“默认路由互指”。在 R2 上加一条默认路由指向 R3，在 R3 上加一条默认路由指向 R2：

R2(config)# ip route 0.0.0.0 0.0.0.0 192.168.23.3 R3(config)# ip route 0.0.0.0 0.0.0.0 192.168.23.2

此时从 PC1 去 ping 一个不在路由表里的公网地址，比如 8.8.8.8，你把 traceroute 跑起来，会看到什么？路径会变成 R1 → R2 → R3 → R2 → R3 → R2……在 R2 和 R3 之间反复横跳，直到 TTL 耗尽。这种默认路由互指在生产环境特别常见，尤其是两个出口设备各自下发默认路由，又通过动态协议互相学习时，稍不注意就是一个环。

协议本质路线：做 RIP 计数到无穷。操作步骤是先把 R2 和 R3 之间的水平分割关掉，然后断开 R1 与 R2 之间的链路，或者在 R2 上触发路由刷新。关水平分割的命令：

interface GigabitEthernet0/1 no ip split-horizon

然后在 R2 上开启 debug：

R2# debug ip rip

之后你会在终端里看到类似这样的输出：

RIP: received v2 update from 192.168.23.3 on GigabitEthernet0/1 192.168.1.0/24 -> 2 hops RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/1 192.168.1.0/24 -> 3 hops RIP: received v2 update from 192.168.23.3 on GigabitEthernet0/1 192.168.1.0/24 -> 4 hops

看到这个输出，你是不是对“计数到无穷”有了画面：同一个网段的跳数在 R2 和 R3 之间一次比一次大，1→2→3→4……直到变成 16，路由被标记为不可达。这就是 RIP 环路从产生到终结的全过程。实验做完记得恢复配置，把静态默认路由删掉，把水平分割恢复，别把环路留到明天。

4.3 关于“16 跳”的底层逻辑

很多人第一次看到 RIP 路由 metric 变成 16，第一反应是“设备坏了”。其实 16 跳是 RIP 协议的一种“主动死亡宣告”：任何路由只要跳数达到 16，就代表这台设备认为该网段不可达。

为什么是 15 和 16？因为 RIP 的设计者很清楚，在一个小型网络中，超过 15 跳的路由大概率已经不可用了。他们把 16 作为“无穷大”的数字，让环路在协议层面有一个自我终止的机制。这个设计和 IP 报文头的 TTL 一样，都是给网络的混乱状态兜底的。

理解了这一点，再看 RIP 环路就不会慌：环路不会永远持续下去，它会在跳数涨到 16 的那次更新后终止。但问题是这个“计数到无穷”的过程需要多个更新周期，每个周期 30 秒，从 2 跳到 16 可能要好几轮，而且这期间业务已经完全中断了。所以，千万不要指望协议兜底，你要做的是在它兜底之前主动干预。

5. 故障处置：先止血，再治根

5.1 快速恢复业务的几种手段

真在现场遇到路由环路，第一目标永远是“先把业务保下来”，而不是坐下来慢慢查根因。我按操作速度和破坏性从小到大给你排个序。

第一种，用静态路由覆盖动态路由。RIP 的管理距离是 120，一条普通静态路由的管理距离是 1，优先级远高于动态路由。假如环路出现在去往 192.168.3.0/24 的方向，直接加一条静态：

ip route 192.168.3.0 255.255.255.0 192.168.23.3

这条更优的静态路由会立刻被路由表采用，动态协议的坏路由就算还在协议层来回通告，也不影响实际转发。华为设备对应：

ip route-static 192.168.3.0 24 192.168.23.3

这招速度最快、副作用最小，但它是治标：等故障排查完，记得把静态路由删掉。

第二种，用路由过滤阻断错误通告。如果你能快速判断出是哪个方向的通告在制造环路，可以在接收方向加 distribute-list 或前缀列表，把错误的前缀直接拒掉。思科命令示例：

access-list 1 deny 192.168.3.0 0.0.0.255 access-list 1 permit any router rip distribute-list 1 in GigabitEthernet0/1

但这招要求你准确定位环路的源头，在完全混乱的故障现场需要一定的冷静和判断力。

第三种，直接断开环路链路。如果上述办法都不好使，观察路由表发现某台设备正在把错误路由通告给邻居，直接在通告方向的接口上 shutdown 或者配置 passive-interface，让环路从物理上断掉。代价是这条链路原有的正常业务也会受影响，所以必须有心理准备，这叫“壮士断腕”。

5.2 根因修复：配置审查与变更规范

业务恢复之后，不要以为事就完了。路由环路是一场故障的“果”，前面一定有一个“因”。如果不去除因，下一次故障早晚复现。

最常见的一个因，是 network 语句宣告了不该宣告的网段。有些同学在 Cisco 设备上配置 RIP 时，习惯性地network 0.0.0.0，把直连、环回、业务网段一股脑全宣告出去。本来直连网段宣告给邻居没问题，但如果设备本身有冗余链路或备份路由，就会把“本不该互相通告的路由”也搅进协议里。

另一个常见因，是重分发方向没有控制。前面说过双点双向重分发最容易制造策略环，正确做法是在重分发时用 route-map 控制方向，用 tag 给路由打标记，并在另一个重分发点拒绝带特定 tag 的路由再进入。这就像快递单上写清楚“此单不要退回到发货地”，每个中转站都在源头过滤一遍，环自然无处可藏。

最后一条可能很多人会忽略：任何网络变更都要有验证和回退方案。我自己的习惯是，变更前先show ip route存一份完整截图，改完等 5 分钟，再看一次路由表，同时盯一段时间的日志。如果发现路由在震荡，立刻执行回退脚本，不要试图在深夜的故障现场“现场调优”，那只会扩大故障面。

5.3 一次凌晨割接的教训

说一个我亲身踩过的坑。当时给一家单位的两个机房做出口设备替换，新设备同时启用了 OSPF 和 RIP，两边的边界设备都有重分发策略。我原本以为所有配置都是按标准模板做的，结果割接完成之后，核心交换机的路由表开始出现“灵异现象”：某个办公网段的下一跳，一会儿指向出口 A，一会儿指向出口 B，而且间隔不到五秒就切换一次。

一开始我以为是 OSPF 邻居震荡，看了邻居表，稳定得很。后来发现是 RIP 侧的问题——新一代设备把 OSPF 学到的路由重分发进了 RIP，老设备再把 RIP 路由导回 OSPF，同一段路由在两个协议之间来回“倒手”。因为两边管理距离不同，路由表里表现为 AD 和下一跳不断变化。最终解决是靠 tag：在从 OSPF 导入 RIP 的路由上打上 tag 100，然后在另一个边界设备的 RIP 导入 OSPF 方向加过滤，拒绝携带 tag 100 的路由。

那次割接之后我总结了一条铁律：任何跨协议重分发，必须双向过滤，必须打 tag，缺一不可。你不是在“优化网络”，你是在给未来的自己埋雷。

6. 常见问题排查速查表与避坑清单

6.1 故障场景速查表

我把实际工作中最常遇到的路由环路相关场景整理成一张速查表，遇到问题时直接对照查。

这里特别说一下“路由表正常但业务超时”这种情况。有些环路并不会让路由表立刻变成“反复横跳”，因为设备可能通过等价路径或者策略路由把报文送进了环路，而路由表本身看起来没什么异常。此时抓包看 TTL 是唯一可靠的判断方式，不要因为“路由表看起来正常”就排除环路。

6.2 关于网站“异常流量”提示的一个提醒

写这篇文章之前正好看到有人搜索“我们的系统检测到您的计算机网络中存在异常流量。请稍后重新发送请求”这类提示，说句实在话：如果你只是访问某个网站时看到这个提示，绝大多数情况下是网站侧的安全风控策略触发了，比如出口 IP 被频繁请求、浏览器指纹异常、代理链路被共享等等，跟你自己局域网里的路由环路没有直接关系。

只有当你们网络内部真的有大范围广播风暴或环路，导致出口流量特征明显异常，才可能触发边界安全设备产生类似的告警。但这是“网络先坏了、安全设备报警”的顺序，而不是“安全设备报警导致网络坏”。所以遇到这类提示，先确认本地网络是否真的有异常流量表现，再看是不是出口 IP 被风控，别把锅甩给路由环路。

6.3 独家避坑清单

这几条是我从多次故障里换回来的经验，专门写给在一线排查的人。

第一，生产环境慎用 debug。debug ip rip或debug ip routing在故障定位时确实直观，但 debug 会大幅消耗设备 CPU，在已经因为环路而满载的路由器上，debug 可能直接把设备拖死。我的习惯是先用 show 命令和抓包缩小范围，最后才考虑 debug，而且 debug 时间不超过 30 秒，看完立刻undebug all。

第二，traceroute 的输出要会看。很多情况下你 traceroute 出来某个节点* * *，不代表这里就是环路。防火墙、设备限速策略、ICMP 过滤都会导致节点无响应。你要找的是“同一个 IP 反复出现”的模式，而不是单纯看星号。

第三，抓包之前想清楚抓哪里。抓对位置比抓多久更重要。环路流量只在环内传播，你抓错了链路，抓一整天都看不到异常。

第四，区分“真环”和“次优路径”。次优路径只是绕路，报文不会反复打转，TTL 只会正常递减；而真环路会让 TTL 快速递减，甚至出现 ICMP Time Exceeded 的反馈风暴。TTL 是判断真环和次优路径的金标准，不要看到路径绕路就喊环路。

最后说点实在的。我自己第一次认真研究路由环路，是刚入行时在一个老厂区的网络里，当时一台接入交换机把一条默认路由通告到了核心，核心又把它传给了另一台接入，结果全网一半终端访问互联网都卡成幻灯片。那时候什么都不懂，只会重启设备，重启一次好一阵，过一阵又犯。后来才明白，网络故障从来不是“重启能解决”的，而是“你要能讲清楚数据包到底在哪里打转”。

所以我的建议很直接：每个做网络的人，都应该在模拟器里亲手复现一次路由环路。你在 GNS3 里把默认路由互指配出来，看着 traceroute 在 R2 和 R3 之间来回横跳的那几分钟，比你翻十遍教材都管用。那种“ping 不通但路径图清清楚楚”的顿悟感，才是干这行真正值钱的经验。