网络实验这东西光看教材上的拓扑图和配置命令很容易产生一种“我全会了”的错觉。真到设备面前敲命令一个掩码算错、一条静态路由下一跳写偏排错能排到怀疑人生。这篇日志接着上一阶段的实验往下走专门聊IPv4编址和IPv4路由基础这两块。它们看着是最基础的内容但恰恰是后面所有动态路由、策略路由乃至整个数据通信体系的底座。基础不牢后面学OSPF、BGP的时候就是空中楼阁。我打算把这次实验的完整过程、踩过的坑、以及那些教材上不会明说但实际配置时一定会遇到的细节原原本本梳理一遍。适合刚接触数通设备、正在啃HCIA-Datacom实验手册的朋友也适合已经能配通但想搞清楚“为什么这么配”的人。1. 为什么编址和路由要放在一起做实验很多人做实验喜欢把编址和路由拆成两个独立任务先给每台设备配好IP验证直连能通然后再单独配路由。这种拆法本身没错但它掩盖了一个关键事实——编址方案的设计直接决定了路由方案的设计。你地址怎么规划、掩码怎么切、网段怎么划分会直接影响后面静态路由写几条、汇总怎么做、下一跳指向哪里。我这次实验特意把两者放在同一个拓扑里做就是想验证这个联动关系。拓扑不复杂三台路由器串成一条链外加两台PC挂在两端中间再拉一条冗余链路。设备用的是常见的数通实验设备接口命名按常规的GigabitEthernet来。整个实验的核心目标有三个第一把IPv4地址规划做扎实包括子网划分和掩码计算第二验证直连网段的通信第三通过静态路由打通非直连网段并理解路由表里每一条表项的来源。先说编址这块的规划思路。给定一个192.168.10.0/24的地址块要分给三段互联链路和两段终端网段一共五个网段。如果偷懒每个网段都用/24地址根本不够分而且互联链路只用两个地址却占掉一整个/24浪费得离谱。所以必须做子网划分。我的切法是先借3位把/24切成8个/27每个/27有32个地址、30个可用主机地址。互联链路各取一个/27终端网段各取一个/27还剩几个留着备用。这个切法不是唯一解但它的好处是每个网段大小一致、掩码统一后面写路由和做汇总的时候脑子不容易乱。提示子网划分没有标准答案但有一个原则——互联链路尽量用最小的可用子网把大块地址留给终端网段。实验环境里这么做的收益不明显但到了真实网络里地址规划的合理性直接关系到后期扩容和路由汇总的效率。这里有个容易被忽略的点掩码的写法在不同场景下不一样。配置接口时用的是点分十进制掩码255.255.255.224写静态路由时可以用掩码也可以用前缀长度/27而路由表里显示的是前缀长度。这三种表示法指的是同一个东西但初学时特别容易在静态路由命令里把掩码写错位。我一开始就在静态路由那条命令上栽了跟头后面会详细说。2. 接口编址实操从掩码计算到配置落地2.1 先把每个网段的地址算清楚再动手动手配置之前我习惯先在纸上或者文本编辑器里把每个网段的网络地址、可用地址范围、广播地址、掩码全部列出来。这一步看着繁琐但能省掉后面大量的排错时间。以/27为例块大小是32所以网段边界是0、32、64、96、128、160、192、224。我取了其中五个网段用途网络地址可用地址范围广播地址掩码互联链路A192.168.10.0.1 - .30.31/27互联链路B192.168.10.32.33 - .62.63/27互联链路C192.168.10.64.65 - .94.95/27终端网段1192.168.10.96.97 - .126.127/27终端网段2192.168.10.128.129 - .158.159/27这张表是整个实验的“地图”。配置接口地址时互联链路两端各取一个可用地址比如链路A的这端用.1、那端用.2。终端网段的路由器接口取.97PC取.98。关键点在于同一网段内所有设备的掩码必须一致。我见过有人路由器接口配/27、PC配/24结果PC能ping通路由器接口但路由器回包时认为PC不在同一网段通信直接断掉。这种问题排查起来非常隐蔽因为接口状态是up的地址看着也“差不多”。2.2 接口配置的命令逻辑与验证顺序配置接口地址的命令本身很简单进接口视图、配地址、开接口三步。但我想强调的是验证顺序。很多人配完地址就直接ping对端ping不通就慌了。正确的做法是分层验证先看接口物理状态和协议状态是否都是up。物理层没起来配什么地址都没用。再看接口的IP地址和掩码是否和规划一致用查看接口简要信息的命令确认。然后看直连网段的路由是否自动生成。接口配了地址且状态up设备会自动生成一条直连路由这是后面所有路由的基础。最后才ping对端接口地址。我这次实验里链路B的一端接口一开始协议状态是down的查了半天发现是对端接口没配地址也没开。这种低级问题在实验里很常见但真实排错时反而容易忽略因为大家习惯性地认为“我配了这边那边应该没问题”。直连链路两端必须都完成配置协议状态才会起来这个因果关系要刻在脑子里。直连路由验证通过后路由表里应该能看到每个已配置网段对应的直连路由标志是路由来源为直连。这时候两端PC还ping不通因为中间隔了路由器非直连网段没有路由。这正是下一步要解决的问题。2.3 一个关于掩码的实操心得配置接口地址时命令行里输入的掩码是点分十进制。这里有个小技巧如果你对点分十进制和前缀长度的换算不够熟练可以先把常用掩码背下来——/24是255.255.255.0/25是255.255.255.128/26是255.255.255.192/27是255.255.255.224/28是255.255.255.240。这几个在实验里出现频率最高。背下来之后配置时不用每次心算出错率会明显下降。另外接口配完地址后建议养成用查看接口详情的命令确认一遍的习惯重点看两处地址和掩码是否成对正确、接口是否被管理性关闭。有些设备的接口默认是关闭状态需要手动开启这个细节在换设备型号时特别容易踩。3. 静态路由配置下一跳到底该写谁3.1 静态路由的本质是“告诉设备往哪扔包”直连路由是设备自己“长”出来的接口一配地址它就知道了。但非直连网段设备一无所知必须人工告诉它。静态路由干的就是这件事目标网段 掩码 下一跳或出接口。它的逻辑特别朴素——你要去某个网段把包交给某个邻居剩下的让邻居去操心。这次实验里最左边路由器要到达最右边的终端网段中间隔了两跳。它自己只知道直连的链路A网段所以需要一条静态路由指向链路A对端的接口地址。同理中间路由器需要知道两端的终端网段各写一条静态路由。最右边路由器对称处理。整个配置下来每台设备的路由表里除了直连路由还会多出若干条静态路由。这里的关键决策是下一跳写对端接口地址还是写出接口两种写法在点对点链路上都能通但在实验环境里我强烈建议写下一跳地址。原因是写出接口的话设备会认为目标网段直接挂在这个接口上可能触发代理ARP之类的行为而且路由表里显示的可达性判断不如写下一跳清晰。写下一跳地址设备会先查下一跳是否可达可达才把这条路由放进转发表逻辑更严谨。3.2 我踩的那个掩码错位坑前面提到我在静态路由命令上栽了跟头具体是这样的配置一条目标网段为192.168.10.96/27的静态路由时我手一抖把掩码写成了255.255.255.0。命令没报错路由也进了路由表但就是不通。查路由表发现这条路由的前缀显示成了/24而实际网段是/27设备认为192.168.10.96/24这个网段存在但转发时目标地址落在/27范围内匹配逻辑就乱了。这个坑的教训是静态路由的掩码必须和目标网段的实际掩码严格一致。写完之后一定要看路由表确认前缀长度对不对。路由表里显示的前缀长度是判断掩码是否写错的唯一可靠依据别信自己敲命令时的手感。注意静态路由配错掩码不会报语法错误设备照单全收但转发行为是错的。这类“静默错误”比命令报错危险得多因为你会误以为配置成功了。3.3 路由表的阅读方法配完静态路由路由表里会混着直连路由和静态路由。学会读路由表是这次实验的核心技能之一。重点看几个字段目标网段/前缀、路由来源直连还是静态、下一跳、出接口、优先级。直连路由的优先级默认最高静态路由次之。当有多条路由指向同一目标时优先级低的生效。我建议每配完一台设备的路由就完整看一遍它的路由表逐条确认这条路由的目标网段对不对、下一跳是不是预期的邻居、出接口是不是预期的链路。这个习惯在实验阶段养成到了真实网络排错时能救命。因为真实网络的路由表可能几百上千条你不可能逐条看但你知道“正常应该长什么样”异常的那条一眼就能揪出来。4. 连通性验证与排错链路复盘4.1 分层验证从直连到端到端全部配置完成后验证要分层做不能一上来就端到端ping。我的验证顺序是直连链路验证每台路由器ping直连邻居的接口地址确认链路层和网络层都正常。单跳非直连验证最左边路由器ping中间路由器的远端接口地址验证静态路由是否生效。端到端验证两端PC互ping验证整条路径的路由是否完整。这个顺序的价值在于一旦某一步不通你能立刻定位问题出在哪一层。如果直连都不通问题在接口配置如果直连通但单跳不通问题在静态路由如果单跳通但端到端不通问题在末端设备或末端路由。我这次实验在第二步卡了一下最左边路由器ping中间路由器远端接口不通。查路由表发现静态路由存在、下一跳正确再查中间路由器的路由表发现它没有回程路由——它不知道怎么把回包送回最左边路由器的源地址网段。路由是双向的去程配了回程也得配这个道理简单但实操时特别容易漏。补上回程路由后单跳验证通过。4.2 端到端不通时的排查清单两端PC互ping不通可能的原因按概率从高到低排排查项检查方法常见问题PC的IP和网关看PC配置网关没配或配错PC的掩码看PC配置和路由器接口掩码不一致末端路由器路由看路由表缺目标网段的路由中间路由器路由看路由表缺双向路由接口状态看接口简要信息接口被关闭或协议down这次实验里我遇到的是PC网关配错。PC的地址是192.168.10.98/27网关应该是192.168.10.97我一开始手滑配成了192.168.10.1。结果PC发包时把网关地址当成目标ARP请求发出去没人应答通信直接断在第一步。改对网关后立刻通了。这个错误特别典型因为192.168.10.1是很多人对“网关”的默认印象但在这个子网划分方案里.1属于互联链路A的网段根本不是终端网段的网关。提示子网划分之后“网关地址”不再是习惯上的.1或.254而是你规划时指定的那个地址。配PC之前先回头看一眼规划表别凭肌肉记忆填。4.3 用抓包和路由追踪辅助定位当ping不通且路由表看着都对时下一步该上工具了。路由追踪命令能看到包经过的每一跳在哪一跳断掉一目了然。如果路由追踪显示包到了某台路由器就不再往前说明那台路由器缺下一段的路由或者下一跳不可达。抓包则能看到更底层的信息比如ARP请求有没有应答、ICMP回显请求有没有发出去。我在实验里用路由追踪确认过一次路径从最左边PC追踪到最右边PC输出显示经过了三台路由器每跳的地址都和规划一致说明路径完全正确。这种“看着都对但就是不通”的情况往往问题在更隐蔽的地方比如ACL实验里没配、NAT实验里没配或者PC本身的防火墙。把工具用起来比盯着路由表干瞪眼高效得多。5. 这次实验里几个值得记住的经验第一个经验关于地址规划的前置性。我一开始图省事想边配边规划结果配到第三个网段时发现前面的划分方式导致后面不好汇总只能推倒重来。后来改成先在纸上把五个网段全部列清楚、掩码统一、边界对齐再动手配置整个过程顺畅得多。地址规划这件事花十分钟在纸上能省一小时在设备前。第二个经验关于路由的双向性。静态路由不是配一条就完事去程和回程要成对考虑。每配一条“去”的路由就要问自己一句“回包怎么走”。这个思维习惯建立起来之后后面学动态路由时会轻松很多因为动态路由协议本质上也是在解决双向可达的问题只是把人工配置换成了协议自动计算。第三个经验关于验证的层次感。不要跳过直连验证直接做端到端也不要在端到端不通时只盯着末端设备看。分层验证、逐层排除是网络排错最朴素也最有效的方法。我现在的习惯是每完成一个配置阶段就验证一次把问题扼杀在最小范围内而不是全部配完再统一测——那时候出了问题可能的原因太多排查成本成倍上升。第四个经验关于命令行的肌肉记忆要建立在理解之上。掩码换算、下一跳选择、路由表阅读这些操作熟练之后确实可以靠手感但手感的前提是理解。我那个掩码写错的坑本质就是手感跑在了理解前面。每次敲完关键命令回头看一眼结果是否符合预期这个“回头看一眼”的动作价值极高。最后说一个实验之外但很实际的体会这套编址加静态路由的组合虽然简单但它是理解整个路由体系的钥匙。后面不管是OSPF的邻居建立、BGP的路由通告还是策略路由的匹配逻辑底层都绕不开“网段、掩码、下一跳、双向可达”这几个概念。把这个实验做透比急着往后赶进度有价值得多。我在配置过程中反复回到那张网段规划表上核对看似低效实际上每一次核对都在加固对编址逻辑的理解。这种“慢”后面会以“快”的形式还回来。