CIDR无分类编址实战：IPv4子网划分与路由聚合全解析

做网络这行，早晚都要过一次这样的坎：看到 192.168.1.0/24 能秒懂，看到 10.1.16.0/20 就得开始心算，等到需要判断两个网段能不能合并、合并之后会不会吞掉别的网段，那就必须掰着手指头数二进制了。实验十四这个“IPv4地址的无分类编址方法”，我第一次做的时候觉得不过是写几个掩码、敲两条命令，直到后来在一个小局域网里亲眼看着四个 /26 聚合成一条 /24，随即又亲手制造出一个路由黑洞，才真正意识到 CIDR 是整个 IP 网络里最值得花时间的数学基础。

这篇文章我会把整个实验完整重做一遍，按照“为什么会有 CIDR → 怎么算 CIDR → 怎么在路由器上配出来 → 聚合验证 → 踩坑排查 → 生产环境迁移”的顺序展开。无论你是正在为实验报告发愁的网络专业学生，还是想在 eNSP、GNS3 里把地址规划练成肌肉记忆的新人，或者是单纯想弄明白“为什么电脑老显示无网络访问权限”的普通用户，都能在下面找到对应段落。

1. 为什么这个实验到今天还值得认真做

1.1 有类编址留下的历史包袱

学 IP 地址的时候，大家都背过那张分类表：A 类的前 8 位是网络号，默认掩码 255.0.0.0，地址范围从 0.0.0.0 到 127.0.0.0；B 类前 16 位是网络号，默认掩码 255.255.0.0，从 128.0.0.0 到 191.255.0.0；C 类前 24 位是网络号，默认掩码 255.255.255.0，从 192.0.0.0 到 223.255.255.0。这套体系在互联网早期确实简单直观，但它有两个非常要命的问题。

第一个问题是地址浪费。一个公司如果只需要 300 个 IP，C 类只有 254 个可用地址，不够；B 类有 65534 个可用地址，又远远超出需求。那就只能给它分一个 B 类，结果几万个地址就这么闲置了。在 IPv4 地址总量只有 43 亿的背景下，这种“按类分配”的方式是极大的浪费。第二个问题是路由表膨胀。那个年代每个 C 类网段都要在骨干路由器的路由表里占一条记录，A/B/C 类又没办法把连续的小网段合并成一条大路由，导致互联网骨干路由表迅速膨胀，路由器内存和查表性能都吃不消。

后来大家想了一个缓和办法，叫“子网划分”：在某个主类网络内部，把主机位的一部分借出来当子网位。比如公司分到一个 B 类 172.16.0.0/16，内部可以按 /24 切成 256 个子网，每个子网容纳 254 台设备，这样内部不浪费。但问题在于，对外部网络来说，它就是一条 B 类路由，没法把内部结构汇总给外面看，骨干路由表依然很臃肿。

1.2 CIDR 到底改了什么

到了 1993 年，RFC 1518 和 RFC 1519 正式提出了 CIDR，中文叫“无分类域间路由”，也叫“无分类编址”。它的核心思想就一句话：彻底废除 A/B/C 类的固定网络位长度，改用“前缀长度”来描述网络位。192.168.1.0/24 里的 /24 就表示前 24 位是网络前缀，后面 8 位是主机位；同样，10.1.16.0/20 表示前 20 位是网络前缀，后面 12 位是主机位。

这样一来，地址划分就从“只能按 8、16、24 位切”变成了“任意位都能切”。你需要 300 个可用地址，就找一个 /23 的块，512 个地址，去掉网络地址和广播地址还剩 510 个，非常合适。同时，路由聚合也顺势成为可能：连续的几个小网段，如果在前缀长度上具备相同的二进制前缀，就能合并成一条大路由，大大减轻骨干路由表的负担。

这里顺便回应一下很多人搜过的“ipv4报文格式”问题。IPv4 报文头里关于源地址和目的地址的字段一直没变，变的不是报文格式，而是路由器对地址的解释方式。收到一个目的地址后，路由器会把路由表里每条路由的前缀长度和目的地址做“与”运算，看结果是否等于该路由的网络地址；如果有多个条目同时匹配，就选择前缀最长的那一条，这就是“最长前缀匹配”。比如目的地址是 10.1.1.130，路由表里同时有 10.1.1.128/26 和 10.1.1.0/24 两条路由，那么数据包会走 /26 这条精确路由，而不是 /24 那条汇总路由。

1.3 无分类让网络管理变简单，也变复杂了

说它变简单，是因为地址可以按需分配，不再受类的束缚；说它变复杂，是因为所有计算都必须回到二进制，凭感觉很容易出错。CIDR 里藏着一堆“陷阱”：/22 到底覆盖多大范围？两个 /24 能不能成功聚合？聚合之后会不会吞掉邻居的地址？这些问题如果没想清楚，轻则网段配置错误，重则出现路由环路和黑洞。这个实验的价值，就是把这些换算和边界判断练成肌肉记忆，而不是靠网上的 CIDR 计算器帮你兜底——毕竟考试不让你用，生产环境排障时你也未必有时间打开网页。

2. CIDR 的核心换算：前缀、掩码、可用地址一次算清

2.1 前缀长度和子网掩码其实是同一件事

很多初学者会被两种表示法绕晕：/26 和 255.255.255.192 到底什么关系？其实它们说的是同一件事。子网掩码就是前缀长度对应的“连续 1”序列，比如 /26 表示前 26 位是 1，后 6 位是 0，转成十进制就是：

第一段 8 个 1 = 255，第二段 8 个 1 = 255，第三段 8 个 1 = 255，第四段前 2 位是 1、后 6 位是 0，也就是 11000000 = 192，所以 /26 = 255.255.255.192。

平时常用的对应关系，我整理成了下面这张表：

换算技巧很简单：看到 /N，就知道掩码前 N 位是 1；反过来，看到一个掩码，把二进制里 1 的个数数出来就是前缀长度。255.255.255.128 就是 25 个 1，所以是 /25。别背表，背“连续 1”这个概念，什么掩码你都能推出来。

2.2 可用主机数为什么总是减 2

每个 IPv4 子网里，主机位全 0 的地址是网络地址，代表这个网段本身；主机位全 1 的地址是广播地址，用于向该网段内所有设备发送报文。这两个地址都不能分配给主机，所以可用地址数永远是“地址总数减 2”。公式就是：

可用主机数 = 2^(32 - 前缀长度) - 2

以 /26 为例，地址总数是 2^(32-26) = 2^6 = 64，可用地址就是 62 个。这就是为什么点对点链路特别喜欢用 /30，它只有 4 个地址，去掉首尾刚好剩下 2 个，分别配给链路两端的路由器接口，一点都不浪费。少数场景还会用 /31，RFC 3021 允许点对点链路上把两个地址都用于主机，因为那种链路上根本不需要广播和网络地址；还有 /32，通常出现在设备的 Loopback 接口或 ACL 的精确匹配规则里，代表单个主机地址。

2.3 划分子网的完整步骤：一个 /24 拆成四个 /26

划分子网的实操逻辑并不复杂。假设你手里有一个 192.168.10.0/24，现在要给它拆成大小一样的 4 个子网。第一步，确定需要借几位主机位：因为 2^2 = 4，所以要借 2 位，掩码从 /24 变成 /26。第二步，计算每个子网的步长：256 除以 4，等于 64，也就是说每个子网以 64 个地址为单位递增。第三步，按步长列出所有子网：

• 192.168.10.0/26：范围 0 ~ 63，网络地址 .0，广播地址 .63，可用 1 ~ 62
• 192.168.10.64/26：范围 64 ~ 127，网络地址 .64，广播地址 .127，可用 65 ~ 126
• 192.168.10.128/26：范围 128 ~ 191，网络地址 .128，广播地址 .191，可用 129 ~ 190
• 192.168.10.192/26：范围 192 ~ 255，网络地址 .192，广播地址 .255，可用 193 ~ 254

很多人容易在这个环节犯一个低级错误：以为子网范围是从“子网号 + 1”到“子网号 + 可用数”，结果把广播地址算漏了。记住，广播地址 = 当前子网起始地址 + 地址块大小 - 1，比如 .64 这个子网，64 + 64 - 1 = 127，所以广播是 .127。

2.4 聚合的数学条件：块对齐

路由聚合是 CIDR 最吸引人的能力，但它有一个严格的前提条件：要聚合的网段必须连续，而且聚合后块的起始地址必须是该块大小的整数倍。这个门槛在教材里很少被强调，但实际网络规划里无数人在这里栽过跟头。

打个比方。一排房间门牌号是 0、1、2、3……你想把 4 个房间合并成一个“大房间”，那么这 4 个房间的门牌号只能从 0、4、8 这种 4 的倍数开始。如果从 1 号开始合并，你就得把 0 号也吞进去，否则会留下一个无法归类的缺口。CIDR 聚合完全同理。

最后一行特容易踩坑：192.168.1.0/24 和 192.168.2.0/24 看着是“连续”的，但二进制里 1 是 00000001，2 是 00000010，从第 23 位开始就不一样了，它们没法精确合并成 /23。强行做只能拼出一个 192.168.0.0/22，把 192.168.0.0/24 和 192.168.3.0/24 也包进来。如果这两个“额外网段”已经被别的部门或者别的路由器占用了，这种聚合就会导致路由黑洞。所以做聚合之前，一定要先画一张网段分布表，逐位核对。

3. 实验环境与拓扑：用三台路由器把 CIDR 跑起来

3.1 工具选型

这个实验不需要真实机房，用模拟器完全够。目前主流的三个选择是 Cisco Packet Tracer、GNS3 和华为 eNSP。

Packet Tracer 的优势是上手快、拖拽就能建拓扑，适合刚接触网络的学生；缺点是命令风格偏思科模拟版，有些特性跟真机有差距。GNS3 需要自己准备 IOS 镜像，能跑真实系统，适合想深入钻研的人。eNSP 则是华为官方的模拟器，免费、内置常见设备型号，命令和真实华为设备几乎一致，国内很多教材和实验环境都在用它。

我个人建议用 eNSP 做这个实验，因为华为路由器的命令支持直接写前缀长度，比如 ip address 10.1.1.1 26，比思科必须写完整掩码 255.255.255.192 要直观得多，特别适合把注意力放在 CIDR 本身的逻辑上。如果你手上只有思科环境，也没关系，我会在关键命令处给对照，原理完全一致。

3.2 拓扑设计与地址规划

这个实验的拓扑我设计了三条路由器链路加三个下联区域：

text复制PC-A ----- R1 ------- R2 ------- R3 ----- PC-C
                 |
                 |-- LoopBack1~4（模拟R2下挂的4个子网）

R1 和 R3 下各挂一台 PC，R2 用四个 Loopback 接口模拟四个远端子网。为什么不用真实交换机接四台 PC？因为实验核心是 CIDR 和路由，不是交换和 VLAN，Loopback 接口天然代表“路由器后面一个网段”，能把无关复杂度降到最低。等你在 Loopback 上把路由和聚合的逻辑吃透了，再换回真实交换机，只是画蛇添足的重复劳动。

完整地址规划表如下：

这个规划隐藏了几层信息：互联链路用 /30，这是点对点链路的标准做法；R2 后面的四个 /26 恰好拼成一个完整的 10.1.1.0/24，为实验二的路由聚合留好了伏笔；LAN-A 是 10.1.0.0/24，LAN-C 是 10.1.2.0/24，它们和 R2 的 10.1.1.0/24 在二进制上是连续的三个 /24，但属于不同路由器，不能随意聚合到同一个下一跳——这一点在实验二里会专门验证。

3.3 基础配置命令

以华为 eNSP 为例，R1 的接口配置如下：

text复制system-view
sysname R1
interface GigabitEthernet0/0/0
 ip address 10.1.0.1 24
 undo shutdown
interface GigabitEthernet0/0/1
 ip address 10.0.12.1 30
 undo shutdown

R2 的互联接口和四个 Loopback 配置：

text复制system-view
sysname R2
interface GigabitEthernet0/0/0
 ip address 10.0.12.2 30
 undo shutdown
interface GigabitEthernet0/0/1
 ip address 10.0.23.1 30
 undo shutdown
interface LoopBack1
 ip address 10.1.1.1 26
interface LoopBack2
 ip address 10.1.1.65 26
interface LoopBack3
 ip address 10.1.1.129 26
interface LoopBack4
 ip address 10.1.1.193 26

这里有一个华为和思科的写法差异：华为在接口上配置地址时完全可以写 ip address 10.0.12.1 30，也就是“IP + 前缀长度”；思科则必须写成 ip address 10.0.12.1 255.255.255.252。很多从思科转到华为的人会不适应，但正是因为华为允许前缀长度简写，这个实验里你可以更直观地看到 /30、/26 这些 CIDR 前缀的实际效果。PC 的配置也不复杂：PC-A 配 10.1.0.10/24，网关 10.1.0.1；PC-C 配 10.1.2.10/24，网关 10.1.2.1。配好以后，先在各路由器上执行 display ip interface brief 确认接口 IP 都正确，再执行 display ip routing-table 查看直连路由。

4. 动手实验一：变长子网划分与路由配置

4.1 先看看没有静态路由时发生了什么

接口和 PC 都配置好以后，先不要急着加路由。在 R1 上执行 display ip routing-table，你只能看到两条直连路由：10.0.12.0/30 和 10.1.0.0/24。这时候从 R1 去 ping R2 的 10.1.1.65，结果是“不可达”，因为 R1 的路由表里根本没有 10.1.1.64/26 这个网段。这个“失败”本身就是实验的一部分，它能直观地告诉你：在没有路由的情况下，即使物理链路上数据包能到达 R2，R1 也不知道应该把包交给谁。很多新手排障喜欢先怀疑链路，看了这一步就应该明白，路由表缺失比链路故障更常见。

4.2 配置明细静态路由，让全网先通起来

要让全网互通，必须在每台路由器上添加去往非直连网段的静态路由。R1 需要去往 R2 后面的四个 /26，以及 R3 后面的 10.1.2.0/24，下一跳都指向互联链路对端的 R2 接口地址 10.0.12.2：

text复制ip route-static 10.1.1.0 26 10.0.12.2
ip route-static 10.1.1.64 26 10.0.12.2
ip route-static 10.1.1.128 26 10.0.12.2
ip route-static 10.1.1.192 26 10.0.12.2
ip route-static 10.1.2.0 24 10.0.12.2

R3 配置去往 R2 后面四个 /26 以及 R1 后面 10.1.0.0/24 的静态路由，下一跳都指向 10.0.23.1：

text复制ip route-static 10.1.0.0 24 10.0.23.1
ip route-static 10.1.1.0 26 10.0.23.1
ip route-static 10.1.1.64 26 10.0.23.1
ip route-static 10.1.1.128 26 10.0.23.1
ip route-static 10.1.1.192 26 10.0.23.1

R2 需要配置去往 R1 后面网段和 R3 后面网段的两条路由：

text复制ip route-static 10.1.0.0 24 10.0.12.1
ip route-static 10.1.2.0 24 10.0.23.2

注意下一跳不是对端路由器的名字，而是对端接口的 IP 地址。路由器转发数据包时，关心的只有“目的网段”和“下一跳地址”，设备名只是给人看的。这也是一个常见的理解误区。

配置完成后，全网应该能通了。在 R1 上依次 ping R2 的四个 Loopback 地址，再在 PC-A 上 ping PC-C，链路都应该是通的。此时 R1 的路由表里一共有多少条静态路由？5 条。R3 也是 5 条。这个“明细路由很多”的状态，正是实验二要改造的起点。

4.3 验证全通时顺便做一张记录表

建议把验证结果记录下来，这既是实验报告需要的素材，也能帮你形成边配置边验证的节奏感：

看到全通不要急着高兴，回到 R1 上执行 display ip routing-table，仔细观察路由表里那 5 条静态路由。它们分别指向 10.1.1.0/26、10.1.1.64/26、10.1.1.128/26、10.1.1.192/26 和 10.1.2.0/24。前三四个网段在逻辑上是连续的、并且都指向同一个下一跳，这就是聚合的绝佳对象。但是 10.1.2.0/24 是另一个“上层网段”，它和 10.1.1.0/24 也是连续的，能不能一并聚合？这个问题留给实验二回答。

5. 动手实验二：路由聚合的完整验证

5.1 把四条明细路由替换成一条汇总路由

实验二的目的是把 R1 和 R3 上指向 R2 后方的四条 /26 明细路由，替换成一条 10.1.1.0/24 汇总路由。

先来分析一下可行性：四个子网分别是 10.1.1.0/26、10.1.1.64/26、10.1.1.128/26、10.1.1.192/26，它们在地址空间上无缝覆盖了 10.1.1.0 到 10.1.1.255 整个 /24 块，而且这个块的全部地址都在 R2 后面，没被其他路由器占用。合并后的结果就是：

text复制ip route-static 10.1.1.0 24 10.0.12.2

删除原来的四条明细路由：

text复制undo ip route-static 10.1.1.0 26 10.0.12.2
undo ip route-static 10.1.1.64 26 10.0.12.2
undo ip route-static 10.1.1.128 26 10.0.12.2
undo ip route-static 10.1.1.192 26 10.0.12.2

R3 上也执行同样的替换，只是下一跳换成 10.0.23.1。此时再看 R1 的路由表，静态路由从原来的 5 条变成了 2 条：一条是 10.1.1.0/24，一条是 10.1.2.0/24。注意，10.1.2.0/24 不能并入 10.1.1.0/24 的汇总里，因为它的目标不在同一个后端；更重要的是，R1 自己还直连着 10.1.0.0/24，如果强行把 10.1.0.0/22 指向 R2，就会连自己的本地网段也包含进去，形成潜在的黑洞。这就是聚合时最容易犯的“贪心”错误。

5.2 看路由表变化，并验证全网依然互通

替换完成后，从 R1 ping R2 的四个 Loopback 地址，全部应该依然能通。原因很简单：R1 不需要关心 10.1.1.0/24 内部到底分了几个子网，它只需要把整个块扔给 R2；R2 再把包按照自己更细的直连路由送进对应的 Loopback 接口。这种“骨干路由器保持简单、边界路由器掌握细节”的分层思想，正是路由聚合存在的意义。

记录一下变化前后的路由表条目数，你会更直观地感受到聚合的价值：R1 上指向 R2 方向的静态路由从 4 条变成 1 条，路由表瘦身了将近一半。如果把这个思路放大到互联网骨干，原本几十万条明细路由可以被汇总成几万条大路由，路由器的内存压力、查表开销都会大幅度下降。

5.3 聚合的代价：黑洞、例外路由与兜底方案

聚合不是免费的午餐。汇总路由 10.1.1.0/24 覆盖的地址范围比四个 /26 大得多，它意味着 R1 会把凡是目的地址落在 10.1.1.0 ~ 10.1.1.255 之间的包，全部转发给 R2。如果这个范围内的某些地址其实并不在 R2 后面，而是在另一台路由器 R4 后面，那 R1 就会把属于 R4 的流量也一并丢给 R2，R2 查不到更精确的路由，只能丢弃，这就是“路由黑洞”。

解决黑洞的办法是利用最长前缀匹配原则：在该范围内的特殊子网上，配置一条更长的“例外路由”。比如假设 10.1.1.128/26 实际在 R4 后面，那么 R1 上应该同时配置两条路由：

text复制ip route-static 10.1.1.0 24 10.0.12.2
ip route-static 10.1.1.128 26 10.0.12.6

去往 10.1.1.130 的包，路由器会在路由表里找到 10.1.1.0/24 和 10.1.1.128/26 两条都匹配的条目，但前缀更长的 /26 优先，于是被精确送到 R4；其他 10.1.1.0/24 内的地址，走汇总路由交给 R2。这是 CIDR 实验里最核心、最实用的一条规则。

还有一个经验做法：在边界路由器上给汇总块配置一条指向 NULL 接口的黑洞路由。比如：

text复制ip route-static 10.1.1.0 24 NULL 0

这样，凡是目的地址落在 10.1.1.0/24 内、但设备上确实没有更精确路由的异常流量，都会被直接丢弃，而不会在路由器之间来回反弹形成环路。生产环境里，这条黑洞路由通常和聚合路由一起配置。

6. 实验中容易踩的坑与排查思路

6.1 电脑显示“IPv4 无网络访问权限”的真相

很多人在实验里给 PC 配完静态 IP，发现右下角网络图标直接提示“IPv4 无网络访问权限”，第一反应是网卡坏了、线没插好。但在这种拓扑里，极大概率是掩码或网关配置错了。举个例子，PC-A 的 IP 是 10.1.0.10/24，网关却写成 10.1.0.129，而 10.1.0.129 实际上是另一个网段的地址，PC 算一下自己的网络号是 10.1.0.0，网关所在网络号也是 10.1.0.0？不，/24 的网络号都相同，这里不会报错。真正容易踩的是：PC 配了 /25，IP 是 10.1.0.10，网关却设在 10.1.0.129，PC 算出来的网络号是 10.1.0.0，网关注册的网关地址 10.1.0.129 落在 10.1.0.128/25 这个子网里，两边网络号不一致，PC 就会认为网关不在本网段，连 ARP 请求都不会发，自然显示“无网络访问权限”。

排查思路也很固定。先在 PC 上执行 ipconfig /all，看 IPv4 地址、子网掩码、默认网关三个字段是否自洽；然后把 PC 的 IP 和网关 IP 分别转换成二进制，分别和掩码做“与”运算，确认两个网络号一致；最后再从 PC ping 网关，网关都 ping 不通，再往路由器接口查。这个流程不仅适用于实验，你以后在公司排查办公电脑上网问题，也是同一套逻辑。

顺带说一句，如果你看到 IP 是 169.254.x.x，说明网卡没从 DHCP 服务器要到地址，Windows 自动给自己分配了一个 169.254.0.0/16 的链路本地地址。这个地址只能用于同一链路内的临时通信，和大多数内网网关都不在同一个子网，所以一样会提示“无网络访问权限”。

6.2 广播地址与网络地址搞混

这是新手最容易犯的错，也是最让人抓狂的错。一个 10.1.1.64/26 子网，网络地址是 10.1.1.64，广播地址是 10.1.1.127，可用地址是 10.1.1.65 到 10.1.1.126。如果你不小心把某台设备的 IP 配成了 10.1.1.127，Windows 会直接提示该地址是广播地址不可用；如果你配成 10.1.1.64，同样不可用。在华为设备上给接口配置这样 IP，设备也不会报错，但你在验证时就会遇到“怎么 ping 不通”的怪现象。

更隐蔽的错误是把广播地址误当成子网掩码或者在网关配置里填了广播地址。记住一个口诀：全 0 是网络，全 1 是广播。所谓“全 0”和“全 1”，指的是主机位部分的二进制，而不是最后一个字节。比如 10.1.1.64/26，它最后一个字节的二进制是 01000000，主机位是最后 6 位，网络地址就是主机位全 0（即 01000000 = 64），广播地址就是主机位全 1（即 01111111 = 127）。不是所有网络地址都以 0 结尾，也不是所有广播地址都以 255 结尾，这一点在 CIDR 里尤其重要。

6.3 子网重叠与路由黑洞

用 CIDR 规划地址时，如果只靠肉眼从密密麻麻的 IP 里找问题，很容易漏掉重叠。一个典型场景是：R2 上配置了 10.1.1.0/26，R3 上又配置了 10.1.1.0/26，这两个网段在网络里重叠了。R1 收到去往 10.1.1.65 的包，路由表里可能出现两条相同前缀、不同下一跳的条目，结果要么负载分担把包乱发，要么一直走错误线路，最终形成黑洞。

排查重叠最有效的方法不是看配置，而是把所有网段列成一张表，按起始地址排序，再观察是否存在区间交叉。比如：

text复制10.1.1.0/26     起始 10.1.1.0    结束 10.1.1.63
10.1.1.64/26    起始 10.1.1.64   结束 10.1.1.127
10.1.1.128/26   起始 10.1.1.128  结束 10.1.1.191

一眼就能看出没有重叠。如果中间有一行 10.1.1.128/25，它的结束地址是 10.1.1.255，和前面某个网段重叠了，就需要重新规划。在实验里养成画表核对的习惯，到生产环境能省下大量排障时间。

6.4 汇总路由的“意外包含”

实验二里，四个 /26 完美拼成一个 /24，聚合非常干净。但现实不会总是这么理想。比如你手里有两个 /24，一个是 10.1.1.0/24，一个是 10.1.2.0/24，你想把两条合并成一条 /23，这时就要求起始地址 10.1.0.0/23 这个块必须整个都归你管。如果 10.1.0.0/24 还在别人手里，你合不出来，合出来就是事故。

判断“能不能精确聚合”的标准就是我前面强调的“块对齐”：聚合后块的起始地址必须能被块大小整除。实际操作时，先用公式算出聚合块大小，比如两个 /24 聚合是 /23，块大小是 2；再看起始地址是不是 2 的倍数。不是 2 的倍数，就要往更大的块去找，直到找到一个足够大的、起始地址对齐的块，同时确认这个大块里没有别人在用的网段。生产环境里做 BGP 路由聚合也一样，很多网络割接事故，都源于这种“看着连续、其实没对齐”或者“对齐了但吞了别人的网段”的疏忽。

7. 从实验台到生产网：CIDR 的真实应用场景

7.1 路由表里的 CIDR 印记

你去一台核心路由器上执行 display ip routing-table 或 show ip route，看到的已经不是 ABC 类地址的分类，而是一大堆前缀长度各不相同的条目：0.0.0.0/0 是默认路由，10.0.0.0/8 是某个大私有段，下面还挂着 10.1.2.0/24、10.1.2.128/25，甚至还有 203.0.113.10/32 这种主机路由。CIDR 已经渗透到路由表设计的每一个角落。

理解 CIDR 后，很多网络分析工作会顺手很多。比如你想查某个 IP 归属哪个运营商、哪个地域，借助 WHOIS 数据库查出来的结果往往就是一段 CIDR，如 203.0.113.0/24；你想判断两个 IP 是不是同一个网段，也只需要把它们的地址和掩码做几次与运算。就连平时有人找直播源，看到一串形如“IP:端口”的地址，想知道这个 IP 属于哪个地区，最终也要靠 CIDR 先定位到网段，再去查归属信息。可以说，CIDR 就是整个 IP 寻址体系的地基。

7.2 云上 VPC 和子网规划

到了云计算时代，CIDR 依然是你创建网络时第一个要填的选项。在云平台上建一个 VPC，系统会让你指定一个 CIDR 块，比如 10.0.0.0/16；创建子网时，又会让你从这个大块里划一个小块，比如 10.0.1.0/24、10.0.2.0/26。安全组规则、网络 ACL 里写的源地址和目的地址，也都是 CIDR 表示法，0.0.0.0/0 就是“所有来源”。

云上最常见的 CIDR 事故是多个 VPC 地址重叠。两个 VPC 想通过对等连接或云企业网打通，结果一个用 10.0.0.0/16，另一个也用 10.0.0.0/16，完全重叠，根本不通。解决办法只能换网段或做 NAT。这些决策看起来是云平台控制台里的几个点击，实际上背后全是对 CIDR 块、子网大小、可用地址数的精确计算。你现在花在实验里的换算功夫，将来都会在云上还回来。

7.3 从 IPv4 到 IPv6：前缀长度彻底取代掩码

IPv6 地址因为太长，几乎没人再写子网掩码，所有人都在说前缀长度。比如“这个客户分配了一个 /56”、“这个链路上用 /64”、“总部互联用一个 /127”。也就是说，IPv6 从设计之初就完全拥抱了 CIDR 的无分类思想，连“类”的概念都不存在了。能把 IPv4 的 CIDR 计算练熟，切换到 IPv6 的地址规划时会平滑很多，因为底层二进制逻辑是一模一样的：连续、对齐、汇总、最长匹配。

我在实际做地址规划时，习惯先把所有网段列成一张 CIDR 表，把网段、起始地址、结束地址、掩码、用途写清楚，再动手敲配置。看起来多花十分钟，实际省下的排错时间是以小时计的。如果这个实验对你有帮助，建议把“块对齐”和“最长前缀匹配”这两个点反复练透，它们才是 CIDR 的精髓。后面再去碰 OSPF 的区域间汇总、BGP 的 aggregate-address、云上 VPC 规划，你会发现翻来覆去都是同一个底层逻辑。