CIDR无分类编址详解：子网划分、路由聚合与最长前缀匹配

互联网早年有个特别拧巴的问题：IPv4 地址本来是按 A、B、C 类固定分档的，可真正用起来，要么一个 B 类地址段大得离谱根本用不完，要么一个 C 类地址段又小得可怜不够塞牙缝。与此同时，核心路由器的路由表被各种零碎网段撑得越来越胖，转发效率直线下降。无分类编址 CIDR就是冲着这两个痛点来的，它把“分类”那层硬壳直接敲碎，让 IP 地址的分配和路由有了完全不同的玩法。这篇《计算机网络》系列第十九篇，我把 CIDR 的前因后果、核心原理、手算方法和避坑经验一次说透，搞懂这一篇，你以后看路由表、划子网、做聚合，都会清爽很多。

CIDR 不是什么考试专属概念，也不是只在思科模拟器里才能用到的玩具。它本质上就是现代 IP 网络的路由与编址基础，你在云控制台配 VPC 网段、在公司交换机上写静态路由、看route -n的输出，背后全是 CIDR 那套逻辑。下面我会先用一个特别朴素的视角解释“为什么非要无分类”，再拆几个实际算例，最后把考试和工作里最常见的坑一次讲清楚。不管你是准备 408 考研、正在学 Devops 方向的网络基础，还是工作中被 CIDR 卡住过，这篇都能直接拿来用。

1. 从分类编址到 CIDR：一场被地址枯竭逼出来的架构革命

1.1 分类编址到底哪里有问题

早期的 IPv4 设计把地址分成 A、B、C 三类，用第一个字节的范围就能看出属于哪类。A 类地址前 8 位是网络号，默认掩码 255.0.0.0，一个 A 类段能容纳 1677 万台主机；B 类地址前 16 位是网络号，默认掩码 255.255.0.0，一个段能容纳 65534 台；C 类地址前 24 位是网络号，默认掩码 255.255.255.0，一个段只有 254 台可用地址。

这套逻辑听起来规则清晰，可实际一用就出问题。大多数公司其实只需要几百个 IP，但申请的时候只能选 B 类段，于是一申请就是 65534 个地址，真正用掉的往往不到 1%，浪费极其严重。反过来，某些小型 ISP 想要跨越骨干网的连续地址块，C 类那 254 个地址又根本不够。这种“要么撑死、要么饿死”的体质，在互联网规模指数级膨胀的背景下完全撑不住。

更麻烦的是路由表。每个 A 类、B 类、C 类网段都代表一条独立的路由条目，随着接入的网络数量爆炸式增长，核心路由器要维护几十万条、上百万条路由，内存和 CPU 都成了瓶颈。我当年看老工程师调核心路由器的转发表，光一个show ip route summary的数据就能刷满半屏，他跟我说了一句我现在还记得的话：“地址还没用完，路由器先撑不住了。” CIDR 就是在这样的背景下被推到前台的。

1.2 CIDR 的核心思想：把“类”这个包袱丢掉

CIDR 的中文全称是“无分类域间路由”，关键就是那个“无分类”。它不再看你是 A 类还是 B 类还是 C 类，而是直接告诉你：这个地址块的前多少位属于网络前缀，剩下的位都是主机位。

表达方式也换成了斜杠记法。192.168.1.0/24表示前 24 位是网络前缀，后面 8 位是主机位；10.0.0.0/8表示前 8 位是网络前缀，后面 24 位全是主机位。斜杠后面的数字就是前缀长度，前缀越长，能容纳的主机越少；前缀越短，能容纳的主机越多，但能划分的独立网络数也越少。

这个“长度可变”就是 CIDR 的精髓。分类编址相当于商场只有 S、M、L 三个码的衣服，你穿了不合适也只能将就；CIDR 则相当于裁缝量体裁衣，你的组织有 500 台机器，我就给你一个/23，两条 C 类地址拼起来，500 台刚好装下。这种灵活性让地址利用率大幅提升，也让网络设计者第一次真正掌握了“粒度”的控制权。

这里有个容易搞混的点：CIDR 并没有废除子网掩码。子网掩码依然存在，只是它的作用从“识别地址类别”变成了“指示前缀长度”。/24对应的掩码是255.255.255.0，/20对应的掩码是255.255.240.0。你看到掩码就应该能立刻换算出前缀长度，看到前缀长度也应该能立刻写出掩码，这是最基础的功夫。

1.3 CIDR 对路由表的减负作用

CIDR 直接带来一个巨大的红利——路由聚合，也叫路由汇总、超网。原理特别朴素：多个连续的 IP 地址块如果具有相同的前缀，就合并成一条路由发布，路由表条目数量因此大幅减少。

举个直观的例子。过去你在公司内部网络规划了 8 个 C 类网段：172.16.0.0/24到172.16.7.0/24，如果没有 CIDR，核心路由器就得维护 8 条路由。但好消息是这 8 个网段的前 21 位完全相同，完全可以用172.16.0.0/21一条路由代表它们。路由器看到目标地址在172.16.0.0到172.16.7.255范围内，就直接把数据包丢给这条路由的下一跳。8 条变 1 条，路由表瞬间瘦身。

我记得有个比喻特别形象：路由聚合就像快递公司把同一个片区的几百个包裹统一装车。每件包裹的地址都精确到门牌号，但快递员不需要在路由表里记录每一户人家，只需要记“这个片区的所有包裹，都送往该片区的集中分拣点”。到了分拣点再按门牌分发。CIDR 让全网的路由转发都变成了“先粗分、再细分”的模式，核心路由器只关心大方向，具体细节交给边缘设备处理，整个互联网的扩展性就是这么撑起来的。

2. 核心细节全拆解：前缀、掩码、地址块、广播地址，一个都不能少

2.1 网络前缀：CIDR 世界里唯一的“标尺”

CIDR 地址的二进制表示可以抽象为：网络前缀 + 主机号。斜杠后面的数字，就决定了前缀和主机号的分界线在哪里。这个数字不是随便取的，它必须是一个 0 到 32 之间的整数，IPv4 地址总共 32 位，前缀占多少位、主机就剩多少位，二者相加永远等于 32。

前缀长度直接决定了地址块的大小。计算容纳主机数量的公式是 2 的（32 减去前缀长度）次方再减 2，因为全 0 的主机号代表网络地址本身，全 1 的主机号代表广播地址，这两个地址不能分配给真实设备。比如/24：2 的 (32-24) 次方等于 256，减去网络地址和广播地址，可用主机数是 254。

这里我要特别提醒一个使用频率极高的前缀：/30。它只有 4 个地址，可用主机数是 2，恰好够一条点到点链路的两个端口使用，所以点对点互联接口基本都用/30。你去查看核心路由器之间的互联端口，掩码几乎清一色是255.255.255.252，也就是/30。反过来，/31比较特殊，RFC 3021 允许它在点到点链路中使用，将两个可用地址全部用满，不再保留网络地址和广播地址，但很多老设备和考试题并不认可这种用法，我个人的建议是：除非你明确知道对方支持，否则点对点链路老老实实用/30，避免兼容性麻烦。

2.2 地址掩码与前缀互转：一张表背熟就行

掩码和前缀之间的转换是 CIDR 实操的基本功。你不需要每次都拿计算器，几个常用值必须形成条件反射：

怎么快速算任意前缀的掩码？核心方法：从 255.255.255.255（也就是 /32）开始，把二进制中的高位 1 逐个变成 0，每借出 1 位，对应位置的 128、64、32、16、8、4、2、1 就从掩码里减掉。

举例来说，从 /32 往前数，/31 少一位，掩码是255.255.255.254，二进制是...11111110；/30 少两位，掩码是...11111100，即255.255.255.252。如果觉得按位倒退太麻烦，也可以记规律：掩码最后一个非 0 字节，等于 256 减去地址块大小。比如/26的地址块大小是 64，最后一个字节掩码就是 256 减 64 得 192，所以是255.255.255.192。这个“256 减块大小”的方法，我直到现在还在用，手算效率特别高。

2.3 网络地址和广播地址：边界判断必须一次算对

拿到一个 CIDR 地址块，第一件事就是确认它的起始地址（网络地址）和结束地址（广播地址）。这两个边界定错了，后面所有规划全部崩盘。

计算方法也简单：把 IP 地址和掩码做按位与，得到的就是网络地址；把网络地址的主机位全部置 1，得到的就是广播地址。

举个例子，202.100.10.129/25。掩码是255.255.255.128，网络地址是202.100.10.128，广播地址是202.100.10.255，可用主机范围是202.100.10.129到202.100.10.254。注意202.100.10.129虽然是这个地址块里的第一个可用地址，但不是网络地址，网络地址是202.100.10.128。这个细节经常在考试和面试里挖坑。

再举一个容易错的地方：192.168.1.66/27。掩码是255.255.255.224，也就是最后一个字节是11100000，地址块大小是 32。从 0 开始数，这个地址落在第 2 个块里：第 0 个块是192.168.1.0到192.168.1.31，第 1 个块是192.168.1.32到192.168.1.63，第 2 个块是192.168.1.64到192.168.1.95。所以网络地址是192.168.1.64，广播地址是192.168.1.95。这种“先算块大小，再定位块号”的思路，比硬转二进制要快得多。

我在实际项目里见过一个特别经典的错误：有同事给一台服务器配了10.20.30.66/26，网关10.20.30.1，结果怎么都不通。我一看就发现问题：/26的块大小是 64，网络地址是10.20.30.64，广播地址是10.20.30.127，而网关却配置在10.20.30.0/26这个子网里，二者根本不在同一网段。服务器和网关跨网段，链路层直接不通，路由表里又没有额外路由，自然访问不了。这种低级错误在机房现场排查起来特别折腾，手里没个表就很容易绕晕。

2.4 为什么全 0 和全 1 主机号不能用

很多初学者会问：为什么偏偏要把全 0 和全 1 的主机号扣掉？网络地址要用来表示这个网段本身，路由器在路由表里记录的正是这个地址；而广播地址用于向本网段所有主机发送数据报文。如果敢把这两个地址分配给某台服务器，会造成寻址混乱，既影响本机的正常收发，也影响整个子网的广播机制。

在早期分类编址时代，还允许某些特殊场景使用全 0、全 1 网络号，但 CIDR 时代为了避免二义性，规则更严格。除非像0.0.0.0/0这种默认路由，或者127.0.0.0/8这种环回地址块，常规业务网段的网络地址和广播地址都是要避开的。考试的时候特别爱考这一点：题目给了/29让你算可用地址数，答案永远是 8 减 2 等于 6，不是 8。

3. 实操演练：子网划分与路由聚合的手算全流程

3.1 需求驱动的子网划分完整案例

CIDR 的实战第一步是“按需分配”。假设公司拿到一个202.100.10.0/24的地址段，现在需要给四个部门划分子网：研发部需要 100 台可用地址，市场部需要 50 台，财务部需要 20 台，运维部需要 8 台。传统分类编址面对这种需求只能干瞪眼，CIDR 则可以从容处理。

先看研发部，100 个可用地址需要主机位至少 7 位，因为 2 的 7 次方减 2 等于 126，刚好够；如果是 6 位主机，只有 62 个可用地址，不够。所以研发部子网的前缀长度是 32 减 7 等于 25，即/25。从202.100.10.0/24中取出202.100.10.0/25给研发部，地址范围202.100.10.0到202.100.10.127，可用地址202.100.10.1到202.100.10.126。

接下来市场部要 50 台，主机位需要 6 位，因为 2 的 6 次方减 2 等于 62。前缀长度 26，取202.100.10.128/26，范围202.100.10.128到202.100.10.191。财务部要 20 台，主机位需要 5 位，因为 2 的 5 次方减 2 等于 30。前缀长度 27，取202.100.10.192/27，范围202.100.10.192到202.100.10.223。运维部要 8 台，主机位需要 4 位，因为 2 的 4 次方减 2 等于 14，前缀长度 28，取202.100.10.224/28，范围202.100.10.224到202.100.10.239。

最后整个/24还剩202.100.10.240到202.100.10.255，也就是一个/28，可以作为预留段给未来扩展，也可以作为管理网段。这样整个规划严丝合缝，没有一个地址重叠，也没有浪费任何一个块。这个例子是典型的“从大到小逐级切分”，你每次切分都要保证剩余空间足够覆盖后面的需求，这也是子网划分的核心策略。

3.2 路由聚合实例：多条明细路由如何折叠成一条

路由聚合是 CIDR 的另一个高价值技能。假设你是一家二级运营商的网络工程师，从上级运营商那里拿到了 8 个连续的 C 类地址段，需要把它们聚合成一条路由对外通告。这时聚合的关键就是看这些网段的二进制。

假设 8 个网段是202.100.8.0/24到202.100.15.0/24，先把第三字节列出来：8 是00001000，9 是00001001，10 是00001010，11 是00001011，12 是00001100，13 是00001101，14 是00001110，15 是00001111。前 5 位完全相同，都是00001，第 6 位才开始变化。第三字节共 8 位，前 5 位已确定，前缀长度就是 16 加 5 等于 21，所以这 8 条路由可以聚合成202.100.8.0/21。

到这里有人会问：是不是只要网段连续就能聚合？不一定。还需要看起始地址是否“对齐”。如果网段从202.100.9.0/24开始连到202.100.16.0/24，这 8 个网段就无法用一个/21聚合，因为起始地址不在/21的块边界上。做聚合前先检查起点是不是块大小的整数倍，这是老工程师的基本素养。

现实场景中可能遇到聚合不了的零散网段，这时候宁可多留两条明细路由，也不要强行聚合。强行聚合只会把不相关的大网段一并吸收进来，造成路由黑洞或者路由环路，风险远大于收益。我见过一个经典的生产事故：有人把10.1.0.0/24和10.2.0.0/24强行聚合成10.0.0.0/8发布，结果把整个私网 10 段全部宣告了出去，数据包全被导向错误出口，全网大面积断连。所以聚合之前，务必核对边界。

3.3 规划一个企业私网地址池的实操思路

私网地址规划是 CIDR 用得最多的工作场景。RFC 1918 规定了三个私网段：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。规模较大的企业通常选10.0.0.0/8，因为地址空间巨大，划分弹性最好。

我个人的习惯是，先按地域或业务模块划分大块，再在大块里按机房或部门继续细分。比如总部用10.0.0.0/16，数据中心用10.10.0.0/16，各个分公司按区域从10.20.0.0/16开始往后排；每个分公司内部再把网段切成/24，按用途分配：办公网、服务器网、视频监控网、打印机网、访客网，互不相通。

另一个容易忽略的是“预留”策略。我强烈建议做规划的时候预留 30% 到 50% 的地址段，而不是一次性全分光。因为后期大概率会冒出新的业务需求，而已经分配出去的网段很难再收回来。在很多公司，IP 地址规划表一旦定稿就很难调整，牵一发动全身，路由策略、防火墙策略、DHCP 池全部关联，提前预留是一种低成本高回报的自我保护。

3.4 手算技巧速成：不查表也能秒出网络边界

我给初学者推荐一套手算流程，熟练之后速度非常快。

第一步，算出块大小，公式是 256 减去掩码最后一个非零字节的值。比如掩码255.255.255.224，块大小就是 256 减 224 等于 32。第二步，用 IP 地址的最后一段除以块大小，取整数商，再乘以块大小，得到的数就是本子网的起始地址。比如 IP 是192.168.1.77，77 除以 32 整数商是 2，2 乘 32 得 64，起始地址就是192.168.1.64。第三步，起始地址加块大小再减 1，得到广播地址：64 加 32 减 1 等于 95，也就是192.168.1.95。可用地址就是 65 到 94。

这套方法本质上是在说：任何子网的网络地址，都必须是块大小的整数倍。记住了这条铁律，你就不容易被地址绕晕。画 VLSM 或者写 ACL 的时候，我都是先在心里过一遍“块大小对齐”，基本不会错。

4. 最长前缀匹配：路由器如何在无数条路由里选对那一条

4.1 为什么匹配越长越优先

CIDR 流行之后，同一个目的地可能同时命中多条路由。比如路由器上同时存在0.0.0.0/0默认路由、10.0.0.0/8、10.1.0.0/16、10.1.2.0/24这四条路由，现在有一个目标是10.1.2.55的数据包，它到底走哪条？

答案是走最精确的那条，即网络前缀最长的那条，也就是10.1.2.0/24。因为前缀越长，匹配范围越小，地址越具体，路由决策越精准。这个原则用英文叫 Longest Prefix Match，是 CIDR 时代路由器的基本行为准则，路由表的查表过程也从“找第一个匹配项”变成了“在所有匹配项中找最长前缀项”。

这个设计符合人的直觉：你要去写字楼里某个公司，总不可能走“全国”这条默认路径，肯定先锁定城市，再锁定街道，再锁定楼栋。0.0.0.0/0相当于“任何地方都可以走的兜底路径”，只有前面所有更具体的路由全部不匹配时，默认路由才兜底。

4.2 路由表查表过程与 CEF 转发的联系

实际路由器转发时，如果每条数据包都去线性扫描路由表，性能无法接受。现代设备普遍采用一种基于前缀长度的树形查找结构，从最长前缀开始尝试匹配，匹配不到再逐级缩短前缀长度，直到命中或落入默认路由。

这里我想顺带提一句：你写静态路由时无法控制路由器对同一条目的选择顺序，唯一能决定优先级的就是前缀长度。如果两条路由的前缀长度相同，再看管理距离；管理距离也相同，再看度量值。但这些都是后话，CIDR 时代最优先的决定因素永远是前缀长度。这也是为什么配置路由时，默认路由前缀一定是/0，它一定是兜底中的兜底。

4.3 最长前缀匹配在 VPC 和云网络中的体现

现在很多公司都在云上建 VPC，VPC 里的路由表同样遵循最长前缀匹配。你在云控制台配路由表，一条0.0.0.0/0指向互联网网关，一条10.0.0.0/8指向对等连接，一条10.0.1.0/24指向某台 NAT 实例，这个路由表的优先级排序依然是最长前缀优先。

我记得有一次排障，业务方说流量没走 NAT 网关，直接跑了公网出口，查了半天发现是路由表里多了一条0.0.0.0/0，把它放在了 NAT 路由前面。但实际原因不在顺序，而是 NAT 那一条写错了前缀，写成/16，业务实际 IP 落在/16之外，最长前缀匹配反而让数据包走了默认路由。这个案例特别典型，排查思路是：先看数据包目的 IP，再反推路由表里哪条前缀最长，基本能定位问题。

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

5.1 掩码写错导致跨网段不通

这是 CIDR 实践中最常见的问题。症状是：服务器 IP 看起来在同一网段，但互相 ping 不通，或者能 ping 通网关却访问不了外网。原因往往是掩码写错，导致设备计算出的网络地址不在同一个子网里。

排查技巧：在设备上执行ip addr或ipconfig，仔细核对本机 IP、掩码、网关三者是否属于同一网段。用 2.2 里的手算方法快速算一下网络地址。如果网关地址在网络地址之外，立刻能看出来。我建议在所有网络设备的规划文档里，把网段写成 CIDR 形式，比如10.10.10.0/24，别只写掩码255.255.255.0，这样大家对齐信息时一眼就能知道边界在哪。

5.2 路由聚合过头导致业务不可达

路由聚合的副作用就是把不相关的小网段吸收进大网段。如果一个大网段里混杂了不该走同一路出的地址，数据包就会发往错误下一跳。

排查思路：在路由器上用show ip route查看聚合路由的明细，再用show ip route 目标地址查数据包实际命中的路由。如果命中的是一条掩码比明细路由更长的聚合路由，而且下一跳不对，那基本就是聚合过头。解决办法是把聚合路由改成若干条更小的路由，确保前缀长度和真实网络范围匹配。

5.3 地址重叠导致路由黑洞

内网规划时如果不小心让两个业务使用了重叠的网段，路由表里会出现相同前缀却指向不同下一跳的条目，最终只有一条生效，另一个业务必然出现间歇性不可达。

这类问题的排查很考验耐心。建议用 IP 地址管理工具或者最简单的 Excel 表，把所有已分配网段集中管理，做任何新分配前先检查是否与现有网段重叠。我在写测试环境脚本时，经常顺手用ipcalc检查网段范围和重叠情况，命令行下几秒钟就能出结果，不比专业软件慢。

5.4 CIDR 考试与面试高频坑位盘点

考试和认证里最常挖的坑无非这几类：一是把可用主机数算成 2 的 N 次方而不是 2 的 N 次方减 2；二是在有类网络里使用无类掩码却没有写 CIDR 记法；三是子网划分时没有按“块大小对齐”原则计算，导致起始地址错了；四是聚合时没有检查起始地址是否为聚合块大小的整数倍。

这些坑说穿了都是“边界条件”问题。如果你能在做题或者面试时主动列出网络地址、广播地址、可用地址范围三个值，就已经比大多数候选人扎实了。我自己带人的时候，必问的一个问题是：给你172.16.5.100/20，它的网络地址是多少？很多人会脱口而出172.16.5.0，正确答案是172.16.0.0，因为/20的块大小是 16，第三字节只要小于 16 都落在起始为 0 的块里。这种题目就是测你是否真的理解了“前缀是 20 位”这个事实。

6. 备考与工程双线作战的实用建议

6.1 学 CIDR 时最有效的三种练习方式

第一，每天手算 10 道“给你 IP 和前缀，求网络地址、广播地址、可用范围”的题。不用任何工具，就用块大小对齐法，练到形成肌肉记忆。第二，在真实环境里查看路由表，对照理解每条路由的前缀和下一跳。第三，用网络模拟器搭建一个多子网互通的实验环境，亲手搭完再拆掉，感受一下 CIDR 对整个网络拓扑的影响。

如果是在准备 408 考研或者网络工程师认证，推荐把谢希仁《计算机网络》中关于 IP 编址和 CIDR 的章节反复精读，再配合王道考研的练习题集，把计算题刷熟。我见过很多人只看书不刷题，结果遇到变体题就慌，其实 CIDR 的题目翻来覆去就那么几种模型，刷够 50 道题基本就通了。

6.2 工程实践中的三个铁律

铁律之一是“凡事写 CIDR 记法，不要只写掩码”。不管是需求文档、机房标签、监控面板还是变更记录，CIDR 记法都比点分十进制掩码更直观、更不容易被误解。铁律之二是“分配前必须查重”，哪怕是临时测试用的网段，也要先确认不会和生产网段重叠。铁律之三是“改动前先看路由表，改动后立刻验证”，任何人都不应该凭直觉在核心路由器上增删聚合路由。

这三条铁律听起来都很基础，但真正能在压力下坚持执行的人并不多。网络变更最怕的就是“想当然”，CIDR 相关的变更尤其如此，因为一个小数点的差别，影响范围可能是一个大网段。做好变更前备份、变更后校验，是对自己负责，也是对线上业务负责。

6.3 关于 CIDR 的最后一个建议

CIDR 只是整个 IP 网络体系里的一环，但它连接了 IP 地址规划、子网划分、路由聚合、路由查找等多个关键领域。把这部分学透，你会发现自己看路由表的能力、排障的直觉，都会明显上一个台阶。

我个人在实际工作中的体会是：不要死记公式，要把“块大小、起始对齐、前缀长度”这三个概念内化成一种直觉。遇到任何 IP 和掩码，先在心里画一下那个二进制分层结构，然后迅速判断它落在哪个块里。这种能力不是一朝一夕练成的，但一旦形成，你在处理任何 CIDR 相关问题时都会感觉踏实很多。

折腾网络这几年，我最大的感受是：协议设计从来不是凭空掉下来的理论，每个看似“弯弯绕绕”的规则背后都有真实世界的约束和代价。CIDR 之所以能取代分类编址，不是因为它更“高级”，而是因为它更灵活、更省地址、更能让路由器跑得动。理解了这层逻辑，你就不再是背规则的人，而是能跟网络协议“对话”的人。希望这篇第十九篇的拆解能帮你把这块硬骨头啃下来，也欢迎你在评论区聊聊自己踩过的 CIDR 的坑。