企业官网建设流程全解析

做网络的人迟早会碰到这么一件事：手头一套跑了很多年的网络，路由表越来越大，收敛越拖越慢，领导一句“优化一下”，就把IS-IS区域迁移和路由汇总推到你面前。这个系列写到第十七篇，前面的内容把IS-IS的邻居关系、LSP交互、SPF计算这些底层机制都过了，这篇重点处理两个在实际运维里绕不开的课题——区域怎么迁、路由怎么汇总。

先说一个真实感受：区域迁移和路由汇总看着是两个独立操作，实际在工程里往往是同一件事的两个阶段。迁移的过程中必须重新梳理区域边界和路由层级，边界梳理完了，汇总参数的配置才有意义；反过来，汇总做得不好，迁移后路由表反而更乱。这篇就把这两件事放到一起讲，从原理到操作步骤再到排查案例，尽量说人话、给干货，让不同基础的朋友都能照着干。

1. IS-IS区域模型：迁移前必须吃透的几个概念

1.1 区域不是画在地上的，是画在路由器上的

很多人对IS-IS区域的第一反应是拿OSPF的Area去套，区域就是接口划分，边界是ABR。这个思路不能说全错，但在IS-IS里确实容易带偏。

IS-IS的区域概念是挂在路由器上的。每台IS-IS路由器拥有一个NET（Network Entity Title）地址，这个地址里的Area ID字段决定路由器属于哪个区域。一台路由器可以配置多个NET地址，在迁移过渡期甚至会故意保持旧、新两个区域地址同时存在。这种设计意味着IS-IS的区域边界不需要跟某一条链路、某一个接口严格对齐，区域间的互联可以发生在任意链路上，只要两端路由器各自明确自己的Level角色。

更好的理解方式是：IS-IS把网络分成两层逻辑台阶，Level-1是普通区域内部，Level-2是骨干区域。一台路由器如果只有Level-1的能力，它就只能知道本区域的拓扑和路由；一台Level-2路由器则知道整个Level-2骨干域的链路状态，负责区域之间的路由传递。还有一种Level-1-2路由器，两边都沾，在Level-1区域里充当“出口”。

这带来一个OSPF里没有的特征：普通Level-1路由器不需要知道区域外的任何明细路由。它靠边界L1L2路由器在Level-1 LSP里设置的ATT位置来生成一条默认路由，所有跨区域流量都扔给最近的Level-1-2边界设备。正是这个机制，让IS-IS天然适合做大范围、多区域的网络，这也是后面讲区域迁移和汇总时必须记住的基础。

1.2 L1/L2/L1L2三种角色与默认路由机制

IS-IS里一台路由器的Level角色由is-type决定，一般有三种配置：level-1只能参与Level-1区域内部路由计算，level-2参与骨干路由计算，level-1-2同时参与两边。

Level-1-2路由器同时维护两个独立的链路状态数据库。它会把本区域Level-1的明细信息汇总后注入Level-2骨干，同时也通过ATT位在Level-1区域里宣告“我是出口”。Level-1路由器看到ATT置位后，会产生一条指向该L1L2路由器的默认路由，但注意它不会学习到其他区域的明细路由。换句话说，Level-1路由器是“不需要知道外面长什么样，只要能出去就行”。

这个机制在路由汇总里非常关键。因为Level-1到Level-2天然就是聚合边界，Level-1的明细路由到了L1L2路由器之后，完全可以在注入Level-2之前做一次汇总，削减骨干域的链路状态数据量。如果你在迁移后不做任何汇总，Level-1区域里的一堆细路由照样会以明细形式进入Level-2域，LSDB膨胀的问题就还在。

1.3 区域迁移到底在迁移什么

很多网工一听到区域迁移，脑子里浮现的是“重新敲一堆配置”。但真正迁移的对象其实是三样东西：区域地址编码、设备Level角色、路由边界的位置。

区域地址编码变化是指NET里的Area ID要改。这个过程涉及LSP重新生成和邻居关系重建，系统ID不变的情况下邻居能保持，但Area ID变了之后，区域内所有路由器都必须重新认知区域归属。

设备Level角色变化是指一台原本只跑Level-2的路由器，要改成Level-1-2，或者本来Level-1的设备要升级成Level-1-2，这台设备的LSP内容、参与的SPF计算范围都变了。

路由边界位置变化是指哪些链路上做区域切分、哪台设备承担L1L2网关角色。这部分最容易被忽略，但实际影响最大——边界位置直接决定了跨区域流量的转发路径。

1.4 什么场景真的需要区域迁移

不是所有网络都要做区域迁移。真正触发迁移需求的场景，通常有下面几种典型症状，我在运维里碰到最多的就是这些。

表格列出来之后解脱很简单，真正执行的时候每一步都是坑。迁移最忌讳一步到位，尤其是生产网络，必须按“评估、灰度、验证、回退”的节奏走。下面聊三条主流迁移路径的选型和执行细节。

2. 区域迁移的三种典型走法：方案选型与执行细节

2.1 方案A：跨协议迁移，从旧IGP搬到IS-IS

跨协议迁移最常见的场景是现网跑着OSPF，因为IS-IS在运营商层面和大规模DC的扩展性更好、协议开销更低、跨厂家兼容更稳，决定整体切换到IS-IS。最忌讳的做法是某天凌晨把全网OSPF进程一删，配置里全部换成IS-IS，然后开始烧香。

规范的做法是“先建后拆、路由渐进”。具体来说分四个阶段：

1. 新增IS-IS进程，先只在少数核心设备上启用，与现有OSPF进程共存。
2. 在核心设备上配置OSPF到IS-IS方向的单向引入，把OSPF路由引入IS-IS，让IS-IS域内先能看到全网路由。这一步不要同时配置反向引入，否则两个协议域之间一互相引入，路由环路和优先级打架问题马上就来。
3. 逐步增加接入设备的IS-IS部署，同时在这些设备上去掉OSPF邻居或降低OSPF路由的优先程度，把实际流量从OSPF切到IS-IS上。
4. 确认全网所有设备在IS-IS下路由完整、无环路、无黑洞后，再清理OSPF配置。

单向引入期间要特别注意管理距离（AD值/优先级）的调整。不同厂商的优先级默认值不一样，如果IS-IS的优先级没有比OSPF更优，切换流量时会发现该走的路径没走。一般思路是先把OSPF引入IS-IS路由的优先级调到明显更低，让IS-IS里看到的OSPF路由只是兜底，等OSPF拆除后再恢复正常优先级。

我个人的经验是所有切换动作都拆成一个一个小窗口，一次只切一个区域或一批设备，切完先看路由表、再看流量统计、最后看接口误码，全部正常才继续下一批。整个过程拉长到两周甚至一个月，比一夜换代的风险低一个数量级。

2.2 方案B：区域结构调整，拆分与合并Level区域

区域结构调整不等同于换协议，它是纯IS-IS内部的重规划。常见两种情况：一是网络规模变大，原有大区域不堪重负，需要拆成多个Level-1区域；二是历史原因导致区域碎片化严重，一堆小区域之间靠L1L2设备连接，区域间路由路径绕路、管理复杂，需要合并区域。

拆分区域的执行关键点在于L1L2边界的选择。每一台被设定为Level-1-2的设备都会成为区域出口，如果区域边界上挂了太多L1L2路由器，Level-1区域内就会同时出现多个默认路由出口，跨区域路径的确定性变差。所以拆分时建议一个区域尽量只保留一到两个L1L2出口，出口越少，路径越可控。如果业务上必须冗余，就选两台，并且把优先级拉开，主备明确。

合并区域的执行逻辑反着来：把多个Level-1区域的NET Area ID改成同一个值，让路由器认为它们属于同一区域，同时把边界设备的Level-1-2角色调整为Level-1。这里有一个容易踩的坑：改NET时如果新旧Area ID切换过程中出现漏网设备没改完，LSP数据库会短暂不一致，区域里会出现“部分设备还认为自己是另一个区域”的情况，路由表会来回抖动。所以合并动作同样必须分批，每改完一批设备，观察所有邻居的LSDB同步状态，等完全收敛再动下一批。

2.3 方案C：设备角色升级，L1到L1L2的角色变更

有些网络上所有设备一开始都是Level-2，骨干和接入没有层次之分。随着规模变大，需要把接入设备降级为Level-1，只有核心出口保持Level-1-2。设备角色变更在命令上只是敲一下is-type level-1或level-1-2，但实际影响是全局性的。

设备从Level-2改成Level-1-2时，它会开始参与Level-1区域的SPF计算，同时它之前作为纯Level-2设备学习的全网L2明细路由，并不会自动变成Level-1路由。也就是说，接入侧的Level-1设备只会收到ATT默认路由，区域外那些以前能看得到的明细全没了。这个变化如果没人提前告知业务方，往往会引起跨区域访问的“间歇性不通”误报。

设备从Level-1升级到Level-1-2时，相当于给区域新增了出口，全局默认路由的下一跳分布会变化。如果升级前区域里已有其他出口，新出口加入后流量路径会重新分配，必须确认业务流量是否允许走新路径。

2.4 灰度、验证与回退：迁移的保命环节

迁移方案不管选哪种，有一点必须提前想明白：回退什么条件触发、回退到哪一步、回退过程中网络能不能承担新增的收敛开销。

我在实际项目中采用的通用策略是：每步操作前先保存当前运行配置，并对核心设备做一次display isis lsdb的完整快照。迁移中的步与步之间设置观察窗口，窗口内盯三件事：SPF计算次数有没有异常暴涨、LSDB里LSP条数有没有异常变化、路由表里是否有不明来历的默认路由或黑洞路由。任何一项异常都立即触发回退。

保留旧NET地址做多NET过渡，也是常用手段。IS-IS支持一台路由器同时拥有多个NET，迁移时新老Area ID可以共存，等全网都切换到新Area ID后再删掉旧NET，这样区域归属切换对设备来说不是“突然换国籍”，而是“中途过渡”。这个操作能让区域迁移的收敛过程平缓很多，强烈建议在生产环境使用。

3. 路由汇总的原理与实操：在哪里汇总，汇总到什么程度

3.1 为什么IS-IS需要路由汇总：LSDB、SPF与收敛风暴

IS-IS是链路状态协议，每台路由器维护全网（所在Level域）的链路状态数据库，然后基于LSDB跑SPF算法。LSDB的规模直接决定SPF的计算开销。当然现代设备处理器不弱，但问题是网络上路由条目不止几百条，经常是几万条起步。LSP条目暴涨之后，SPF计算时间会呈现超线性增长，而且每一次明细路由变动都会触发区域内的LSP泛洪和SPF重算，形成“收敛风暴”。

路由汇总的核心价值就是在大规模网络中减少链路状态数据库中路由条目的数量。在L1L2边界把区域内一堆具体前缀聚合成一条或几条前缀，Level-2骨干看到的就不是几百条细路由，而是几条聚合路由。这么做的收益不只是路由器内存降低，更重要的是拓扑稳定性——某个Level-1区域内的路由抖动，因为被聚合成一条L2路由，骨干域根本感知不到明细变化，SPF重算次数立刻降下来。

3.2 汇总放哪里：L1L2边界和重分发边界

IS-IS的汇总位置相对固定，最常规的是在L1L2路由器上做Level-1到Level-2方向的汇总。在这里配置汇总命令，L1的明细路由先经过汇聚再注入L2 LSP。这是IS-IS区域架构里最自然的汇总点，设置一个区域边界就等于给区域内的路由设置了一个“出口管卡”。

另一种汇总点是协议重分发边界。如果IS-IS域内需要引入外部路由，比如把静态路由或直连网段放进IS-IS，外部路由条目多的时候，可以在重分发配置里直接做前缀聚合，避免外部明细路由逐条注入导致LSP膨胀。第三种情况是接入层设备把直连网段通告进IS-IS时，如果直连网段过于碎片，可以在设备上用被动接口或网段汇总来收敛通告粒度。

选择汇总位置时需要结合路由流向想明白。IS-IS的L1L2汇总只会影响L1到L2上行方向的路由通告，不会影响L2到L1的下行方向。如果你想控制下行方向的路由规模，那要靠路由泄漏的策略，不是靠汇总。这个方向感很多人搞混，先理清楚再动手。

3.3 汇总命令与参数选择：掩码怎么定，聚合路由怎么生成

不同厂商的IS-IS汇总命令措辞有区别，但思路一致，就是在IS-IS进程下声明“把符合条件的前缀汇总成一条”。通用配置形态如下：

router isis is-type level-1-2 net 49.0001.0000.0000.0001.00 summary-address 10.1.0.0 255.255.0.0

这个命令表示把区域内10.1.x.x的明细路由汇总为10.1.0.0/16通告到Level-2。

汇总掩码的选择是这门技术里最需要拿捏的地方。掩码选大了，聚合范围过大，会把不相关的路由一并收编，造成交通过度集中，之后策略控制很被动；掩码选小了，聚合后的路由条数还是很多，汇总效果不明显。判断标准是“站在边界设备上按网段连续布局来选掩码”。比如区域内所有业务地址在10.1.0.0/16段内连续分配，就直接汇总成/16；如果区域内还混着10.2.0.0/16的部分网段，就必须给这部分单独规划，不能强行塞进/16的聚合里。

另外要注意汇总命令是否支持“有条件汇总”。较新的实现里，可以配合前缀列表或者Tag过滤，只有匹配的明细参与汇聚，不匹配的一律不生成聚合路由。这个特性非常实用，举个场景：区域内10.1.0.0/16里包含业务网段10.1.0.0/20、10.1.128.0/20，但也包含一段保留网段10.1.240.0/20，你不想让保留段出现在骨干路由表里，就可以通过条件汇总精确控制聚合范围。

3.4 汇总与路由泄漏的组合玩法

路由泄漏这个概念在IS-IS里和汇总几乎是成对出现的。默认情况下，Level-1区域看不到外部明细路由，只有边界生成的默认路由。这样设计很简洁，但代价是路径不一定最优：区域明明有两个出口，一个离目标近一个离目标远，Level-1路由器却只会把跨区域流量丢给“最近的那个核心”，远的那条路径只能空闲。

路由泄漏就是把Level-2里的特定明细路由反向注入到Level-1区域，让Level-1路由器可以针对特定目标前缀选择更优的出口。它和汇总有一个微妙的配合：汇总能减少上行方向的LSP规模，泄漏则在下行方向有选择地放行少量明细路由。好的设计是“上汇总、下泄漏”：区域上行把细路由全部聚合，骨干路由表干净；下行只把确有跨区域访问需求的网段泄漏下来，避免Level-1区域被外部明细刷爆。

配置层面可以用带Tag的前缀列表来实现。比如给需要泄漏的网段打上Tag 100，边界设备只泄漏带Tag 100的路由。这种做法比直接匹配IP前缀更抗变更，后来增加网段时只要在源端打Tag，不用改边界过滤策略。

3.5 汇总的常见副作用：黑洞与次优路径

画重点：汇总之后的黑洞路由问题在IS-IS里非常典型。

假设边界设备把10.1.0.0/16汇总后通告到Level-2，但此时Level-1区域内实际只部署了10.1.1.0/24到10.1.10.0/24这些网段。骨干域里的流量目标是10.1.200.0/24（并不存在于Level-1区域），流量沿着聚合路由到达边界设备之后，边界设备发现自己没有这条明细路由，流量就被丢弃。这就是汇总后产生的黑洞。

规避方式有几种：一是确保聚合路由对应的网段范围完全覆盖实际部署，并且边界设备配置一条指向Null0的汇总路由兜底；二是利用条件汇总，让聚合路由只在明细路由存在时才发布；三是在边界设备上对下行转发做策略控制，明确告知不可达段应该被丢弃还是走备份路径。

次优路径问题前面提过。本质上是因为汇总让骨干域只知道“这个区域有这个段”，但不知道段内更细的拓扑，跨区域选路时只能选离边界最近的入口。如果业务对时延敏感，需要结合路由泄漏来精确指定最优入口。

4. 组合实战：双区域迁移加边界汇总完整案例

4.1 场景与地址规划

用一个改造过多次、经过脱敏的模拟场景来说话。某公司内部网络原先是全网Level-2扁平结构，大概有四十多台路由器，路由条目约一万条。设备性能报警已经不是一天两天了，SPF重算的抖动经常导致业务丢包。改造方案是拆成两个Level-1区域，分别归入不同业务域，两个区域之间保留一个Level-2骨干域，在区域边界设备上做汇总。

迁移前的第一步不是敲命令，而是对区域A和区域B的地址分配做一遍盘点。确认10.1.0.0/16和10.2.0.0/16范围内有没有出现交叉分配、保留段和临时网段。如果有，先整理地址规划，该收敛的收敛，该挪位的挪位。地址不干净，后面的汇总就是给黑洞挖坑。

4.2 分阶段实施步骤

阶段一：先把核心骨干域的设备全部明确为Level-2，保持现状。然后在两台边界设备X和Y上把角色从Level-2改成Level-1-2。这一步成功后，边界设备会生成L1 LSP，并向Level-1方向宣告ATT位。观察所有L1邻居是否正确建立，L1区域内的默认路由是否生成。

阶段二：将区域A内的接入设备角色从Level-2改为Level-1。注意一次改一台，每改完一台立即观察该设备的邻居关系、路由表、LSDB同步状态。全部改完后，区域A内所有Level-1设备都应该通过X设备学习到默认路由。

阶段三：同样操作区域B。全部就位后，全网应该呈现“Level-1区域 + Level-2骨干”的两级结构。此时跨区域路由依赖默认路由，可能还没有恢复到最优路径，先不急着调优，确认基本连通性。

阶段四：在边界设备X和Y的IS-IS进程下配置汇总。

router isis is-type level-1-2 net 49.0001.0000.0000.0001.00 summary-address 10.1.0.0 255.255.0.0

router isis is-type level-1-2 net 49.0002.0000.0000.0001.00 summary-address 10.2.0.0 255.255.0.0

阶段五：如果业务要求跨区域路径最优，再在边界设备上配合路由泄漏，把区域B的关键业务网段精确泄漏到区域A，区域A的关键业务网段也精确泄漏到区域B。

4.3 验证与效果对比

验证不是看一眼路由表就行，要回到底层去看LSDB的变化。重点检查几个指标：Level-2域里的LSP总条数是否明显下降、边界设备上是否生成了聚合前缀对应的LSP、SPF触发次数是否降低、跨区域连通性是否持续稳定。

实际当然不会像表格里这么理想，中间会有各种意外。但按表格维度去记录，至少能在迁移前后有一个客观的量化对比，用来向团队和领导交代“优化有效果”，比一句“我觉得好多了”可信得多。

4.4 迁移过程中的观察点与手动校验

迁移过程中有个习惯值得养成：每次都检查一下Level-1区域里的默认路由是不是正确生成，下一跳是不是指向预期边界设备。ATT默认路由是IS-IS区域迁移最容易出问题的点。如果边界设备未正确宣告ATT，或者Level-1路由器没有生成默认路由，跨区域流量直接断掉。这个检查要在每台Level-1路由器上看，不能只看边界设备。

另一个手动校验是抓一份Level-1区域内的明细路由清单，在边界设备上做一次“清单对比汇总范围”的演练。把区域内所有活跃前缀列出来，和汇总掩码做交集确认，保证没有遗漏、没有多包。这个动作虽然土，但能避免汇总配置下发后才发现的“覆盖范围大于实际部署”问题。

5. 常见问题与排查技巧实录

5.1 问题速查表

5.2 一个典型的黑洞排查过程

某次改造后，骨干域里通告了10.1.0.0/16聚合路由，但是区域A里实际只部署了10.1.0.0/20和10.1.128.0/20两段。外部访问10.1.200.0/24时，流量到了边界设备X，X在L1区域内查明细前缀，发现没有对应条目，随即丢包。一开始还以为是区域迁移把明细路由搞丢了，后来逐台检查边界设备的LSP发布情况，才确认明细本来就不存在、聚合范围又覆盖到了废弃网段。

处理方式分两步：一是把10.1.0.0/16改成条件汇总，只对存在的明细段进行聚合发布；二是在边界设备上把废弃网段明确黑洞掉，避免误入流量继续在内部打转。如果当时图省事直接删掉汇总，骨干域又会膨胀回去，等于没优化。

5.3 三个值得坚持的检查习惯

第一个习惯是变更前把当前IS-IS进程配置完整导出一份，尤其注意NET地址、Level角色、汇总前缀三块。这三个字段只要有一个配置不对，整个迁移就要从头排查。

第二个习惯是每次改动后用display isis lsdb对比关键LSP的变化，而不是只看路由表。路由表是SPF计算后的结果，链路状态数据库里如果有问题，路由表的变化可能延迟或者被策略掩盖。链路状态层面的变化才是IS-IS问题的第一现场。

第三个习惯是按区域为单位做“路由规模预测”。迁移或汇总前，拿当前明细路由数量估算一下改造后LSDB的规模，算出SPF降载的幅度。如果估算结果和实际验证相差很大，一定是有路由没被聚合进来，或者聚合范围没覆盖干净。这个预测动作能提前暴露很多配置遗漏。

6. 写在最后：这片网络改造给我留下的习惯

IS-IS区域迁移和路由汇总做多了之后，我最大的体会是这两件事拼的不是硬件性能也不是命令熟练度，而是“对链路状态数据库的理解”。很多人遇到IS-IS网络问题习惯性先看路由表，我现在的第一反应永远是看LSDB、看LSP、看SPF计算记录。路由表只是结果，链路状态才是原因。

另外一点是关于节奏的。区域迁移这类操作，最怕的就是“觉得没问题，顺手多改一点”。每次只做一件事、观察一段时间、确认稳定再继续，这套行事方式虽然慢，但这么多年帮我避开过好多次大事故。

最后分享一个小技巧：做路由汇总的时候，先把区域内活跃路由清单导出来，按网段连续性和掩码长度做排序，这比趴在配置里猜“哪些段该聚合”要快得多。清单排完之后，汇总掩码是多少、要不要开条件汇总、要不要配合路由泄漏，基本一眼就能定下来。用这个办法，迁移前后的链路状态变化也更容易跟同事讲清楚。