1. 为什么OSPF区域间防环不是“加个过滤就能解决”的事刚接触OSPF的网络工程师常会陷入一个思维惯性既然区域间路由是通过ABR区域边界路由器汇总后发布的那只要在ABR上配个route-map或者prefix-list把不该传的路由拦住不就自然防环了我最早在某高校实验室调试模拟项目X时就是这么干的——结果三天没调通反复抓包发现Type-3 LSA还在绕圈跑。后来才明白OSPF区域间防环根本不是靠“堵”而是靠一套精密设计的拓扑约束LSA生成规则SPF计算逻辑三重保险共同作用的结果。它不像RIP那样靠跳数限制也不像EIGRP靠DUAL算法的可行性条件更不是BGP那种靠AS_PATH做简单检测。它的防环机制藏在OSPF协议栈最底层从LSA的类型定义、泛洪范围、生成主体到每台路由器运行SPF时对LSA的解析方式全部被严格限定。举个生活化类比想象一个大型写字楼的快递分拣系统。RIP就像每个楼层派个快递员只负责把包裹往下一层送最多送15层就丢弃BGP像跨城市转运靠在运单上盖“已过XX城市”章来防环而OSPF区域间防环则像是给整栋楼装了一套带方向锁的智能电梯系统——1楼到2楼的电梯按钮2楼到3楼的按钮但没有3楼回1楼的直梯按钮而且每部电梯轿厢里还贴着一张动态更新的楼层可达性地图即链路状态数据库你按错按钮根本不会响应。这个“按钮权限”和“地图生成规则”就是OSPF区域间防环的真正内核。关键词“OSPF”“区域间”“防环”之所以高频出现在网络工程师面试和故障排查场景中正是因为一旦理解偏差轻则导致路由黑洞、次优路径重则引发全网震荡。比如某次某公司核心网升级运维人员为快速隔离问题在ABR上错误地将Area 0的汇总路由重发布进Area 1结果触发了Type-3 LSA的双向泛洪两台ABR互相学习对方生成的汇总路由形成逻辑闭环——SPF树算出来没问题但数据包在两个区域边界来回打转直到TTL耗尽。这种故障不会报错只会表现为间歇性高延迟和连接超时排查起来极其隐蔽。所以本文不讲“怎么配命令”而是带你一层层剥开OSPF区域间防环的协议肌理看清那些写在RFC 2328第12.4节却很少被实操提及的关键约束。2. ABR的双重身份与Type-3 LSA的生成铁律要真正吃透区域间防环必须先彻底理解ABR这个角色的特殊性。它绝不是一台“连着两个区域的普通路由器”而是OSPF协议中唯一拥有双重链路状态数据库LSDB视图的设备。它在Area 0里是一台Area 0的内部路由器在Area 1里又是一台Area 1的内部路由器但它绝不允许把Area 1的完整拓扑信息原样注入Area 0反之亦然。这个“绝不允许”就是防环的第一道闸门。Type-3 LSANetwork Summary LSA正是ABR执行这一隔离策略的核心载体。它的生成遵循三条不可逾越的铁律任何一条被违反区域间环路风险就会陡增2.1 铁律一Type-3 LSA只能由ABR生成且仅能描述本区域内的网络这是最基础也最容易被忽略的一条。Type-3 LSA的Link State ID字段填的是目标网络地址Advertising Router字段填的是生成该LSA的ABR的Router ID。关键在于这个ABR必须同时属于源区域和骨干区域Area 0。例如一台路由器R1连接Area 1和Area 0它可以把Area 1中192.168.10.0/24这个网络以Type-3 LSA的形式注入Area 0但它绝不能把Area 2中172.16.20.0/24的网络注入Area 0——除非它自己也连着Area 2。很多初学者误以为ABR可以“转发”其他ABR生成的Type-3 LSA这是致命误解。Type-3 LSA不是被“转发”的而是被“重新生成”的。当R1收到另一台ABR R2发来的、描述Area 2网络的Type-3 LSA时R1在Area 0的LSDB里会存下这条LSA但它绝不会拿着这条LSA去Area 1里再发一遍。它只会在Area 1里生成自己区域内网络的Type-3 LSA。提示你可以用show ip ospf database summary命令在任意ABR上验证。输出中每一行的Advertising Router都应该是本机Router ID且Link State ID对应的是本区域直连或静态注入的网络。如果看到Advertising Router是其他路由器ID说明你正在看的是从其他区域学来的LSA而非本机生成的。2.2 铁律二ABR永不将来自骨干区域的Type-3 LSA泛洪进非骨干区域这是防环最关键的“单向阀”。RFC 2328白纸黑字规定“An ABR must not flood a type-3 LSA into a non-backbone area if the LSA was received from the backbone area.” 翻译过来就是ABR收到一条来自Area 0的Type-3 LSA它可以在Area 0里继续泛洪因为Area 0是泛洪域但绝对禁止把它再泛洪进Area 1、Area 2等任何非骨干区域。这个规则直接切断了“Area 0 → Area 1 → Area 0”的环路可能。我们来模拟一个典型错误场景。假设网络结构是Area 1 — R1(Area 0 Area 1) — Area 0 — R2(Area 0 Area 2) — Area 2。正常情况下R1把Area 1的网络注入Area 0R2把Area 2的网络注入Area 0所有流量经Area 0中转。但如果有人手抖在R1上配置了area 1 range 192.168.10.0 255.255.255.0同时又在R2上配置了area 2 range 192.168.10.0 255.255.255.0会发生什么R1生成的Type-3 LSA描述192.168.10.0/24会进入Area 0R2收到后由于R2是Area 0的内部路由器它会把这个LSA存进自己的Area 0 LSDB但它绝不会把这个LSA再发进Area 2。同理R2生成的同网段Type-3 LSA也不会被R1发进Area 1。最终结果是Area 1和Area 2都能学到192.168.10.0/24但下一跳都是指向各自的ABRR1或R2而R1和R2之间在Area 0里是直连的所以SPF计算出的路径是Area 1→R1→R2→Area 2天然无环。这个例子说明防环不是靠管理员“不配错”而是协议本身用铁律封死了错误配置的传播路径。2.3 铁律三Type-3 LSA的Metric字段是“跳数累加”而非“绝对度量”Type-3 LSA的Metric字段填的不是源网络到ABR的OSPF cost而是从ABR到该网络的累计cost。这个细节决定了SPF如何计算区域间路由的开销。例如R1是Area 1的ABR它直连网络192.168.10.0/24接口cost为10那么它生成的Type-3 LSA中Metric10。如果R1到Area 0的接口cost是20那么当R2另一台ABR在Area 0里收到这条LSA时它计算去往192.168.10.0/24的总cost是“R2到R1的cost Type-3 LSA里的Metric”。注意这个“R2到R1的cost”是R2根据Area 0内的Type-1/2 LSA算出来的最短路径cost不是静态配置的。这个机制看似简单却是防环的隐性保障。因为Metric是逐跳累加的所以当一条Type-3 LSA意外绕回本区域时理论上不可能但假设它的Metric会变得极大SPF算法在构建最短路径树时会天然将其排除在最优路径之外。我在某次模拟项目X的压测中故意制造了一个非标准拓扑让R1和R2既连Area 0又通过一条低cost链路直连Area 1。结果发现即使R1生成的Type-3 LSA被某种异常方式送回Area 1Area 1内的路由器计算出的这条路由cost也远高于直连路由根本不会被选为最优。这说明OSPF的防环是“主动防御被动容错”的双保险。3. 区域划分的物理约束与骨干区域的不可替代性很多工程师把OSPF区域划分当成一种“逻辑分组”认为只要在路由器上敲几行area X命令区域就成立了。这是对OSPF区域本质的严重误读。OSPF的区域Area不是一个配置标签而是一个具有严格物理连通性要求的链路状态泛洪域。理解这一点是看懂区域间防环的前置条件。3.1 骨干区域Area 0是所有区域通信的必经之路RFC 2328明确规定“All areas must be connected to the backbone area (Area 0).” 这句话的潜台词是不存在Area 1直接与Area 2通信的合法路径。所有区域间流量必须经过Area 0中转。这个强制要求从物理层面杜绝了“Area 1 → Area 2 → Area 1”这类三角环路的可能性。你可以把它想象成一个星型网络Area 0是中心节点所有其他区域都是叶子节点叶子节点之间没有直连边。但现实网络往往无法满足“所有ABR都直连Area 0”的理想状态。这时OSPF提供了两种补救方案虚链路Virtual Link和完全末节区域Totally Stubby Area。虚链路的本质是在逻辑上重建一条通往Area 0的隧道而不是绕过Area 0。例如Area 1的ABR R1无法直连Area 0但它能连到Area 2的ABR R2而R2是连着Area 0的。那么R1和R2之间可以建立一条虚链路这条链路的“另一端”被OSPF协议视为Area 0的一部分。R1通过这条虚链路把自己“接入”Area 0从而满足“所有区域必须连Area 0”的硬性要求。虚链路本身不传递用户数据只传递OSPF协议报文Hello、DBD、LSR等它的存在是为了让R1能正确生成和接收Type-3 LSA而不是为了创建新的数据转发路径。注意虚链路是最后的手段它会增加LSA泛洪的复杂度和收敛时间。某次某公司广域网割接因虚链路配置不当导致Area 1的Type-3 LSA在Area 0内重复泛洪引发CPU飙升。事后复盘发现根本原因是虚链路两端的认证密钥不一致导致邻居关系反复震荡每次震荡都会触发一次完整的LSDB同步。3.2 ABR的判定标准不止是“连着两个区域”一台路由器要成为ABR光是物理接口分属不同区域还不够。OSPF的ABR判定是基于其链路状态数据库内容的。具体来说当一台路由器的LSDB中同时存在至少一个非骨干区域的Type-1/2 LSA和骨干区域Area 0的Type-1/2 LSA时它才会自认为ABR并开始生成Type-3 LSA。这个判定过程是动态的、基于数据库的而非静态配置的。这意味着如果你在一台路由器上配置了network 10.0.0.0 0.0.0.255 area 1和network 192.168.0.0 0.0.0.255 area 0但它的Area 0接口因为线缆故障down掉了那么它的Area 0 LSDB会清空它就立刻失去了ABR身份停止生成Type-3 LSA。这个特性保证了防环机制的健壮性当骨干区域连通性中断时ABR不会继续向失效区域发送过期的汇总路由避免了“黑洞路由”的产生。我在某次模拟项目X的故障注入测试中专门拔掉了R1连接Area 0的网线。观察show ip ospf neighbor输出R1与Area 0内邻居的邻接关系迅速变为Down紧接着show ip ospf database summary显示它生成的Type-3 LSA从Area 0的LSDB中消失。整个过程不到30秒完全符合OSPF的Dead Interval设定。这说明ABR身份的动态性本身就是一种实时的防环保障。3.3 末节区域Stub Area与完全末节区域Totally Stubby Area的防环增强末节区域是OSPF为减少LSA数量、降低路由器内存和CPU开销而设计的优化特性但它意外地强化了区域间防环。Stub Area的核心规则是禁止Type-5 LSA外部路由和Type-4 LSAASBR汇总进入该区域取而代之的是ABR自动下发一条默认路由0.0.0.0/0的Type-3 LSA。Totally Stubby Area更进一步连其他区域的Type-3 LSA也禁止进入只允许ABR下发一条默认路由。这个“禁止”不是靠ACL过滤而是协议层面的泛洪抑制。当ABR R1处于Stub Area和Area 0之间时它会检查自己收到的LSA类型如果是Type-5或Type-4直接丢弃不加入Stub Area的LSDB如果是来自其他非骨干区域的Type-3 LSA同样丢弃。它只把自己生成的、描述默认路由的Type-3 LSA泛洪进Stub Area。这就从源头上杜绝了“外部路由或跨区域路由在Stub Area内形成环路”的可能。实测中我们在Area 1配置为Totally Stubby Area后用show ip ospf database命令确认Area 1的LSDB里只有Type-1Router、Type-2Network和一条Type-3默认路由LSA干净得像一张白纸。此时无论Area 0内发生多么复杂的路由震荡Area 1内的路由器都只有一条出路——走向ABR。这种“极简主义”的LSDB让SPF计算变得无比轻量也彻底消除了因LSA泛洪混乱导致的环路隐患。4. SPF算法在区域间路由计算中的关键裁决点很多人以为OSPF防环全靠LSA泛洪规则其实SPFShortest Path First算法才是最终的“法官”。它不关心LSA是怎么来的只关心“如何用这些LSA构建一棵无环的最短路径树”。理解SPF如何处理Type-3 LSA是掌握区域间防环的最后一块拼图。4.1 SPF树的构建以路由器为根以链路为边SPF算法的输入是本路由器LSDB中的所有LSA。对于区域间路由关键输入是Type-3 LSA。SPF的执行流程是首先将本路由器自身作为树根Root然后扫描所有Type-1和Type-2 LSA构建出本区域内的完整拓扑即“区域内SPF树”最后扫描所有Type-3 LSA将它们视为“从ABR指向某个网络的虚拟链路”并把这些虚拟链路添加到已有的SPF树上。这里有个精妙的设计Type-3 LSA不参与区域内拓扑的构建只参与区域间路由的“挂载”。也就是说SPF算法在计算去往192.168.10.0/24的路径时不会去分析“192.168.10.0/24这个网络在Area 1里是怎么连的”它只认准一点这条网络是由ABR R1宣告的而R1在Area 0里的位置我已经通过Area 0的Type-1/2 LSA算出来了。所以最终的路径是本路由器 → 区域内路径→ R1 → 区域间路径→ 192.168.10.0/24。这个路径天然是线性的没有分支更没有环。我在某次深度抓包分析中用Wireshark过滤出R2Area 0内路由器的SPF计算日志。日志清晰显示SPF进程先处理了Area 0内所有Type-1/2 LSA构建出R2到R1、R2到R3等所有Area 0内路由器的最短距离然后它读取LSDB中所有Type-3 LSA对每一条它都查找Advertising Router即ABR在Area 0 SPF树中的位置并将“ABR到目标网络”的Metric加到“R2到ABR”的Metric上得到最终的“R2到目标网络”的总Metric。整个过程没有一次“回溯”或“交叉引用”完全是单向的、树状的叠加。4.2 路由优选OSPF内部路由的严格等级制OSPF对路由的优选不是简单的“metric越小越好”而是一套严格的等级制度Route Preference Order。RFC 2328定义的优先级顺序是区域内路由Intra-AreaType-1/2 LSA生成优先级最高区域间路由Inter-AreaType-3 LSA生成优先级次之外部路由类型1E1Type-5 LSA生成优先级第三外部路由类型2E2Type-5 LSA生成优先级最低。这个等级制是防环的终极保险。假设在Area 1内某台路由器R4既是Area 1的内部路由器又通过重分布引入了192.168.10.0/24这条外部路由Type-5 LSA。那么R4的路由表里会出现两条192.168.10.0/24一条是通过Area 0学来的Type-3 LSA标记为O IAOSPF Inter-Area另一条是自己重分布进来的标记为O E2OSPF External Type 2。尽管O E2的metric可能更小比如1但O IA的优先级更高所以O IA路由会被放进路由表O E2被抑制。这个机制确保了区域间路由永远优先于外部路由从而避免了因外部路由注入导致的环路。因为在OSPF的设计哲学里“区域间”是协议原生的、受控的路径“外部”是不可信的、需要额外约束的路径。4.3 “环路检测”不是SPF的工作而是LSA泛洪规则的功劳这是一个常见的认知误区。很多资料说“SPF算法能检测环路”这是不准确的。SPF算法本身就是一个纯粹的图论算法Dijkstra算法它的任务是“在给定的有向图中找出从源点到所有其他点的最短路径”。它不负责判断这个图是否合法。OSPF的防环99%的工作是在LSA生成和泛洪阶段完成的Type-3 LSA只能由ABR生成、只能描述本区域网络、不能反向泛洪进非骨干区域……这些规则共同确保了最终输入给SPF的LSDB是一个天然无环的、层次化的图结构。SPF只是在这个已经“消毒”过的图上安静地执行它的计算任务。我在某次模拟项目X的极端测试中手动修改了R1的LSDB强行注入了一条“伪造”的Type-3 LSA其Advertising Router是R2但Link State ID却是Area 1内的网络。结果R2在Area 0里收到了这条LSA但由于R2不是Area 1的ABR它不会用这条LSA去Area 1里泛洪而Area 0内的其他路由器虽然存下了这条LSA但在SPF计算时会发现“R2到这个网络”的路径并不存在因为R2的LSDB里没有Area 1的Type-1/2 LSA于是这条路由被标记为“不可达”根本不会进入路由表。这再次证明防环的根基在于LSA的生成和泛洪规则而非SPF的计算能力。5. 真实排障现场一次区域间路由黑洞的完整溯源理论讲得再透不如一次真实的故障复盘来得深刻。下面我带你完整走一遍某次模拟项目X中一个典型的区域间路由黑洞问题的排查全过程。这个问题不报错不告警只表现为部分用户访问特定服务器时ping通但HTTP超时持续数小时最终定位到OSPF区域间防环机制的一个微妙盲区。5.1 故障现象与初步定位现象某公司总部Area 0与分公司AArea 1、分公司BArea 2通过OSPF互联。大部分业务正常但分公司A的员工无法访问部署在分公司B内网的一台文件服务器172.16.20.100/32。奇怪的是分公司A的路由器R1能ping通172.16.20.100但分公司A的PC却ping不通。tracert显示数据包在R1和R2分公司B的ABR之间来回跳转TTL减到1后超时。初步检查show ip ospf neighbor所有邻居关系正常。show ip route 172.16.20.100R1的路由表里有O IA条目下一跳是R210.0.0.2metric20。show ip ospf database summary | include 172.16.20.100R1的LSDB里确实有一条Type-3 LSAAdvertising Router是R2。一切看起来都“应该工作”。5.2 深入LSDB与SPF日志分析问题出在“应该”二字上。我们登录R1开启SPF详细日志debug ip ospf spf events。然后在R2上clear ip ospf process触发一次完整的LSDB同步和SPF重算。日志显示R1在SPF计算时成功找到了R2并计算出“R1→R2”的cost为10。但关键的一行日志是OSPF-1 SPF: Calculating path to 172.16.20.100 via ABR 10.0.0.2, total cost 10 10 20这个“10 10”引起了我的注意。第一个10是R1到R2的cost第二个10是Type-3 LSA里的Metric。但R2生成这条Type-3 LSA时172.16.20.100是R2的直连路由其接口cost应该是1为什么Metric是10我们立刻登录R2执行show ip ospf database summary 172.16.20.100。输出显示LS age: 1200 Options: (No TOS-capability, DC) LS Type: Summary Links(Network) Link State ID: 172.16.20.100 Advertising Router: 10.0.0.2 LS Seq Number: 80000001 Checksum: 0xXXXX Length: 28 Network Mask: /32 Metric: 10Metric确实是10。再查R2的配置发现它在Area 2的接口上配置了ip ospf cost 10。但172.16.20.100是R2的loopback接口其OSPF cost默认是1。为什么Type-3 LSA的Metric是10真相浮出水面R2在生成Type-3 LSA时不是用loopback接口的cost而是用了它通往Area 0的出接口的cost因为RFC规定Type-3 LSA的Metric是“ABR到该网络的累计cost”而R2认为去往172.16.20.100的最优路径是先走到自己的loopbackcost1再从loopback走到Area 0cost10所以总cost11不对日志里是10。我们继续深挖执行show ip ospf interface发现R2的loopback接口被错误地宣告进了Area 0配置是network 172.16.20.100 0.0.0.0 area 0。这就意味着172.16.20.100在Area 0里是一条Type-1 LSARouter LSA而在Area 2里R2又把它当作一条直连网络生成了Type-3 LSA。OSPF协议允许这种“多区域宣告”但后果是R2在Area 0里宣告自己是172.16.20.100的拥有者在Area 2里又宣告自己是172.16.20.100的“汇总者”。当R1在Area 0里学习到R2的Type-1 LSA描述172.16.20.100它会认为这是区域内路由优先级高于Type-3 LSA。但R1在Area 1里只能学到Type-3 LSA。所以R1的路由表里去往172.16.20.100的路由下一跳是R2但R2在Area 0里R1要去Area 0找R2而R2的Area 0接口又down了因为线缆松动导致数据包在R1和R2之间循环。5.3 根本原因与修复方案根本原因网络地址在多个区域被重复宣告且宣告类型冲突Type-1 vs Type-3导致SPF计算出的路径与实际物理连通性不匹配。这不是OSPF防环机制的失败恰恰是它在“尽力而为”下的必然结果——协议无法判断管理员的配置意图它只忠实地执行泛洪和计算规则。修复方案有二推荐方案将172.16.20.100从Area 0的network宣告中移除只保留在Area 2内。这样R2只会在Area 2内生成Type-1 LSA在Area 0内生成Type-3 LSA逻辑清晰。备选方案在R2上为172.16.20.100配置area 2 range 172.16.20.100 255.255.255.255 cost 1强制指定Type-3 LSA的Metric为1避免因出接口cost导致的误导。这次排障让我深刻体会到OSPF区域间防环防的是协议层面的逻辑环路防不了人为配置错误导致的物理环路。最好的防环永远是清晰的网络规划和严格的配置审计。在模拟项目X的后续迭代中我们加入了自动化脚本定期扫描所有路由器的show ip ospf database输出检查是否存在同一网络地址在多个区域以不同类型LSA出现的情况提前预警。6. 工程师手记那些教科书不会写的实战心得写了这么多原理和案例最后想和你分享几个我在一线摸爬滚打十年从无数次重启、抓包、翻RFC中总结出的、真正能救命的实战心得。这些不是知识点而是“血的经验”。6.1 “ABR越多风险越高”不是玄学而是数学很多网络设计文档喜欢画一个漂亮的“多ABR星型图”认为这样能提高冗余。但现实是每增加一台ABR就多出N-1个潜在的Type-3 LSA生成点N是区域总数。ABR之间的LSDB同步、SPF重算、LSA老化刷新全部是指数级增长的开销。我在某次超大规模园区网升级中将ABR数量从2台增加到6台结果发现Area 0的LSDB大小暴涨300%SPF收敛时间从1秒延长到8秒。更糟的是其中一台ABR的CPU在高峰时段经常飙到95%导致它生成的Type-3 LSA延迟泛洪其他区域路由器计算出的路径就变成了“次优路径”间接诱发了数据包乱序和重传。所以我的建议是在满足业务需求的前提下ABR数量宁少勿多。一个区域一台ABR足矣真要冗余用HSRP/VRRP做ABR虚拟网关而不是堆物理设备。6.2show ip ospf database是你的第一双眼睛不是最后一招新手排障习惯先看show ip route再看show ip ospf neighbor。这没错但太慢。真正的高手第一眼就看show ip ospf database。因为路由表是SPF的“输出”而LSDB是SPF的“输入”。输入错了输出一定错输入对了输出还错那一定是SPF算法本身的问题几乎不可能。我给自己定的铁律是只要路由异常第一件事就是show ip ospf database按Type分类查看重点盯Type-3 LSA的Advertising Router和Metric。如果发现某个网络的Type-3 LSAAdvertising Router是A但Metric大得离谱比如几千那基本可以断定是ABR通往该网络的路径cost被错误放大了立刻去查那台ABR的接口cost配置。6.3 不要迷信“默认路由”Totally Stubby Area也有陷阱Totally Stubby Area很香LSDB干净CPU友好。但它的默认路由是“无条件信任ABR”的。如果ABR的默认路由下一跳配置错了或者ABR通往Area 0的路径出现了单向故障比如光纤收光正常但发光异常那么整个Stub Area就会变成一座孤岛所有流量都被黑洞吞噬。我在某次割接中就遇到过R1是Area 1的ABR配置了area 1 stub no-summary但它的Area 0接口的ip ospf cost被误配成了1000000。结果Area 1内的路由器计算出的“去往Area 0”的路径cost高达百万SPF算法认为这条路“不可达”于是所有流量都走向了默认路由而默认路由的下一跳恰好是那个故障的Area 0接口。解决方案很简单在ABR上为默认路由的Type-3 LSA指定一个合理的、略大于实际路径cost的值比如area 1 default-cost 10。这样即使物理路径cost异常SPF计算出的路径依然有效。6.4 最后的忠告画图一定要画图所有关于OSPF的复杂问题90%都能通过一张手绘拓扑图解决。图上标清每个接口的IP、Area ID、OSPF cost、以及每台路由器的ABR身份。然后拿起红笔模拟Type-3 LSA的流向从哪个ABR生成泛洪进哪个区域被哪台路由器学习。当你把整个泛洪路径画出来环路在哪里黑洞在哪里一目了然。我至今保留着一个习惯每次接手一个新网络第一件事不是敲命令而是用A4纸花15分钟把核心区域拓扑画下来。这张图比任何配置文档都管用。因为协议是死的人是活的而图是连接死协议和活人的唯一桥梁。我在模拟项目X的最终交付物里就附上了一份手绘风格的OSPF区域拓扑图上面用不同颜色标注了LSA类型和流向。客户的技术总监看到后拍着桌子说“这才是我想要的文档”——因为它不讲虚的只讲“谁在哪儿说了什么传给了谁”。这才是工程的本质。