告别海量路由轰炸！抓包揭秘OSPF Totally Stub的极致减负魔法

通过前面几次学习，对OSPF的四种网络类型算是摸了个门儿清。在BMA网络里（拒绝网络动荡！抓包揭秘OSPF的夺权潜规则与定海神针），DR和BDR是维持庞大网络稳定运作的定海神针；对于P2P和P2MP网络（别再傻等40秒了！一键优化OSPF，体验秒级收敛的快感），可以精简LSDB、加速收敛，是保障网络高可用性的一把好手；对于NBMA网络（从120秒到1秒的性能狂飙！带你硬核抓包OSPF的P2MP魔法），虽然减少了LSA泛洪与邻居关系数量，但硬伤是必须通过单播手段静态指定邻居，就像在黑屋子里抓瞎。

像我们的实验环境，满打满算也就是个只有14台设备的小网络。一旦到了真实场景，随着网络规模滚雪球般扩大，我们不可避免地会撞上一个核心痛点：路由表过于庞大导致设备资源耗尽。

俗话说，好钢用在刀刃上。在骨干网中，路由器通常性能强悍，能够承受全网明细路由的计算。但对于处于网络边缘的分支机构或接入层设备而言，它们往往只有一条上行链路指向核心网，让这些小身板去维护成百上千条外部明细路由，不仅纯属脱裤子放屁——多此一举，更是一场吃光内存的灾难。

这就引入了我们今天要介绍的OSPF为边缘网络减负的绝佳手术刀：Stub区域和Totally Stub区域机制。毕竟，这些边缘路由器根本不需要知道到达外部网络或其他区域的每一条明细路由，舒舒服服地只留一条默认路由指向骨干网就足够了。

本次实验，我们依旧是在EVE-NG实验环境中（告别V6时代！EVE-NG 7.0丝滑跨代升级实战，内核狂飙，老旧模拟器该换代了），使用14台V9850-256H交换机设备来配置OSPF，同时搭配一台部署了我们ZTP管理系统的Ubuntu系统来进行操作（彻底告别配置丢失焦虑！让可视化ZTP系统赋能快照读档神技）。

整个实验的完整接口互联表如下，方便大家按图索骥。

全网一共划分6个区域，各设备的所属区域如下所示：

本次实验，我们将战场转移到网络的边缘区域Area 4，并通过自治系统边界路由器ASBR来制造外部路由压力。通过选取ASBR1、ABR2、A4A这三台设备，构成了一条完美的从外部网络、到骨干网、再到边缘网络的数据流向链条。

在这盘棋里，ASBR1设备就是外部路由的发源地，A4A设备是急需减负的受害者，而ABR2设备则是执行过滤策略的关键闸门。

为了直观体现Stub区域过滤外部路由的价值，我们先在ISP1设备上创建一个公网业务网段。

#
interface LoopBack100
ip address 10.100.1.1 255.255.255.0
然后在ASBR1设备上配置静态路由指向ISP1设备，并将这条静态路由引入OSPF进程。

ip route-static 10.100.1.0 24 10.11.21.11
#
ospf 1 router-id 10.0.2.1
import-route static
在未配置任何Stub策略之前，我们先检查一下处于边缘的A4A设备的路由表。

display ospf 1 routing

可以看到，A4A设备作为一台仅有单链路上行的叶子节点，它的OSPF路由表中居然塞满了26条区域间路由，以及1条远在天边的5类ASE外部路由！

试想一下，随着其他区域的疯狂扩展，这些明细路由还会呈指数级爆炸增长。对于边缘接入设备A4A而言，这种资源浪费情况，无疑使其LSDB将面临巨大的维护压力。

接下来，我们使用Stub机制为A4A设备来一场极致瘦身。

注意，在配置Stub区域的过程中，OSPF底层会发生极其剧烈的状态机断裂与重组。如果要捕捉这一精彩瞬间，我们需要在配置前就开启抓包操作。

配置时，我们先在ABR2设备上率先将Area 4配置为Stub区域。

#
ospf 1 router-id 10.0.3.2
area 0.0.0.4
stub
配置下发之前，两台设备之间的Hello报文还是正常的。

报文中的Options字段为0x02，E位的值为1，表示支持外部路由，两台设备也能愉快的进行沟通。

就在配置下发的一瞬间，ABR2设备马上翻脸不认人，将Options字段E位的值调整为了0，严正声明自己不再支持外部路由。

此时，OSPF严苛的安全与一致性检查机制就开始发威了。它要求建立邻居的双方，必须对区域类型达成绝对的一致。可现在两台设备有关是否接收外部路由产生了巨大分歧：ABR2设备突然拒收外部路由，而A4A设备一侧依然傻乎乎地保持着支持外部路由的状态。

结果可想而知，因为两端核心参数不匹配，友谊的小船说翻就翻，OSPF引擎果断拒绝建立邻居，原本处于Full状态的邻居关系走向断裂。

别慌，我们接着在A4A设备上跟进Stub区域配置。

#
ospf 1 router-id 10.0.4.4
area 0.0.0.4
stub
配置下发之后，A4A设备如梦初醒，立即修改自身参数，同样声明不再接受外部路由了。

终于，参数对齐后的两台设备重归于好，不过后配置的A4A设备也降级为了BDR角色，与ABR2设备恢复了Full邻接关系。

诶？A4A设备降级为BDR，到底是因为他是后配置的？还是因为配置了Stub区域引发的蝴蝶效应呢？我们重启OSPF进行看一下。

看到了吧，配置Stub区域不影响DR/BDR选举，刚才Router ID更大的A4A设备被选举为BDR设备，纯粹是因为我们先配置了ABR2设备，而ABR2设备在等待期里毫不客气地把自己选举为了DR设备。

我们看看A4A设备现在的查看路由表。

display ospf 1 routing

虽然总的路由条目还是30条，但是ASE路由不见了，外部路由多了一条全零的默认路由，下一跳指向ABR2设备。

这么看变化也不大啊？别急，为了将减负进行到底，我们在ABR2设备上追加no-summary指令。

#
ospf 1 router-id 10.0.3.2
area 0.0.0.4
stub no-summary

这一手可谓是秋风扫落叶！可以看到，相比于初始状态那多达30条的臃肿路由表，现在A4A设备的路由表堪称艺术品。所有的外部ASE路由和3类区域间路由被全部剔除，只剩下一条下一跳指向ABR2设备默认路由！

这波操作极大释放了边缘设备的内存和CPU资源，实现了最优雅的网络出口导流。

当然了，在实际工程中，对于双ABR的多出口网络场景，我们还可以精细化调整ABR设备下发默认路由的开销值。

#
ospf 1 router-id 10.0.3.2
area 0.0.0.4
default-cost 20

可以看到，因为ABR设备宣告的Cost从1变成了20，再加上A4A设备到ABR2设备的开销值1，A4A设备路由表中的缺省路由的Cost值从默认的2精准变为了21。在双ABR冗余架构中，这一机制是实现主备链路切换的核心手段。

在大型企业网和运营商网络的架构设计中，控制核心骨干网与边缘网络的路由交互规模是重中之重。通过本次实验，我们层层递进地体验了OSPF特殊区域的减负魅力：

未减负前，边缘设备不得不默默承受来自ASBR注入的外部网络和全网其他区域的海量路由轰炸。

通过配置Stub区域，我们坚决将最容易引发动荡、数量最不可控的5类外部路由拒之门外，构筑了Stub区域的第一道防线。

随后，通过简单的no-summary指令，我们连同3类域间明细路由也一并屏蔽，用最精简的一条0.0.0.0/0实现了全网连通，这就是Totally Stub的终极打击。对设备内存和CPU的消耗降到了绝对的物理最低点。

掌握了Stub/Totally Stub的减负艺术，再结合双ABR的default-cost导流，我们就掌握了构建高可用、高扩展性的大型园区网出口架构的终极密码。