做实验做到IPv4地址的无分类编址,等于从"会用IP地址"跨到了"能规划网络"这个台阶。我当年第一次接触CIDR(Classless Inter-Domain Routing,无分类域间路由)的时候,最直观的感觉就是:终于不用死记A类、B类、C类的默认掩码了,一个/26、/27、/28就能把地址块切得刚刚好。这个实验主要解决两个问题:一是分类编址带来的地址浪费,二是路由表膨胀。如果你正在学网络基础、准备考试,或者工作中要自己规划网段,都值得把这里面的计算思路彻底吃透。下面按我实际做实验的过程,把原理、计算、实操和踩过的坑一起理一理。
1. 从分类编址到无分类编址:这一套规则到底解决了什么
1.1 分类编址的规则与它的尴尬
先说背景。IPv4地址最初被划分成A、B、C、D、E五类,其中D类是组播,E类保留,平时能分配给主机的就是A、B、C三类。A类第一个字节是1到126,默认掩码255.0.0.0;B类第一个字节是128到191,默认掩码255.255.0.0;C类第一个字节是192到223,默认掩码255.255.255.0。这套规则非常规整,一眼就能看出地址属于哪一类,但实际用起来相当尴尬。
举个例子你就明白了。假设一家公司有300台电脑,申请IP地址时,C类地址一个网段只有254个可用地址,不够;B类地址一个网段有65534个可用地址,又实在用不完。这种场景下,要么硬着头皮申请B类地址浪费大量IP,要么申请多个C类地址段,内部再想办法做路由聚合。更麻烦的是,A类地址一个网段有16777214个可用地址,几乎没有哪个组织能吃下这么大的地址块,可早年一旦分配出去,这个地址段就很难再回收。结果就是B类地址很快告急,A类地址更是稀缺中的稀缺。
除了地址浪费,分类编址还有一个被很多人忽略的痛点:骨干路由器的路由表膨胀。因为地址是按"类"分配的,假设给A公司分了几段C类地址,给B公司又分了几段C类地址,那骨干路由器上每一段都要占一条路由表项。以当年的设备水平,内存和路由查找性能都不行,路由表一大,转发性能就会明显下降。这个问题的本质,是分类编址把地址块的粒度锁死在了字节边界上,灵活性太差。
1.2 CIDR的核心设计思路
后来业界提出来无分类编址,就是CIDR,思路特别简单:放弃固定的A、B、C类边界,改用"前缀长度"来精确描述一个地址块的大小。所谓前缀长度,就是掩码里二进制1的个数。比如192.168.10.0/24,表示前24位是网络位,后8位是主机位;而192.168.10.0/26,表示网络位有26位,主机位只有6位,整个地址块的大小是64个地址。
这个"打破字节边界"的设计带来了两个直接好处。第一个好处是地址分配可以按需取用。以前想分一个254个地址的C类网段,只能整段分;现在可以只分一个/26(64个地址)、/27(32个地址)甚至/30(4个地址),粒度精细到比特,地址浪费被大幅压缩。第二个好处是路由聚合。如果一个用户拿到的是一个连续的地址段,比如从202.100.0.0到202.100.15.255,这实际上就是202.100.0.0/20,可以用一条路由通告出去,而不是拆成16条C类路由分别通告。路由表肉眼可见地瘦身了。
所以说,无分类编址不是发明了一套新地址,而是把IPv4地址的使用方式从"按类粗放分配"改成了"按位精确规划"。这也是为什么后来做IP规划、写路由配置、做访问控制列表时,几乎都离不开CIDR记法。这个实验的核心,就是把这种按位规划的思路,从理论落到实际操作上。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 无分类编址的核心概念与计算方法
2.1 前缀长度、子网掩码和CIDR记法的对应关系
无分类编址里边最基础的内容,就是把前缀长度和子网掩码对应起来。我之前带过不少新人,经常有人把/22对应的掩码算错。这里给你一个很稳的算法:先把前缀长度除以8,算出哪些字节是全1,再处理剩下的部分。
比如/20,20除以8商2余4,前两个字节是255.255,第三个字节二进制是11110000,也就是240,所以/20 = 255.255.240.0。同理,/26,26除以8商3余2,前三个字节是255.255.255,第四个字节二进制是11000000,也就是192,所以/26 = 255.255.255.192。下面这张表可以存一下,实际做实验时经常要到:
| 前缀长度 | 子网掩码 | 地址块大小 | 可用主机数 |
|---|---|---|---|
| /24 | 255.255.255.0 | 256 | 254 |
| /25 | 255.255.255.128 | 128 | 126 |
| /26 | 255.255.255.192 | 64 | 62 |
| /27 | 255.255.255.224 | 32 | 30 |
| /28 | 255.255.255.240 | 16 | 14 |
| /29 | 255.255.255.248 | 8 | 6 |
| /30 | 255.255.255.252 | 4 | 2 |
| /31 | 255.255.255.254 | 2 | 0(点对点链路用) |
| /32 | 255.255.255.255 | 1 | 0(单个主机用) |
这里有个小细节:地址块大小,也就是子网里的总地址数,等于2^(32-前缀长度)。块大小减2就是可用主机数,因为网络地址和广播地址不能分配给主机。比如/28的块大小是2^4=16,可用主机数是14。这块如果掐不准,后面做VLSM划分一定翻车。
2.2 网络地址、广播地址和可用范围的计算步骤
我在实验里习惯按三个步骤算一个子网的所有关键信息。第一步,把IP地址和掩码都转成二进制,然后做按位与运算,得到网络地址。第二步,把主机位全部置1,得到广播地址。第三步,中间的范围就是可用主机地址。
举一个例子,地址是192.168.10.77/26。先把192.168.10.77写成十进制点分形式,最后一段77的二进制是01001101。掩码/26表示最后一段前两位是网络位,后六位是主机位。网络位是前两位,也就是01,主机位全置0后,最后一段变成01000000,十进制是64,所以网络地址是192.168.10.64。主机位全置1,最后一段变成01111111,十进制是127,广播地址是192.168.10.127。可用主机地址就是65到126,一共62个。
这里最容易搞混的地方是,很多人在算到广播地址时想当然地觉得"子网是64到127,那广播地址应该是127,怎么看着有点像本来就该是". 其实你把二进制展开就一目了然:64到127这个块,首位固定是01,中间六位从000000变到111111,边界非常清晰。我建议第一次做实验时别偷懒,把每个子网的网络位在二进制下多写几遍,比单纯背十进制结果可靠得多。
2.3 为什么可用主机地址要减2
凡是学过网络基础的人都知道一个公式:可用主机数 = 2^n - 2,n是主机位数。减2的原因是网络地址和广播地址不能分配给主机。网络地址是主机位全0的地址,用于标识整个子网;广播地址是主机位全1的地址,用于向子网内所有主机发送数据。这两个地址在协议栈里都有特殊意义,如果分配给某台主机使用,就可能导致通信混乱。
不过这里我要补一句,实际工程里也有一些特殊情况。比如/31子网只有2个地址,按公式算可用主机数是0,但它被广泛应用于路由器之间的点对点链路。原因是RFC 3021中规定,点对点链路的两端只有一个对端,不需要广播地址,所以/31的2个地址可以全部用于接口。再比如/32通常用于标识单个主机,在ACL规则、Loopback接口里很常见,它同样不遵循减2的常规逻辑。实验里你按减2来处理,考试和大多数场景都是对的;但心里要清楚,这不是一条铁律,而是一种普遍约定。
3. 实验实操:用VLSM给一家模拟公司做地址规划
3.1 需求分析与划分思路
这次实验我搭了一个模拟场景:一家公司申请到了192.168.10.0/24这个地址段,内部有四个部门需要分配IP。技术部要求可用地址50个,市场部要求20个,财务部要求12个,人事部要求6个。所有部门在同一个园区网内,要求彼此网段不冲突,还要留出尽可能多的空闲地址供以后扩展。
拿到这种需求,第一反应不是直接算,而是先排序。划分子网时有一条核心原则:从大到小分。为什么?因为每个子网的大小必须是2的幂次,而且起始地址要跟它的大小对齐。如果你先分了一个很小的子网,比如/29,占用了8个地址,它可能把后面一个/26大块的对齐边界给切碎了,导致明明还有空间,却凑不出连续的大块给技术部。从最大的需求开始分,可以让每个子网都落在正确的边界上,碎片最少。
按这个原则,我们要分的第一个子网是技术部的50个地址。50个可用地址意味着主机位n要满足2^n - 2 ≥ 50,最小的n是6,因为2^6 - 2 = 62。也就是说技术部需要/26,地址块大小64。接下来市场部20个,2^5 - 2 = 30,需要/27,块大小32。财务部12个,2^4 - 2 = 14,需要/28,块大小16。人事部6个,2^3 - 2 = 6,刚好满足,需要/29,块大小8。
3.2 逐个子网的完整计算过程
技术部用/26,从192.168.10.0开始,块大小是64,所以它的范围是192.168.10.0到192.168.10.63。网络地址192.168.10.0,广播地址192.168.10.63,可用地址192.168.10.1到192.168.10.62。这里要特别留意,广播地址不是192.168.10.64,很多新手在这一步会犯轴,觉得0到63一共64个地址,那64应该是下一个子网的开始而不是广播地址。
接下来市场部从192.168.10.64开始,/27块大小32,范围是192.168.10.64到192.168.10.95。网络地址64,广播地址95,可用地址65到94。财务部从192.168.10.96开始,/28块大小16,范围是96到111。人事部从192.168.10.112开始,/29块大小8,范围是112到119。最后剩下的120到255一共136个地址,保持空闲,以后新增部门时可以直接用。
完整的结果我整理成了表格,实验时建议照着这个格式记录:
| 部门 | 需求地址数 | 分配前缀 | 网络地址 | 可用地址范围 | 广播地址 |
|---|---|---|---|---|---|
| 技术部 | 50 | /26 | 192.168.10.0 | 192.168.10.1 - 192.168.10.62 | 192.168.10.63 |
| 市场部 | 20 | /27 | 192.168.10.64 | 192.168.10.65 - 192.168.10.94 | 192.168.10.95 |
| 财务部 | 12 | /28 | 192.168.10.96 | 192.168.10.97 - 192.168.10.110 | 192.168.10.111 |
| 人事部 | 6 | /29 | 192.168.10.112 | 192.168.10.113 - 192.168.10.118 | 192.168.10.119 |
做完这个划分之后,整个192.168.10.0/24网段里,已经被使用的地址是0到119,总共120个地址,还剩136个空闲,利用率控制得比较合理。如果按传统分类编址的思路,要么给每个部门都分一个/24,四个部门直接吃掉4个C类地址段,浪费天量;要么共用一个大网段然后手工乱切,根本说不清边界。VLSM的价值在这个对比里体现得很明显。
3.3 验证计算结果并配置到设备上
纸上算完,实验还没结束,一定要上设备验证一遍。我用的是GNS3里的路由器模拟环境,也可以用思科模拟器或者手头真实的交换机路由器。验证最简单的方式是给设备的Loopback接口配上这些地址,然后互相ping,同时查看路由表。
比如我在路由器上执行了interface loopback0命令,配置ip address加上技术部网段的地址,再把其他网段配到其他接口上,然后用show ip route观察直连路由。每一个子网都会生成一条直连路由,前缀显示为/26、/27、/28、/29,而不是传统的/8、/16、/24。这一步能直观看到无分类编址在路由表里的表现形式。如果你的实验环境里有交换机和多个VLAN,那更建议直接在VLAN接口上配置这些地址,然后观察不同VLAN之间的三层通信是否正常。
这里我要说一个比较容易忽略的点:配置完地址后,验证两台不同网段主机能否通信时,一定要确认网关地址。网关通常是子网里第一个可用地址,比如技术部的网关是192.168.10.1,市场部的网关是192.168.10.65。如果你把网关配置成了广播地址,比如192.168.10.63,那么数据帧根本不会被转发,反而可能出现在本地广播的行为,排查起来非常隐蔽。我见过不止一个人在这个地方卡半天。
4. 常见问题与排查技巧实录
4.1 子网边界计算错误的排查方法
做无分类编址实验,最典型的翻车点就是计算子网边界。尤其是/27、/28这种块大小不是整字节的子网,出错率非常高。最常见的问题是,把192.168.10.96/28误认为可用地址范围是96到127,其实/28的块大小是16,96加16得到112,所以112是下一个子网的起始地址,这个子网真正的范围是96到111。
我自己的排查方法很简单:先算出块大小,再用"起始地址加上块大小减1"来验证结束地址。比如/28的块大小是16,起始地址是96,结束地址应该是96+16-1=111,这样就不容易出错。做实验时建议把每个子网的起始地址和结束地址都写成二进制对比一遍,特别是在掩码跨字节时,比如/18、/22这种前缀长度不是整字节的情况。一旦发现两个子网的地址范围重叠了,基本就是边界少算了一个,或者起始地址没对齐。
一个额外的技巧:算块大小时,可以直接用256减去掩码的十进制最后一段。比如/28的掩码是255.255.255.240,块大小就是256-240=16;/26的掩码是255.255.255.192,块大小就是256-192=64。这个公式对IPv4子网划分非常通用,比一个个列二进制快得多。但注意它只适用于IPv4,IPv6的子网划分逻辑完全不同,别混用。
4.2 网络连接详细信息里出现两个IPv4地址是怎么回事
有同学做实验时打开Windows的"网络连接详细信息",发现一个网卡上同时显示两个IPv4地址,当场就懵了,以为是子网划分把系统搞乱了。其实这个现象很常见,不一定是配置错误。一个物理网卡上同时启用DHCP和手动备用配置时,Windows会同时显示DHCP分配的地址和备用地址;另外,装了虚拟化软件后,比如VMware Workstation,它创建的VMnet1、VMnet8虚拟网卡默认也带自己的IPv4地址,在"详细信息"里看起来就像有两个地址。
排查思路是先用ipconfig /all看所有适配器,确认两个IPv4地址是不是真的在同一块物理网卡上。如果其中一个地址属于虚拟网卡,那是正常现象,不影响物理网络通信。如果地址确实在同一块物理网卡上,而且你并没有配置备用地址,那就要检查是不是装了某些代理类软件或者虚拟网卡驱动。最简单的处理方式是在"网络连接"里禁用不用的虚拟网卡,再刷新一下IP信息。
这里我要提醒一点:做纯实验时,尽量把无关网卡禁用掉,尤其是虚拟机网卡。因为多网卡环境下,Windows的路由选择可能出现"明明能ping通网关,但跨网段访问却超时"的诡异现象,原因就是系统把数据包错误地丢给了虚拟网卡,而虚拟网卡根本没有到达目标网段的路由。禁用多余网卡能让实验环境干净很多,排查问题也省心。
4.3 IPv4和IPv6并存时,如何调整优先级
现在的操作系统默认同时启用IPv4和IPv6。如果你在做实验时需要确保某些流量走IPv4,比如在微服务注册中心里看到服务注册的是IPv6地址,或者某些老系统只监听IPv4端口,那就需要调高IPv4的优先级。在Windows 11里,调整方式是进入"网络连接",右键点击当前使用的网卡,选择"属性",双击"Internet协议版本4(TCP/IPv4)",点击"高级",然后在"IP设置"标签页里修改"接口跃点"。
接口跃点(Interface Metric)这个参数,数值越小,网络接口的优先级越高。你可以把IPv4的跃点设成一个较小的值,比如5,把IPv6的跃点设成一个较大的值,比如50,这样系统在选择地址时就会优先使用IPv4。不过要说明的是,这种调整是全局性的,会影响这个网卡上所有流量,所以在生产环境里要谨慎操作。如果你只是希望某个应用走IPv4,更好的方式是配置应用本身,比如在Java应用启动参数里加上-Djava.net.preferIPv4Stack=true。
这个参数我在实际项目里用过很多次,它能强制JVM在IPv4和IPv6双栈环境下优先使用IPv4。尤其是在一些老旧的网络环境下,IPv6网络不稳定或者根本没有IPv6路由,不加上这个参数,应用可能拿到IPv6地址后无法正常通信,表现就是服务能启动,但访问超时。这种问题很难一下子想到根因,因为"启动正常"很容易让人忽视网络栈层面的配置。
4.4 Nacos这类注册中心识别不到IPv4怎么办
做微服务实验时,经常遇到Nacos服务注册后,注册中心显示的服务IP是172.x.x.x或者10.x.x.x这种内网地址,甚至直接是IPv6格式,而客户端通过这个IP调用服务却失败。这个问题的根子通常不在Nacos配置,而在服务器有多块网卡,注册中心自动获取IP时选错了网卡。比如服务器装了Docker,Docker0虚拟网卡的地址是172.17.0.1,如果注册中心优先识别到了这个地址,那其他服务器根本访问不通。
解决办法有几种。最简单的是在服务的配置文件里显式指定注册IP,比如在Spring Cloud Nacos的配置中,通过spring.cloud.nacos.discovery.ip参数,把服务实例要注册的IPv4地址写死,这样注册中心就不会再去自动探测网卡。如果你希望所有Java应用都在双栈环境下优先使用IPv4,可以在JVM启动参数里加上-Djava.net.preferIPv4Stack=true,也能从一定程度上规避识别错误。
这个问题跟无分类编址实验表面上看关系不大,但它暴露了一个网络底层的事实:IPv4地址的规划不是只写在路由器配置里的,它还深刻影响着上层应用的注册发现与调用链路。所以我做实验时,特别强调理解"地址是怎么从网卡里出来的"这件事。一个网卡绑定多个地址、多个网卡同时激活、IPv4/IPv6双栈同时生效,这些真实环境里的复杂性,往往比实验手册里写的要麻烦得多。
4.5 环回地址127.0.0.1和网卡地址要分清
做实验时经常有人用ping 127.0.0.1来判断网络是否正常,这个操作没问题,但结论要拎清楚。ping 127.0.0.1走的是环回接口,数据包根本不会离开本机网卡,它只能证明TCP/IP协议栈本身工作正常,不能证明网线、交换机、路由器这些物理链路是通的。如果你配置完子网地址后,ping 127.0.0.1通了,但ping网关不通,那问题大概率出在地址配置、VLAN划分或者物理连接上,而不是协议栈。
在这个实验里,127.0.0.1还有一个常见的用途,就是配合/32前缀使用。配置Loopback接口时,可以用127.0.0.1/32这样的地址模拟一个只属于本机的逻辑接口。这种接口不会因为物理链路断开而失效,常用于路由器管理、OSPF的Router ID等场景。理解环回地址和物理网卡地址的区别,能帮你少走很多弯路。至少以后你再ping 127.0.0.1时,心里就门清——我到底在测什么。
4.6 路由条目和标准IPv4数据包的关系
无分类编址实验做到最后,我还想提一个容易被忽略的点:不管是/26、/27还是/28的划分,这些前缀信息最终都是被封装在IPv4数据包的路由查找过程中使用的。标准IPv4数据包头部里,目标IP地址是一个32位的字段,路由器收到数据包后,提取目标IP,然后跟路由表里每条路由的掩码做按位与运算,比对网络地址,命中的那条路由就是数据包的转发出口。
正因如此,CIDR并不改变IPv4数据包的封装格式,它只是改变了路由表里的路由表示方式。这也是为什么一个支持CIDR的路由器可以同时存在/8、/16、/24这些不同前缀长度的路由条目,而传统分类路由协议(比如RIPv1)无法携带掩码信息,所以不支持无分类编址;RIPv2、OSPF这些无分类路由协议,则可以在路由更新里携带前缀长度,从而让CIDR真正落地。你如果实验中配置了路由协议,可以对比一下RIPv1和RIPv2的路由表,差异会特别直观。
我个人做这个实验最大的收获,不是背会了子网掩码和前缀长度的换算表,而是真正理解了"按需分配"这四个字。地址规划从来不是一个纯数学题,它既要算清楚2的幂次和可用主机数,也要考虑业务增长、广播域大小、路由聚合和故障隔离。做实验时,我习惯先画一张网络拓扑图,把每个部门的主机数和通信需求写在边上,然后用Excel把每个候选子网的起始地址、结束地址、掩码、可用地址全部列出来,最后再上设备配置验证。这个过程虽然繁琐,但能帮你养成规划前先思考的习惯,比直接对着计算器敲IP地址要靠谱得多。
最后再分享一个小技巧:你在做VLSM实验时,如果划分出来的子网数量多,别急着在设备上配,先把所有子网按照起始地址从小到大排序,然后检查相邻两个子网之间有没有重叠和空隙。我见过很多次,规划表上看着很完美的方案,真到配置时发现某个部门多申请了几个地址,导致后续所有子网边界整体偏移。这时候你才明白,地址规划是一个动态调整的过程,随时要准备用CIDR的按位思想重新切分,而不是抱着第一版方案不放手。多练几次这种"从需求出发、按位分配、边界对齐、动态调整"的思路,无分类编址对你来说就不再是实验手册里那几道计算题了。
