网际协议里真正容易卡住人的，往往不是地址格式，而是转发和编址这两件事怎么咬合在一起。我见过不少人能把子网掩码算得飞快，却在"目的地址和网关不在同一网段"这种问题面前愣半天；也有人能背出最长前缀匹配的定义，但让他解释为什么一条更具体的路由会抢走本该走默认路由的流量，就说不太清楚了。编址决定地址空间怎么切分、谁属于谁、一个地址块里哪些能用哪些不能用；转发决定一个已经到达路由器的包下一步该从哪个口出去、交给谁。把这两件事分开看，再合起来看，很多模糊的地方会突然变得清楚。

这篇按我自己的理解顺序来：先把IP层的职责边界划清楚，再拆地址结构为什么长成这样，然后讲转发表到底怎么被查，最后落到子网规划的手算过程和几条能直接敲的命令上。中间会穿插一些实际踩过的坑，尤其是那些文档里不太写、但一上手就撞上的细节。

1. 把转发和路由分开，IP层的职责边界才清楚

1.1 无连接、尽力而为：IP层承诺了什么，又拒绝承诺什么

IP协议在设计上做了一个非常克制的选择：它只负责把数据报从源主机送到目的主机，而且只承诺"尽力"。不保证送达，不保证按序，不保证不重复，也不保证时延。这个选择在当时看是妥协，放到今天看反而是它活下来的原因——网络层不背负可靠性，可靠性被推到端系统用传输层去解决，中间设备就可以做得足够简单、足够快。

这个"简单"体现在哪？路由器收到一个包，看目的地址、查表、转发出去，它不关心这个包属于哪个连接，不保存任何按连接维度的状态。这也是为什么IP层被叫做无连接：每个数据报都是独立处理的，前后两个包可能走完全不同的路径，后发的先到是常态而不是异常。

理解这一点很关键，因为它直接决定了很多现象的合理性。比如你抓包看到同一连接的两个包到达顺序反了，那不是"网络出错"，而是设计使然；再比如路由器内存吃紧时丢包，也不会通知源端"我丢了"，只能靠上层超时重传。我在排查时见过有人把这类现象当成链路故障去查，折腾半天才发现是自己对IP层语义的预期错了。

1.2 控制平面写表，数据平面查表

"路由"和"转发"这两个词在日常交流里经常被混用，但在实现层面它们是两件完全不同的事。路由是控制平面的活：运行路由协议、收集拓扑信息、计算路径，最终产出一张路由信息库。转发是数据平面的活：每个到达的包都要在极短时间内完成一次查表动作，决定出接口和下一跳。

控制平面的更新频率是秒级甚至分钟级，数据平面的查表频率是线速级别——一个万兆口满负荷时每秒要处理上千万个包。这两个数量级差了六七个数量级，所以实际设备里一定是分开实现的：控制平面算好的结果被"编译"成一张转发表下发给硬件，硬件只管查，不管算。转发表里的条目通常比路由信息库精简，因为硬件表项是稀缺资源。

我在调一个转发异常的问题时，最有用的一个习惯就是先确认"路由表里有"和"转发表里有"是不是同一件事。有些平台上两者会短暂不一致，配置刚下发时路由表已经能看到，但硬件表还没刷新完，这时候抓包看到的现象就是"路由明明配了，包却没出去"。等几秒再测，或者主动触发一次表项同步，问题就消失了。这类问题不看实现分层是想不明白的。

1.3 一个包从主机到主机的完整决策链

把决策链从头走一遍，转发和编址的关系就浮出来了。

应用层把数据交给传输层，加上端口号；网络层封装IP头，填上源地址和目的地址，TTL设一个初始值（常见64或128）；然后主机拿目的地址和自己配置的掩码做一次与运算，判断目的主机是否在同一网段。如果在同一网段，直接对目的地址做地址解析，拿到下一跳的链路层地址；如果不在同一网段，就对网关地址做地址解析，把包交给网关。

包进入第一台路由器，路由器查转发表，找到出接口和下一跳，把TTL减一，重新封装链路层帧头（源和目的链路层地址都换成本跳的），转发出去。这个过程逐跳重复，直到最后一台路由器发现目的网段直连，直接投递。

这里有个特别值得记住的对照：IP地址端到端不变，链路层地址逐跳改变。源IP和目的IP在整个旅程中基本不动（地址转换是例外，属于另一层机制），但每一跳的帧头都是新的。很多人对转发的困惑就来自把这两层地址的角色搞混了，以为路由器是"照着目的MAC转发"的。恰恰相反，路由器看的是目的IP，MAC只是把包送到下一跳的手段。

2. IP地址的层次：编址设计的取舍

2.1 32位地址怎么拆成网络号与主机号

IPv4地址是32位，写成点分十进制只是为了人看着舒服，本质是一个从0到4294967295的整数。这个整数被切成两段：前一段标识网络，后一段标识该网络内的主机。切在哪，就是编址的核心问题。

为什么要切？因为路由表不能存全世界每一台主机的地址。如果地址是扁平的，全球几十亿个可达地址就要几十亿条表项，任何设备都扛不住。加上层次之后，路由器只需要知道"某个网段在哪个方向"，一个表项覆盖一大片地址，表项数量就降到了可控范围。这是编址设计最根本的动机，也是为什么子网划分、路由聚合这些概念存在——它们都是在维护这个层次结构。

早期的做法是分类编址，靠地址的前几位固定判断类别。A类第一位是0，网络号8位；B类前两位是10，网络号16位；C类前三位是110，网络号24位；D类前四位1110用于组播；E类前四位1111保留。这个方案的好处是不需要额外信息就能判断网络号长度，坏处是粒度太粗。

2.2 分类编址为什么撑不下去

分类编址的问题不是"技术上错了"，而是"和真实需求对不上"。一个中等规模的组织需要几百到几千个地址，A类给它一千六百万个，浪费到离谱；C类只给254个，又不够用；只有B类勉强合适，结果所有人都去申请B类，B类地址空间很快见底。

更麻烦的是路由表膨胀。分类编址下，一个组织即使只用了一个B类地址段里的一小部分，对外也得宣告整个B类，路由器没法把相邻的多个C类合并成一条，因为类别边界是死的。地址空间消耗和路由表规模两个问题同时恶化，这套方案就走到头了。

我第一次认真理解这段历史，是在算一个老网络的地址规划时发现的：那个网络里到处是"半个B类用了几十个地址"的情况，剩下的地址既不能给别人用，也没法聚合，白白占着。分类编址的遗产在今天的很多内网里还能看到痕迹，比如习惯性地按A、B、C的边界去切地址段。

2.3 子网掩码与CIDR：把前缀长度变成一等公民

子网掩码解决的是"在类别内部再切一刀"的问题。它是一个32位数，网络位全1、主机位全0，和地址做与运算就得到网络地址。比如掩码255.255.255.0，前三段是网络，最后一段是主机。这样即使拿到一个B类地址，也可以按需切成多个/24的子网，内部路由就精细多了。

CIDR（无类域间路由）把这件事推到极致：前缀长度可以是0到32之间的任意值，不再受类别约束，写法就是"地址/长度"。192.168.16.0/20表示前20位是网络位，剩下12位是主机位，能容纳4094个可用地址。这个表示法同时解决了编址和聚合两个问题——因为前缀长度自由，相邻的地址块只要前缀能对齐，就可以合并成一条更短前缀的路由。

举个具体的聚合例子。四条路由分别是192.168.0.0/24、192.168.1.0/24、192.168.2.0/24、192.168.3.0/24。看第三段的二进制：0是00000000，1是00000001，2是00000010，3是00000011，只有最低两位在变，高六位完全一致。所以这四块可以合成192.168.0.0/22，一条表项覆盖四条。判断能不能聚合的方法就是这个：把候选地址块写成二进制，看从第几位开始出现分歧，共同前缀就是聚合后的长度。

提示：聚合的前提是地址块连续且按边界对齐。192.168.0.0/24和192.168.2.0/24中间夹着1.0/24，这两条就不能直接合成/22，硬合会把不属于自己的地址也宣告出去，属于典型的配置事故。

3. 转发平面的核心动作：最长前缀匹配

3.1 转发表里到底有什么

一条转发表项最少包含三样东西：目的前缀、下一跳、出接口。目的前缀用"地址/长度"表示，下一跳是邻接设备的地址（直连路由可以为空），出接口是本机哪个口发出去。有些实现还会带度量值、优先级、标签等信息，但查表的核心逻辑只依赖前缀。

表里通常有几类条目并存：直连路由（本机接口配置地址后自动产生，前缀就是接口网段）、静态路由（手工配置）、动态路由（协议学来的）、默认路由（0.0.0.0/0，前缀长度0，能匹配任何地址）。默认路由的存在是为了兜底：当一个目的地址在表里找不到更具体的匹配时，就按默认路由走。

这里有个容易忽略的点：默认路由不是"特殊规则"，它只是一条前缀长度为0的普通表项。理解这一点，后面讲匹配顺序时就顺了。

3.2 最长前缀匹配的逐步演算

规则只有一条：在所有能匹配目的地址的表项里，选前缀最长的那条。前缀越长，覆盖范围越窄，描述越精确。

假设某台路由器的转发表是这样的：

现在来一个目的地址10.1.2.200。逐条看：/0匹配（任何地址都匹配）、/8匹配、/16匹配、/24匹配（前24位一致）、/25也匹配（10.1.2.128/25覆盖128到255，200在里面）。五条都命中，选最长的/25，从eth4直连发出。

换成10.1.3.5：/0匹配、/8匹配、/16匹配（10.1开头），/24不匹配（第三段是3不是2），/25也不匹配。选/16，走eth2。

再换203.0.113.7：只有/0匹配，走默认路由eth0。

这个演算过程看起来简单，但它是所有转发异常的第一怀疑对象。我遇到过好几次"路由配了但流量还是走老路"的情况，最后查出来都是表里存在一条更长前缀的旧路由，把流量截走了。排查时先用查表命令看实际命中的是哪条，比猜快得多。

3.3 默认路由、主机路由与等价多路径

默认路由的实战价值在于收敛表规模。一个末梢网络只要一条默认路由指向出口，内部所有未知目的地址都往出口送，不需要知道全网明细。这就是所谓"边缘默认、核心明细"的常见布局。

主机路由是另一个极端：/32前缀，只匹配单个地址。它的典型用途是给某台关键设备单独指定路径，或者在做流量牵引时把某个地址的流量强行导到特定设备上。主机路由因为前缀最长，永远优先于任何网段路由，所以用起来很有力，也很容易变成"埋雷"——配置的人走了，后来的人死活想不通为什么这台机器不走正常路径。

等价多路径（ECMP）出现在有多条同前缀、同优先级路由的情况下。设备会把这些下一跳都保留下来，按流做哈希分流，让不同连接走不同路径，既提升带宽又保留冗余。这里要注意的是哈希的粒度：多数实现按五元组哈希，同一条连接的所有包走同一路径，避免乱序；但如果你做了地址转换，哈希输入变了，分流结果也会变。这一点在做链路扩容后验证流量分布时特别值得留意。

硬件实现上，高速转发设备通常用三态内容寻址存储器来做查表。它的特点是所有表项并行比较，一次就能得出最长匹配结果，代价是容量有限、功耗高。所以真实设备会把最常用的前缀放进硬件表，长尾的放到软件路径处理，这也是为什么有些目的地址的转发时延会明显高于其他地址。

4. 子网划分实战：从需求到地址块

4.1 VLSM规划：一个大块怎么切

变长子网掩码的核心思想是：不同大小的网段用不同的前缀长度，按需分配，减少浪费。规划顺序应该是从大到小，先满足大块，再用剩下的空隙填小块。

拿一个具体需求走一遍。手上有一个10.10.0.0/16，需要满足：总部500台主机、分部200台、两个小部门各50台、四条点对点互联链路。

第一步算每个网段需要的主机位。可用地址数是2的h次方减2（去掉网络地址和广播地址）。500台需要2^9=512，减2得510，够用，所以主机位9位，前缀长度32-9=23。分部200台需要2^8=256减2得254，主机位8位，前缀/24。50台需要2^6=64减2得62，主机位6位，前缀/26。点对点链路只需要2个地址，理论上2^2=4减2得2，前缀/30正合适。

第二步按顺序分配：

这里有个细节值得说：/23的网段跨越了10.10.0.x和10.10.1.x两段，网络地址是10.10.0.0，广播地址是10.10.1.255。很多人算到这儿会下意识把广播地址写成10.10.0.255，这是把/23当成两个/24了。判断方法很简单：主机位是9位，全1就是广播地址，第三段和第四段一起看，10.10.1.255的二进制后9位全是1，没错。

4.2 聚合：让路由表瘦下来

规划完之后，如果这些网段都要对外宣告，八条路由有点多。看看能不能聚合。前四块10.10.0.0/23、10.10.2.0/24、10.10.3.0/26、10.10.3.64/26合起来覆盖了10.10.0.0到10.10.3.127，能不能压成一条？

把第三段写二进制：0是00000000，1是00000001，2是00000010，3是00000011。共同前缀到前30位（即第三段的高6位），也就是说10.10.0.0/23和10.10.2.0/24合起来是10.10.0.0/22，但10.10.3.x只覆盖了0到127，128到255还在用（四条/30链路），所以不能整体合成/22，否则会把链路段也包括进去。

如果链路段的地址规划时挪到别的地方，比如放到10.10.4.0/24里，那么前四块就能干净地合成10.10.0.0/22。这就是规划时"预留空隙"的价值：地址分配不只看当下够不够用，还要考虑未来能不能聚合。我现在的习惯是给每类用途划一个连续的地址池，池内再细分，池与池之间留出对齐的边界，后期聚合会舒服很多。

反面的教训也见过：有的网络地址分配是"谁先申请谁先拿"，东一块西一块，最后出口路由器上挂了上百条明细路由，每次扩容都要手工加，还容易漏。这种局面下想做聚合就得重新规划地址，代价非常大。

4.3 特殊地址清单与易错点

编址里有几个地址段有固定含义，配置时踩错会出很隐蔽的问题：

几个高频错误。第一个是172.16.0.0/12的范围，很多人记成172.16.0.0/16，结果把172.17.x.x当成公网地址配出去了。第二个是环回段，以为只有127.0.0.1是环回，实际上127开头的整个/8都是，随便配一个127.1.1.1也能通，这在测试时很方便。第三个是每个子网的网络地址和广播地址不能用，/24网段实际可用254个而不是256个，规划时如果按256算，最后两台机器会配不上地址。

还有一个偏门的点：点对点链路上用/31可以省地址，两个地址都可用，没有网络地址和广播地址的概念。这个做法在标准里有明确定义，主流设备都支持。四条链路用/31的话只需要8个地址，比/30省一半。不过老设备可能不认，上线前要确认。

5. 编址与转发在真实环境里的交互

5.1 网关地址必须和主机同网段，这不是建议是硬约束

主机判断"目的地址在不在本网段"用的完全是自己的掩码。如果判断为不在，它就去解析网关的链路层地址，把包交给网关；如果判断为在，它直接解析目的地址，根本不看网关。

这就意味着：网关地址必须落在主机自己的网段内，否则主机的地址解析请求发出去没人应答，包根本出不了网卡。这个约束在配置界面里通常不校验，你填一个明显不在同网段的网关，系统照样保存，然后就是上不了网，而且现象很迷惑——网关本身可能是通的，因为从别的机器 ping 它能通。

我遇到过一个典型案例：某台服务器的地址是10.20.30.40/24，网关填了10.20.31.1。从别的网段 ping 这台服务器能通（因为路由是对的），但从这台服务器往外 ping 全失败。查了半天路由表都对，最后发现是网关不在同网段，地址解析根本发不出去。改成10.20.30.1立刻就好。

反向的问题也存在：掩码配错导致"同网段判断"出现分歧。两台机器地址看着在同一个/24里，但其中一台掩码写成了/25，那么它对另一半地址的判断就是"不同网段"，会去找网关；而另一台认为同网段，直接发地址解析。结果就是这两台机器互相 ping 不通，但各自 ping 网关都正常。这种故障特别难查，因为表面上看两台机器"明明在一个网段"。

5.2 地址转换改变了什么，没改变什么

私有地址在出口做地址转换是极常见的做法，它的作用是让内网地址复用、减少公网地址消耗。从转发角度看，转换设备在转发路径上多做了一步：把源地址换成出口地址，同时记录映射关系，回程包再按映射换回来。

这件事对编址的影响是：内网地址的规划可以完全独立于公网，只要保证内部不冲突就行。这也是为什么私有地址段可以反复出现在不同组织内部，互不影响。

对转发的影响更值得注意：转换设备必须看到双向流量才能维护映射，所以它天然是个有状态的中间点。一旦映射表项超时被清掉，回程包就找不到对应关系，表现为连接"卡住"然后慢慢恢复。排查这类问题时，看转换设备的会话表比看路由表有用得多。另外，转换会改写地址，某些把地址信息嵌在载荷里的协议就需要额外处理，这也是这类协议在转换环境里容易出问题的原因。

5.3 同一台设备上多个地址段时的转发细节

一台路由器接口上配了主地址和从地址的情况很常见，尤其是做地址迁移的过渡期。这时候要注意：从地址所在的网段也算直连路由，会进转发表。如果从地址的网段和别处冲突，转发就会乱。

迁移时的稳妥做法是先把新网段配成从地址，验证连通性，再把主机逐批切过去，最后把主地址换成新网段、删掉旧的。整个过程两台网段的直连路由同时存在，互不干扰。但如果中途有人在新网段上又配了静态路由指向别处，直连路由和静态路由会打架——直连路由的优先级通常更高，静态路由配了也不生效，配置的人会以为没生效是设备问题。

这类问题的通用排查思路是：先确认实际命中的路由来源（直连、静态还是动态），再看优先级。不同来源的路由在表里是可以共存的，最终生效的由优先级和前缀长度共同决定，只看前缀长度是不够的。

6. 排查与验证：几条能直接用的命令和思路

6.1 看地址、看路由、看实际命中

Linux 环境下最常用的三条：

# 看接口地址和掩码 ip addr show # 看路由表 ip route show # 看某个目的地址实际会命中哪条路由 ip route get 203.0.113.10

第三条是最有价值的。前两条是"配置了什么"，第三条是"实际会怎么走"，两者不一致的时候问题就藏在那儿。比如你明明配了走A口，结果查出来走B口，那说明表里有更具体的路由把流量截走了，或者有策略路由干预。

Windows 环境下对应的是route print和tracert，前者看表，后者看路径。tracert的价值在于它能告诉你包在哪一跳开始偏离预期。如果前三跳正常、第四跳突然跑到一个不该出现的方向，那基本可以确定是中间某台设备的路由配错了。要注意tracert依赖回程的ICMP消息，有些设备会限速或不回，看到星号不一定代表断了，可能只是不响应。

6.2 分层验证的顺序

排查连通性问题，我习惯从下往上，一层一层确认，不要跳：

1. 链路层：接口是否 up，有没有错误计数增长，对端是否同一广播域。
2. 地址层：本机地址和掩码是否正确，网关是否在同网段内。
3. 地址解析：能否解析到网关的链路层地址，表项是否正常。
4. 路由层：实际命中的路由是否符合预期，下一跳是否可达。
5. 上层：端口是否监听，有没有策略拦截。

这个顺序的理由是：越往下越基础，下层不通的话上层怎么配都没用。跳过下层直接查上层，最常见的结局是花了半小时发现网线没插好。

6.3 常见现象与根因对照

这张表里最值得留意的是最后一行。设备替换是转发类故障的高发场景，因为旧设备上那些"配了但没人记得"的路由不会自动跟着走。我的习惯是替换前把旧设备的完整路由表导出来，和新设备逐条比对，重点看默认路由、静态路由和那些指向具体主机的/32条目，这三类最容易被遗漏。

7. 一点个人经验

编址和转发这两块，单独看都不难，难的是它们交织在一起的时候。我现在做地址规划，会强迫自己多问一句"这块地址以后能不能聚合"，而不是只看"现在够不够分"。多花十分钟把边界对齐，后面能省掉很多次手工加路由的麻烦。

排查方面有个习惯挺管用：先确认"实际命中"，再谈"为什么"。很多人一上来就看配置文件，看完觉得没问题就卡住了。其实配置和实际行为之间还隔着表项下发、优先级比较、最长前缀匹配几道关，直接看实际结果反而更快定位。命令敲下去三秒钟的事，比盯着配置文件推演十分钟靠谱。

最后一个容易忽略的点：文档里写的"可用地址数"永远是理论值，实际还要减掉网关占用的那个、可能的保留地址、以及某些设备会占用第一个可用地址做管理。规划时按理论值卡着上限分，上线时一定会少一个。留点余量，比事后改掩码省事得多。