企业官网建设流程全解析

OSPF 跑在以太网这类多路访问网段上，如果每台路由器都跟同网段的其他所有路由器建立完整邻接，5 台设备就是 10 条邻接，10 台就是 45 条，LSA 泛洪会变成一场人人喊话的会议。DR 和 BDR 的选举机制就是把这个网状结构收敛成星型：大家只跟主持人交换信息，主持人再统一分发。我见过不少网络在扩容、割接之后出现路由黑洞、设备 CPU 飙高，追到最后都是 DR 选举没提前规划——要么全网优先级都是默认的 1，谁当 DR 全看 Router ID 大小，要么改了优先级以为立刻生效，结果老 DR 一直干到进程重启。这篇就把思科设备上多路访问网络的 DR/BDR 选举规则、配置命令、验证方法，以及我实际踩过的坑一次讲清楚。刚接触 OSPF 的读者可以照着搭实验，已经上手但被"为什么改了优先级不切换"困住的同学也能找到答案。

1. 多路访问网络里为什么必须选DR和BDR

1.1 从邻接关系的数量说开去

先算笔账。一个广播网段里有 n 台路由器，如果不做任何优化，每台路由器都要跟其余 n-1 台建立 Full 邻接，全网邻接总数是 n(n-1)/2。这个增长是平方级的，5 台设备 10 条，10 台设备 45 条，20 台设备就是 190 条。每一条邻接背后都是一整套开销：Hello 保活、数据库描述报文交换、LSR/LSU 请求与更新、重传队列、邻居状态机维护。设备数量一上去，接口带宽和 CPU 都会被这些"内部沟通"吃掉。

更要命的是泛洪逻辑。网段里任何一台路由器收到一条新 LSA，都要向它的所有邻居各复制一份。邻接关系越多，同一条 LSA 在同一个网段里的副本数量就越多，收敛时间也跟着拉长。OSPF 的设计者在这个点上做了一个很务实的取舍：既然大家的信息最终都要同步，那就选一个"汇总人"，让所有人只跟汇总人同步，再由汇总人统一广播出去。这就是 DR（Designated Router，指定路由器）的由来，BDR（Backup Designated Router，备份指定路由器）则是它的热备。

提示：这里的"选举"不是投票制，没有多数票的概念。它是每台路由器根据 Hello 报文里的接口优先级和 Router ID 自行比较、自行收敛的结果，理解这一点对后面排查问题非常关键。

1.2 DR和BDR到底各干什么活

DR 的核心职责有两个。第一，它代表这个广播网段生成 Type 2 的 Network LSA，这条 LSA 里列出了该网段上所有路由器的 Router ID 和 DR 自己的接口地址，让区域内的其他路由器知道"这个网段上挂着哪些人"。第二，它作为该网段的泛洪中心，把收到的更新以组播 224.0.0.5 发给网段内所有 OSPF 路由器。

BDR 的职责容易被误解成"什么都不干等着接班"。实际上 BDR 必须跟网段内所有 DROTHER 建立 Full 邻接，同步完整的链路状态数据库。它监听 224.0.0.6 这个 AllDRouters 组播地址，把 DR 收到的每一条更新都收下来。正因为数据库是热的，DR 一旦失效，BDR 能在 Dead Timer 到期后立刻接管，不需要重新同步数据库，收敛时间被压到最短。如果 BDR 平时不同步，切换时就得从头来一遍，那这个备份就形同虚设了。

DROTHER 之间的状态是 2-Way，不是 Full，这点新手经常看错。它们互相能收到对方的 Hello，知道对方存在，但不交换数据库描述报文。所有 DROTHER 只跟 DR 和 BDR 建立 Full 邻接。数据层面的组播地址分工也很清晰：DROTHER 发更新用 224.0.0.6，只有 DR 和 BDR 收；DR 发更新用 224.0.0.5，所有人都收。

1.3 哪些网络类型参与选举，哪些压根不投票

不是所有 OSPF 网络类型都会选 DR。搞混这一点，会在排查时绕很大弯路。下面这张表是我自己整理的对照，日常查起来比翻文档快。

点到点网络不选举的理由很直白：只有两端，没有第三方，星型收敛没有意义，直接建 Full 邻接最简单也最快。点到多点则是把一条物理链路在逻辑上拆成多条点对点，每对邻居单独建邻接，同样不需要 DR。

真正容易出问题的是"网络类型配置不一致"。一端配成 broadcast，另一端配成 point-to-point，Hello 和 Dead 定时器对不上，邻居根本起不来。我在一个割接项目里遇到过，两端都是串口，一边沿用了老模板配了 ip ospf network point-to-point，另一边是默认的 non-broadcast，结果邻居卡在 INIT 一直不动，查了快两个小时才发现是网络类型不匹配。

2. 选举规则拆解：优先级、Router ID与不可抢占

2.1 两轮比较：先看接口优先级，再看Router ID

DR 的选举就两轮比较，逻辑非常干脆。第一轮比接口优先级，这是接口级参数，取值范围 0 到 255，默认值是 1，通过ip ospf priority配置。优先级最高的那台成为 DR，第二高的成为 BDR。第二轮是在优先级相同时比 Router ID，数值大的胜出。Router ID 是路由器级参数，取值来源有优先级顺序：手工配置的router-id最高优先，其次是 Loopback 接口里 IP 最大的那个，最后才是物理接口里 IP 最大的那个。

举个具体例子。四台路由器在同一网段，R1 优先级 200、RID 1.1.1.1；R2 优先级 100、RID 2.2.2.2；R3 和 R4 优先级都是默认 1，RID 分别是 3.3.3.3 和 4.4.4.4。结果就是 R1 当 DR，R2 当 BDR，R3 和 R4 是 DROTHER。假如 R1 和 R2 优先级都配成 100，那 R2 因为 RID 更大（2.2.2.2 > 1.1.1.1）反而会成为 DR，R1 降为 BDR。这个细节在做"指定主备"的时候经常被忽略，光配了相同优先级，以为先配的先赢，实际是 RID 说了算。

还有一层容易混淆：Router ID 是整个 OSPF 进程内唯一的，但 DR/BDR 的身份是接口级的。同一台路由器，G0/1 接口上可能是 DR，G0/2 接口上可能是 DROTHER，两者互不影响。每个广播网段独立进行一轮选举，各选各的。

2.2 Wait Timer与选举时机：改完配置为什么没反应

这是 DR 选举里最容易让人抓狂的部分，也是我被问得最多的一个问题。核心结论：OSPF 的 DR/BDR 选举是"不可抢占"的。

具体过程是这样的。一台路由器在广播接口上启动 OSPF 后，会进入一个 Wait Timer，默认等于 Dead Timer，也就是 40 秒。在这 40 秒里，它持续发 Hello、收 Hello，但不急着宣布自己是 DR。如果 40 秒内没有收到任何声称自己是 DR 的 Hello，它就认为这个网段还没有 DR，自己顶上。这 40 秒的等待就是防止设备重启后造成不必要的选举震荡。

一旦选举完成，格局就固化了。此时新加入一台优先级更高的路由器，它会在 Hello 里宣告自己的优先级，现有 DR 也能看到，但大家都不会主动让位。只有现有的 DR 失效——Dead Timer 到期、接口 down、或者进程重启——才会触发新一轮选举，这时候新来的高优先级设备才有机会上位。

注意：这就是"改了优先级不生效"的根本原因。配置本身是立即写进 Hello 报文的，但选举结果要等下一次选举事件才会改变。不要以为是配置没敲对，反复敲命令是没用的。

这个设计的好处在稳定性，坏处是变更不直观。所以规划阶段就要把 DR 的位置定好，别指望上线后随时调。我的习惯是在设计文档里直接写明每个广播网段的 DR 应该是谁，对应的优先级和 RID 一起写清楚，施工时一次性配到位。

2.3 优先级0的真实语义和几个高频误解

ip ospf priority 0的含义是"这台路由器永远不参与 DR/BDR 选举"，它会被强制固定在 DROTHER 角色。这个配置在实际工作中很有用，比如某些只作为接入的路由器，不需要承担泛洪中心的职责，就可以把优先级设成 0，把 DR 的位置留给核心设备。

关于这个 0，有几个高频误解值得单独说。第一个误解是"优先级 0 表示最低优先级，还是有可能被选上"。不是的，0 是硬性排除，不是排序里的最小值，数学上是"退出竞选"。第二个误解是"优先级设得很高（比如 255）就一定能抢到 DR"。在已经收敛的网段里，高优先级同样抢不了，还是受不可抢占规则约束。第三个误解是"优先级 0 的路由器还能当 BDR"。也不行，DR 和 BDR 是从同一个候选池里选出来的，优先级 0 直接出局。

还有一个更隐蔽的认知偏差：有人以为 DR 是"路由计算中心"，所有 SPF 都由 DR 算好了再分发。完全不是。每一台路由器都会独立运行 SPF 算法、独立维护 LSDB，DR 只影响 LSA 的泛洪拓扑结构，不参与路由计算的分工。搞清这一点，就不会在 DR 切换后看到"路由需要重算"时觉得奇怪了——重算是必然的，因为 Type 2 LSA 换了生成者。

3. 配置实操：搭一个能看清楚选举过程的小实验

3.1 拓扑与地址规划

想看明白选举过程，至少需要三台路由器，因为两台设备的场景下必定一主一备，看不出 DROTHER 之间的 2-Way 状态。我用四台路由器接同一台二层交换机来搭，这个结构最接近实际的企业网接入层。

地址规划如下：R1 的 G0/1 配 10.1.1.1/24，Loopback0 配 1.1.1.1/32；R2 的 G0/1 配 10.1.1.2/24，Loopback0 配 2.2.2.2/32；R3 的 G0/1 配 10.1.1.3/24，Loopback0 配 3.3.3.3/32；R4 的 G0/1 配 10.1.1.4/24，Loopback0 配 4.4.4.4/32。四台设备都在 Area 0。

实验的目标分三步走：第一步全用默认配置，看选举结果是不是按 RID 大小排；第二步手工调优先级，验证"不抢占"这个特性；第三步人为让 DR 失效，观察 BDR 接管和高优先级设备上位的过程。这三步走完，选举机制的每个细节都能亲眼看到。

3.2 接口优先级与OSPF进程的命令清单

先看 R1 的完整配置，其他三台照抄改地址即可。

R1(config)# interface Loopback0 R1(config-if)# ip address 1.1.1.1 255.255.255.255 R1(config-if)# exit R1(config)# interface GigabitEthernet0/1 R1(config-if)# ip address 10.1.1.1 255.255.255.0 R1(config-if)# no shutdown R1(config-if)# ip ospf priority 200 R1(config-if)# exit R1(config)# router ospf 1 R1(config-router)# router-id 1.1.1.1 R1(config-router)# network 10.1.1.0 0.0.0.255 area 0 R1(config-router)# network 1.1.1.1 0.0.0.0 area 0

ip ospf priority是接口下的命令，配在哪个接口就影响哪个网段的选举，这点要记牢。有人在全局配了一遍发现没效果，就是找错了位置。router-id建议养成手工指定的习惯，这一点我要重点强调。

不手工指定 RID 的隐患在于：OSPF 选择 RID 的顺序是先看有没有手工配置，没有就选 Loopback 里最大的 IP，再没有就选物理接口里最大的 IP。如果 RID 是靠物理接口选出来的，某个接口 down 掉，RID 可能就变了。RID 一变，这台路由器在邻居眼里的身份就变了，所有邻居关系会被重置，LSDB 重新同步，网段上还可能触发一轮新的 DR 选举。生产环境里这种"莫名其妙断一下"的事故，不少都是 RID 不稳定造成的。

另外提一句，多数 IOS 版本里配置router-id之后需要重启 OSPF 进程才真正生效，敲完命令用show ip ospf看一眼当前 RID 是不是你配的那个，别想当然。

3.3 用show命令把选举结果读明白

配置完成后，在 R1 上执行接口状态查看命令，输出的关键几行是这样：

R1# show ip ospf interface GigabitEthernet0/1 GigabitEthernet0/1 is up, line protocol is up Internet Address 10.1.1.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1 Transmit Delay is 1 sec, State DR, Priority 200 Designated Router (ID) 1.1.1.1, Interface address 10.1.1.1 Backup Designated Router (ID) 2.2.2.2, Interface address 10.1.1.2 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Neighbor Count is 3, Adjacent neighbor count is 3 Adjacent with neighbor 2.2.2.2 (Backup Designated Router) Adjacent with neighbor 3.3.3.3 Adjacent with neighbor 4.4.4.4

读这段输出要抓几个点。State DR说明本接口角色，Priority 200是当前接口优先级。Designated Router和Backup Designated Router两行显示的是当前网段公认的结果，注意这里显示的 ID 是 Router ID，后面的 Interface address 才是接口 IP。Hello 10, Dead 40, Wait 40三个定时器里，Wait 等于 Dead，正是前面讲的等待期。Adjacent neighbor count is 3表示有三条邻接达到 Full，括号标注的那条是 BDR。

再看 R2 的邻居表，这里的对比信息最有价值：

R2# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 200 FULL/DR 00:00:32 10.1.1.1 GigabitEthernet0/1 3.3.3.3 1 FULL/DROTHER 00:00:37 10.1.1.3 GigabitEthernet0/1 4.4.4.4 1 2WAY/DROTHER 00:00:39 10.1.1.4 GigabitEthernet0/1

R2 自己是 BDR，所以它跟 DR（R1）是 Full，跟 R3 是 Full，跟 R4 是 2WAY。R3 和 R4 都是 DROTHER，互相之间只有 2WAY。这一段经常被误判成故障，其实完全正常。判断标准很简单：只要每个 DROTHER 跟 DR 和 BDR 都是 Full，整体就是健康的。

想看 Type 2 LSA 是谁生成的，执行show ip ospf database network，能看到 Link ID 是 DR 的接口地址（10.1.1.1），Advertising Router 是 DR 的 RID（1.1.1.1），LSA 正文里挂着四台路由器的 RID。DR 一旦切换，这条 LSA 的 Link ID 和 Advertising Router 都会跟着变，SPF 也会重算一次。

3.4 让选举立刻生效的几种做法与各自代价

如果确实需要马上把 DR 换掉，可选的手段不多，每一种都有代价，得权衡。

第一种，clear ip ospf process。敲完会提示确认：

R1# clear ip ospf process Reset ALL OSPF processes? [no]: yes

这个命令重置的是整台设备的 OSPF 进程，该设备上所有 OSPF 接口、所有区域的邻居关系全部重建。如果这台设备是多区域边界，影响面会很大，路由会抖动几秒到几十秒。除非在维护窗口，我不建议在网络高峰期这么干。

第二种，接口 shutdown 再 no shutdown。影响范围只限这个接口，比清进程温和得多，代价是这个网段的邻居会短暂中断，并且会触发一次本网段的重新选举。

第三种，让老 DR 的优先级降下来，然后等。听起来很优雅，实际不解决问题——降优先级同样不触发抢占，还得等老 DR 失效。所以这个方案只在"下次选举时不想让它再当选"这个场景下有意义。

第四种，在下游做流量牵引，或者干脆接受现状、把变更排到维护窗口。我个人的做法是后者，DR 切换虽然影响不算大，但会引起全网段 SPF 重算，在大型网络里还是可能造成短暂的路由黑洞，值得谨慎。

提示：真正正确的做法是"事前规划"。DR 的位置在设计阶段就定死，配置模板里把优先级和 RID 一起固化，别让它上线后随机漂移。

4. 特殊网段：NBMA、点对多点与共享介质上的选举差异

4.1 NBMA网络：手动指定邻居，让Hub坐稳DR位

非广播多路访问网络（NBMA）不支持下组播和广播，OSPF 报文得靠单播发，所以邻居必须手工指定。在 router ospf 进程下用neighbor命令，还可以顺便指定对方的优先级：

R1(config)# router ospf 1 R1(config-router)# neighbor 10.1.1.2 priority 10 R1(config-router)# neighbor 10.1.1.3 priority 5

这里有个容易被忽略的关键点：在 Hub-Spoke 结构里，Hub 必须是 DR。原因是 OSPF 把 NBMA 当成一个广播网段来看待，SPF 计算时会认为所有 Spoke 之间是直连的，下一跳直接指向对端接口地址。但实际物理拓扑里 Spoke 之间没有直连链路，流量必须经过 Hub 中转。如果 DR 选到了某个 Spoke 上，Type 2 LSA 由它生成，其他 Spoke 拿到的下一跳信息可能就不对，直接表现就是部分 Spoke 之间通、部分不通，或者时通时不通。

解决办法就是在 Hub 上把接口优先级调高，确保它稳定当选。同时别忘了 NBMA 的 Hello 是 30 秒、Dead 是 120 秒，Wait 也是 120 秒，比广播网络慢得多，割接后要有耐心等它收敛。

4.2 点对多点与点对多点非广播：压根不选

把接口网络类型改成 point-to-multipoint，选举就彻底不发生了：

R1(config)# interface Serial0/0 R1(config-if)# ip ospf network point-to-multipoint

这种模式下，OSPF 把共享网段逻辑上拆成一堆点对点链路，每条链路单独建邻接，每台邻居生成一条 /32 的主机路由。好处是配置简单、不需要全互联、不需要操心 DR 位置；代价是路由表条目变多，LSA 数量增加，在大规模网络里对设备资源有一定压力。

如果链路本身不支持组播，还得改成 point-to-multipoint non-broadcast，配合手工neighbor命令。这种类型同样不选举。

4.3 交换机堆叠/级联环境下的隐蔽问题

最后说说二层环境带来的干扰。广播域是由交换机划定的，同一个 VLAN 内的所有端口共享一个广播域，也就共享一次 DR 选举；不同 VLAN 属于不同网段，各自独立选举。这个道理简单，但实际操作里有几个坑。

一是子接口。路由器如果通过 trunk 接交换机、划了多个子接口，每个子接口是独立的广播网段，各自有一轮选举。有人只在主接口上配了优先级，以为子接口会继承，实际不会，子接口得单独配。

二是二层收敛。如果交换机之间的级联链路不稳定、STP 反复收敛，Hello 报文会丢。丢几个 Hello 不致命，但连续丢满 Dead Timer（默认 40 秒），邻居就会被判定失效，触发 DR 重新选举。等链路恢复，原来的 DR 变回 DROTHER，Type 2 LSA 换人生成，全网段 SPF 再算一遍。这种"周期性抖动"极难排查，因为从三层看就是毫无规律的邻接中断。查的时候一定要往二层看，看接口有没有 CRC 错误、有没有 STP 拓扑变更记录。

三是 MTU 不一致。同网段内各接口 MTU 不同，数据库描述报文交换会卡在 EXSTART 或者 EXCHANGE 状态，邻接建不起来，选举结果自然也不对。这类问题在跨厂商设备混接的环境里比较常见，建议在接口上统一 MTU，或者干脆用ip ospf mtu-ignore临时绕过。

5. 排障实录：DR/BDR相关故障与速查表

5.1 双DR、无DR、邻接卡2-Way分别意味着什么

双 DR 基本不可能出现在同一个广播域里，OSPF 的收敛机制保证了任一时刻一个网段只有一个 DR。如果你同时看到两个接口都显示 State DR，先确认它们是不是同一个网段——十有八九是地址规划错了，两台设备配了不同子网，压根不在一个广播域。要么就是划在了不同 OSPF 进程里，进程之间互不感知，各选各的。

无 DR 是真实存在的故障。典型现象是show ip ospf interface里状态长期停在 DROTHER，或者显示等待中，网段内一条 Type 2 LSA 都没有。最常见的原因是所有参与设备的接口优先级都被设成了 0——可能是照抄了某个"接入层模板"，结果整段都没人能当 DR。这种情况下该网段的路由收敛会出问题，直连网段的路由还在，但经过该网段转发的路径可能算不出来。排查方法很直接，逐台看接口优先级。

邻接卡在 2-Way 要分情况。如果网段里有三台以上路由器，DROTHER 之间 2-Way 是设计如此，不用管。但如果只有两台路由器，状态还是 2-Way，那就有问题——正常情况应该是互为 DR/BDR、状态 Full。这时候先查优先级是不是有一方配了 0，再查双方网络类型是不是一致。

5.2 优先级不生效的五种可能

第一种，也是最多的，不可抢占。改完优先级不切换是正常行为，不是配置错误。要让它生效，必须等下一次选举事件。

第二种，配错了接口。在有子接口的环境里，优先级要配在真正承载 OSPF 的那个子接口上，配在物理主接口上不生效。

第三种，Router ID 冲突。两台设备手工配了相同的 router-id，邻居关系会反复建立又断开，选举结果一片混乱。这种情况在show ip ospf neighbor里能看到邻居状态不断跳变，日志里会有明确的 RID 冲突提示。

第四种，比错了对象。优先级和对方一样时，比的是 RID。配了 100，对方也是 100，但对方 RID 更大，那对方当选，你看到的现象就是"我优先级明明调高了却没当上 DR"。

第五种，网络类型不是广播。接口如果是 point-to-point 或 point-to-multipoint，压根不选举，配多少优先级都是摆设。先用show ip ospf interface看一眼 Network Type 那一行。

5.3 故障速查表与我的避坑清单

最后分享几条我自己总结的避坑要点。第一，永远手工指定 Router ID，别让它依赖接口状态自动选出来，这是所有诡异问题的源头之一。第二，DR 的位置在规划阶段就写进配置模板，别指望上线后现场调，因为调不动。第三，NBMA 和 Hub-Spoke 结构里，Hub 的优先级一定要显式配高，靠 RID 大小碰运气是最不稳的做法。第四，变更前先想清楚影响面，clear ip ospf process会重置整台设备的所有 OSPF 邻居，不是只影响一个网段，这条命令在高峰期用过一次就长记性了。

我在实际项目里最看重的一点是：DR 选举这块看起来是个小配置，但它牵动的是整个网段的 LSA 泛洪拓扑，一旦 ER 位置漂移，全网段的 SPF 都要重算。所以与其事后补救，不如在开局就把优先级和 RID 一起固化进模板，让它从一开始就待在该待的位置上，后面几年都不用再操心这件事。