1. 为什么要聊CIDR从一次真实的上网困境说起说实话网络技术里CIDR这个概念教科书上翻来覆去就那几页但真正把它用明白的人不多。我最早接触CIDR是在做IDC机房网络规划的时候当时公司拿到一个/22的地址段要分配给十几个业务线人手一份VLAN表对着算算得头皮发麻。后来彻底搞懂了CIDR的子网划分与聚合逻辑才发现很多看似复杂的网络规划本质上就是一道前缀长度的数学题。这篇笔记我围绕IP地址与网络协议的基本盘专门把CIDR无类别域间路由拆开讲清楚。内容主要覆盖CIDR解决了什么问题、前缀长度与网络掩码怎么换算、子网划分与路由聚合怎么做、最长前缀匹配如何进行、以及实际配置中常见的坑。不管是刚开始学网络的在校生还是要做VPC规划、企业网段设计的运维和开发这篇内容应该都能帮你在脑子里立起一张CIDR的“计算表”。CIDR的全称是Classless Inter-Domain Routing中文通常叫无类别域间路由。它的核心概念其实只有一句话把IP地址空间从“固定类别”的框架中解放出来让网络前缀的长度由你说了算而不是被A/B/C类地址锁死。2. 分类编址到底输在哪里地址浪费与路由表爆炸理解CIDR的价值得先看看它出现之前的世界。早期IP地址采用的是“有类编址”方案也就是大家熟悉的A类、B类、C类、D类、E类划分。这个方案在思路上很直接按首位bit判定类别每个类别有固定的默认掩码。A类地址段首位为0地址范围从0.0.0.0到127.255.255.255默认掩码是255.0.0.0也就是/8。B类地址段首位为10范围从128.0.0.0到191.255.255.255默认掩码255.255.0.0也就是/16。C类地址段首位为110范围从192.0.0.0到223.255.255.255默认掩码255.255.255.0也就是/24。这样分类的结果就是你只能用三种固定大小的“筐”去装IP地址巨型筐A类、中型筐B类、小型筐C类。这带来的问题放到今天的网络环境里极其致命。2.1 地址空间严重浪费一个机构如果申请到一个B类地址段哪怕它只需要几千个IP也拿走了65,534个可用地址。余下大部分IP就只能躺在地址池里睡大觉。IPv4的地址总量只有2的32次方约43亿个按这种粗放的分配方式很快就不够用了。我记得有资料统计过在启动CIDR改造之前全球B类地址段的实际利用率普遍不到10%这是非常低效的分配。2.2 路由表条目激增有类寻址还带来另一个灾难路由表持续膨胀。互联网骨干路由器需要保存通往每个网络的路由条目。如果不做任何聚合全球每新增一个B类或C类地址段骨干路由器就要在转发表里增加一条记录。在20世纪90年代初骨干路由表已经膨胀到数万条而且还在加速上涨。那时候的路由器硬件性能和内存都和今天没法比路由表一膨胀转发决策变慢整网的稳定性和可扩展性都受到直接影响。CIDR就是在这样的背景下被提出的。它打破了“有类”的固定边界允许你以任意位的长度来宣布网络前缀比如/23、/20、/13等等。于是你想怎么切就可以怎么切想聚合也可以把一堆连续的小段合并成一个大段。这个改变看起来只是“把掩码变灵活了”但影响是结构性的。它带来了两个直接收益第一地址分配可以按需匹配实际规模减少浪费第二通过路由聚合即超网化把连续的小地址段聚合成一个大的前缀通告出去显著压低全球路由表的条目数量。3. CIDR表示法前缀长度、掩码与地址块计算CIDR的表示法非常简洁就是在IP地址后面加一个斜杠和数字比如192.168.1.0/24。这个数字表示的是网络前缀的长度也就是从最高位开始连续的“1”的个数。理解这一点是做所有子网划分和聚合计算的基础。3.1 前缀长度与子网掩码的对应关系网络掩码写成二进制前面是连续的1后面是连续的0。斜杠后的数字就是掩码中二进制“1”的数量。所以我们可以直接得到换算表前缀长度子网掩码十进制可用主机数减2后的值/8255.0.0.016,777,214/16255.255.0.065,534/24255.255.255.0254/25255.255.255.128126/26255.255.255.19262/27255.255.255.22430/28255.255.255.24014/29255.255.255.2486/30255.255.255.2522/31255.255.255.2542特殊用途P2P链路/32255.255.255.2551单机路由有个基础知识点必须先说清楚一个网段里的网络地址主机位全为0和广播地址主机位全为1是不能分配给设备使用的。比如/24总共256个IP减去网络地址和广播地址实际可用254个。同理/30只有4个IP减掉两个特殊地址只剩下2个可用IP通常用在点对点链路的环境里。3.2 地址块大小的快速心算法不做二进制转换也有一个快速心算方法前缀长度每减小1地址数量翻一倍。/24有256个地址/23就有512个/22就有1024个依此类推。反过来/25是128个/26是64个/27是32个。这种翻倍关系用熟了以后你看到任何前缀长度基本都能在3秒内估出地址块规模。举个例子某云厂商给你分配了一个10.0.0.0/20的VPC网段立刻能算出这个网段有2的(32-20)12次方也就是4096个地址扣除保留地址后可用约4091个具体保留规则因平台而异一般会预留网络地址、广播地址以及网关地址。3.3 网络边界与广播地址的计算判断一个IP属于哪个网段、网络地址和广播地址是多少这是无论是配服务器IP、做ACL还是做网络排障都必须掌握的基本功。方法并不复杂先将IP地址和掩码都转换为二进制然后做逐位“与”运算。掩码中为1的位保留IP的原始位掩码中为0的位结果强制置0。得到的32位二进制数就是网络地址。将网络地址的主机位全部置为1得到的就是广播地址。我常用的是更快速的十进制做法。比如要判断192.168.1.137/26先算出每个子网块的大小为64因为/26掩码的最后一个字节是192块大小是256-19264。然后找到137落在哪个块里64137128所以它属于192.168.1.128这个子网。该子网的网络地址是192.168.1.128广播地址是下一个块开始位置减1即192.168.1.191可用主机范围就是129到190。这个方法不用写二进制效率高很多。4. 手把手做一次子网划分与路由聚合CIDR的核心能力一个是“分”一个是“合”。分是子网划分合是路由聚合。我结合一套实际可操作的示例把这两个过程完整演示一遍。4.1 子网划分把一块大地址切到刚刚好假设公司申请到了一个公网地址段203.0.113.0/24。现在要把它拆分给四个部门研发部需要100个可用IP市场部需要50个可用IP财务部需要20个可用IP人事部需要10个可用IP这里有一个初学者很容易犯的错误直接用可用主机数去对应IP总数。比如研发部需要100个可用IP但网络地址和广播地址不能分配所以实际要占用的地址块必须大于102。2的7次方是128减去2正好126个可用地址所以研发部至少需要一个/25128个地址的块。继续算市场部需要50个可用IP明确需要大于52。2的6次方是64减去2为62所以分配一个/2664个地址的块。财务部需要20个可用IP至少22个地址。2的5次方是32所以分配一个/2732个地址的块。人事部需要10个可用IP至少12个地址。2的4次方是16所以分配一个/2816个地址的块。接下来从203.0.113.0/24里依次切分。注意CIDR子网划分必须从块边界开始也就是起始地址必须是块大小的整数倍。研发部从203.0.113.0/25开始范围是203.0.113.0到203.0.113.127。市场部紧跟着从203.0.113.128/26开始范围是203.0.113.128到203.0.113.191。财务部从203.0.113.192/27开始范围是203.0.113.192到203.0.113.223。人事部从203.0.113.224/28开始范围是203.0.113.224到203.0.113.239。最后剩余了203.0.113.240到203.0.113.255这16个地址可以作为预留段也可以分配给未来的新部门。这份划分方案可以用一张表清晰梳理部门需求可用IP分配前缀地址范围网关可用起始IP研发部100/25203.0.113.0/25203.0.113.1市场部50/26203.0.113.128/26203.0.113.129财务部20/27203.0.113.192/27203.0.113.193人事部10/28203.0.113.224/28203.0.113.2254.2 路由聚合把一串小网段合成一个通告在核心路由器上如果有多条连续的子网路由我们完全可以把它们聚合成一条更短的前缀来通告从而减小路由表。假设公司有四个连续的/24网段198.51.100.0/24、198.51.101.0/24、198.51.102.0/24、198.51.103.0/24。判断这些网段能否聚合成一条路由关键看它们是否在二进制上连续并且起始地址是否对齐。这4个网段的第三个字节0、1、2、3对应的二进制为00000000、00000001、00000010、00000011。可以看到前6位是完全一致的都是000000也就是聚合后的前缀长度为16622。所以这4个/24可以聚合成一条路由198.51.100.0/22通告给上层即可。但这里有一个经典的反例如果4个网段是198.51.100.0/24、198.51.101.0/24、198.51.102.0/24、198.51.103.0/24可以聚合。但如果换成198.51.100.0/24、198.51.101.0/24、198.51.102.0/24再加一个198.51.104.0/24就不能直接聚合成/22了因为10001100100、10101100101、10201100110、10401101000的二进制前缀并不完全一致。遇到这种情况一个稳妥的做法是聚合成两条/23198.51.100.0/23和198.51.102.0/23再加一条198.51.104.0/24然后看上游路由器是否有更长的掩码黑洞风险再做进一步处理。4.3 边界不对齐时的调整策略实际运维中地址块并不总是从0开始。比如有人给你分配了172.16.4.0/24到172.16.7.0/24这四个连续网段让你聚合。先看172.16.4.0/24、172.16.5.0/24、172.16.6.0/24、172.16.7.0/24第三个字节分别是00000100、00000101、00000110、00000111前6位都是000001所以可以直接聚合成172.16.4.0/22。但如果从172.16.3.0/24开始到172.16.6.0/24结束这4个网段的第三个字节为00000011、00000100、00000101、00000110它们前5位相同但无法被一个/22完整覆盖。最合理的聚合方式是分别宣告172.16.3.0/24和172.16.4.0/22这两条路由虽然多了1条但能保持路由的精简又不引入覆盖错误的黑洞风险。5. 路由器如何选路最长前缀匹配原则CIDR引入了更灵活的前缀之后一个不可能回避的问题出现了路由表里可能同时存在多条前缀不同的路由它们都能匹配同一个目的IP这时到底该选哪条答案是最长前缀匹配Longest Prefix MatchLPM。也就是谁的掩码长匹配到的地址范围更精确就优先选谁。这也是现代路由器和三层交换机的标准转发逻辑。5.1 一个容易看懂的选路示例假设路由器路由表里有下面三条路由0.0.0.0/0 下一跳 Gateway_A默认路由172.16.0.0/16 下一跳 Gateway_B172.16.100.0/24 下一跳 Gateway_C现在有一个目的IP是172.16.100.55的报文到达路由器路由器会拿路由表里的每条路由和这个IP做匹配。三条路由都能匹配上但172.16.100.0/24的掩码是/24比/16和/0都长因此路由器会毫不犹豫地选择下一跳Gateway_C。只有当目的IP不在172.16.100.0/24范围内、也不在172.16.0.0/16范围内时才会落入默认路由0.0.0.0/0走Gateway_A转发。5.2 为什么最长前缀匹配如此重要理解这个机制就对很多网络故障有了判断依据。比如你在内网访问某个业务流量突然“绕远”了先检查一下是不是某条更具体的路由被注入或删除了导致流量落到了默认路由。流量行为的改变多数不是随机发生的而是前缀匹配结果变了。另一个常见场景是黑洞路由。运维有时候会用一条指向Null0的汇总路由做“兜底”比如把10.0.0.0/8指向黑洞再通过几条更精确的路由指向特定出口。如果有一条更具体的/24指向正常网关流量就正常转发万一这条精确路由被撤销了流量就会坠入黑洞表现就是网络“通但不通”——路由上了但业务全部超时。注意LPM是硬件转发芯片的核心逻辑很多故障排查都要回到“路由表中哪条前缀最长”这个基本问题上来。6. CIDR在现代网络中的落地场景VPC、容器与骨干网CIDR不是一个停留在协议文档里的历史名词它深入到了几乎所有现代网络架构的底层设计。我从三类最常见的实战场景说起。6.1 云上VPC网段规划做云上架构设计的同学天天和CIDR打交道。无论AWS的VPC、阿里云的VPC还是腾讯云的私有网络创建网络时第一步就是选择一个CIDR块。比如你选了10.0.0.0/16然后需要在这个大块下划分多个子网。一个常见的生产环境规划如下公网负载均衡子网10.0.1.0/24应用服务器子网内网10.0.10.0/22数据库子网10.0.20.0/24Redis缓存子网10.0.21.0/24运维跳板机子网10.0.100.0/28这里的每一个子网都是一个CIDR块。之所以在设计阶段就要把前缀长度定清楚是因为云上子网一旦创建修改CIDR非常困难牵一发动全身通常只能重建。我见过不少团队早期图省事整片VPC全用/24结果业务一扩容IP不够只能拆VPC、做对等连接或者搞二次规划代价很大。规划时有一个经验可以分享给每个子网预留50%以上的地址余量。比如当前只有20台ECS建议至少分配/24而不是/26因为云上资源扩张的速度往往超出预期而改子网CIDR的代价远高于一开始多给几个IP的成本。6.2 容器网络与Pod网段划分Kubernetes集群的Pod网络也大量使用CIDR定义。在Flannel的VXLAN模式或者Calico的BGP模式下每个Node都会分配一个PodCIDR比如192.168.1.0/24。这个字段直接决定了该节点上最多能调度多少个Pod。如果把节点上的PodCIDR配得过小比如/28那么这个节点最多只能创建14个Pod再多就调度失败。所以集群规划时要根据单节点最大Pod数和节点数反推整个集群的网段大小。比如单节点计划最多跑100个Pod那么PodCIDR至少是/25126个可用地址如果集群有10个节点那么整个Pod网段至少是10个/25的累加选择/212048个地址通常比较稳妥还能留下余量。容器网络还有一个常见问题Pod网段和VPC网段冲突。如果你在云上建集群VPC已经用了172.16.0.0/16而容器网络又配上172.16.0.0/16那么集群内访问VPC内其他资源就会出现地址冲突轻则路由错乱重则直接不可达。规划时必须让Pod网段、Service网段、VPC网段三段互不重叠。6.3 骨干网与BGP路由聚合在ISP骨干网和企业出口路由器上CIDR的聚合能力被发挥到了极致。骨干路由器之间通过BGP协议交换可达性信息。如果没有CIDR全球路由表的条目数量会爆炸到几十万甚至上百万条骨干设备根本扛不住。BGP的宣告技巧就建立在CIDR语义上。当你从运营商拿到一段IP比如203.0.113.0/24你可以在自己的AS内把它细分为更小的前缀用于内部业务但对外只宣告一条203.0.113.0/24。这样既保证了业务地址的灵活性又不给互联网路由表添负担。不过这里有个关键点对外宣告的路由前缀必须与IP地址的分配记录一致。如果你启用了路由过滤上游运营商会校验你宣告的前缀是否与地址注册数据库匹配。如果宣告了未分配给你的地址块会被上游过滤甚至影响你整个AS的连通性。7. CIDR实操中的典型踩坑与可复用的排查方法我在实际运维和网络方案评审里见过不少跟CIDR相关的低级问题。这些问题单独看都不复杂但混在一起就很容易让人排查得焦头烂额。我把典型的几类问题和对应的排查思路整理一下。7.1 IP与掩码不匹配导致的上网异常这是最常见的一类故障。服务器配置了静态IP子网掩码少写了一位或者多写了一位表现是本机配置无误看起来网络也通了但去ping网关以外的地址时通时不通或者干脆不通。有一次排查一个办公网段的打印机问题打印机IP是192.168.10.50掩码应该是255.255.255.0但设备配置里写成了255.255.255.128。结果打印机认为自己的广播域只有192.168.10.0到192.168.10.127网关虽然还能访问但与192.168.10.128网段之外的设备通信时打印机用ARP去询问目标目标设备却在另一个广播域响应不了于是表现为时通时不通。排查这类问题时第一件事就是在终端上查看IP、掩码、网关三者的关系并把IP和掩码转换成CIDR表示快速判断设备所在的子网边界再对比网关是否真的在同一个子网内。7.2 路由聚合后出现的黑洞路由路由聚合能把多条路由合成一条但如果聚合后的前缀覆盖了并不存在的网段就可能产生黑洞路由。举个例子你有172.16.1.0/24和172.16.2.0/24于是聚合宣告了一条172.16.0.0/22。这条聚合路由覆盖了172.16.0.0/24和172.16.3.0/24如果这两个地址段被某些设备使用或者有内部需求访问这些段的地址但在内网里根本没有对应的路由指向这些流量就会被丢弃形成黑洞。所以做聚合时一个基本检查点是确认聚合前后覆盖的地址范围明确哪些段是被“顺带”包含进来的并确认这些段没有真实业务或路由需求。如果不确定宁可不聚合多宣告几条长度稍长的前缀。7.3 云上安全组规则里的CIDR误配云上安全组规则经常要用CIDR来限制来源或目的IP误配CIDR也是常见问题。比如要放行某个办公室的出口IP 203.0.113.45有人图省事直接写了203.0.113.0/24结果整个网段的流量都能访问业务端口等于把策略放开了256倍。更隐蔽的错误是把CIDR的起始地址写错。比如想要限制203.0.113.128到203.0.113.191这一段正确的CIDR是203.0.113.128/26但写成203.0.113.129/26就是非法网络地址有些平台会直接拒绝保存但也有一些平台会静默修正成203.0.113.128/26造成“你以为限制了实际限制的范围和你想的不一样”的偏差。配置完之后就用IP归属计算工具复核一遍是个好习惯。7.4 一个快速的CIDR自查思路分享一个我每次做完网络规划后都会执行的检查清单明确每个CIDR块的起始地址是否对齐块大小比如/26块的起始地址必须能被64整除。计算每个块的可用IP数减去网络地址和广播地址后是否满足实际需求。检查所有子网之间是否重叠重叠是路由混乱的万恶之源。检查聚合后的前缀是否覆盖了不需要覆盖的地址段。在配置设备或云平台前先用工具或心算验证一遍网络地址和广播地址。7.5 线上勘察案例一个/23的误判有一次同事反馈新部署的K8s节点无法访问某个内部服务我登上去一看Node的PodCIDR被配置成了10.244.0.0/23但网络插件里默认的ClusterCIDR是10.244.0.0/16。按说/23在/16范围内不应该有问题。但实际问题是该节点被分配了10.244.0.128/25作为实际Pod网段然而calico的IP池配置的却是10.244.1.0/24两者在地址空间上部分重叠。K8s调度器按Node的PodCIDR分配Pod IPCNI插件又从IP池分配IP两边各自为政导致Pod IP与相邻节点的地址冲突路由一会走这个节点一会走那个节点流量时通时断。定位方式不复杂但需要有清晰的CIDR概念才能想到先看Pod实际获取到的IP再结合traceroute和路由表逐跳核验最后发现是PodCIDR与IP池范围不一致。问题的根子还是在于地址规划阶段没有把各层网段的CIDR关系表列清楚。因此在集群初始化前把ClusterCIDR、Node PodCIDR、ServiceCIDR、IP池范围统一对齐画出一张不重叠的CIDR分配表应该作为交付前的强制检查项。8. 我对CIDR学习路线的一点建议CIDR看起来就是几个数字的排列组合但真正理解并灵活运用需要反复练习。我建议有条件的同学不要只看文档而是用虚拟机搭建一个mini网络环境亲自动手做一次子网划分、配置几台设备的静态路由和聚合路由再通过traceroute和抓包验证转发路径这样CIDR就不再是纸上谈兵的知识点而是一种肌肉记忆。踩过几次坑之后我个人最大的体会是CIDR相关的故障都不是“难”而是“隐蔽”它不会直接报错告诉你掩码算错了只会表现为一种间歇性的、范围不精确的网络异常。下次再遇到“通但不通”“时通时不通”的问题可以先把所有相关设备的IP、掩码、路由表抄到一张纸上手动算一遍网段归属再考虑抓包和更复杂的排障手段。很多时候问题就藏在那一位子网掩码里。