做网络实验这些年我个人最大的体会是二层技术看着基础真正到HCIP级别反而不容易拿分。很多朋友把精力全放在OSPF、BGP这些路由协议上一碰到PPP和MGRE就开始含糊——尤其是把它们放在一个综合实验里既要处理点对点链路的认证协商又要处理NBMA网络上的隧道封装脑子和手都得在线。这篇博文我就拿一个我自己常练的二层综合实验做例子把PPP点对点协议和NBMA网络上的MGRE隧道技术从头到尾拆开讲清楚包括底层原理、配置思路、验证手段还有我踩过的那些坑。不管你是正在备考HCIP还是在企业网络里做分支互联这篇内容都能帮你少走弯路。1. 项目整体设计与思路拆解1.1 为什么“二层技术”里先要啃PPP和MGREHCIP考试大纲里二层技术往往被考生当成“送分题”实际上恰恰相反。PPP和MGRE这两块内容单个拿出来都不算复杂但它们共同覆盖了两种截然不同的网络模型一个是串行链路上的点对点模型一个是NBMA网络中的多点隧道模型。你只有把这两种模型的本质差异理解透了才能在做综合实验时不混乱。先说PPP。它工作在OSI模型的第二层主要解决的是两点之间直接连接的链路层协商问题。企业里两台路由器通过串口直连、或者拨号链路互连这种场景下PPP几乎是标配。它比HDLC多了一个非常重要的能力——认证。也就是说对端想接入你的网络必须先证明自己的身份这让PPP在安全性上天然优于老式的HDLC封装。再说MGRE。MGRE全称是Multipoint GRE多点GRE隧道技术。它解决的问题是底层网络是NBMA非广播多接入环境比如Frame Relay、ATM或者只是简单的以太网多分支互联你不可能像局域网那样直接广播也不可能给每一对分支都建一条专线这时候就需要一条逻辑隧道把分散的站点“虚拟”成一个可广播的overlay网络。把这两个技术放进同一个实验本质上是在逼你同时掌握两套思维PPP是“两点一线”的协商式思维MGRE是“多点网状”的注册式思维。能在一台设备上同时把这两种链路配置好、验证通才算真正跨过了HCIP二层的门槛。1.2 一个实验里同时仿真两种二层网络的价值刚开始做实验时我也怀疑过PPP和MGRE一个走串口、一个走隧道放在一个实验里会不会互相干扰做了几遍之后我发现这恰恰是最有价值的组合。原因很简单。现实中的分支网络从来不是单一技术构成的。一台出口路由器上可能一边通过运营商的串行链路连接到中心机房PPP另一边通过互联网隧道连接着另外几个分支机构MGRE。如果只在实验里单独练PPP你练不出“多条链路协同工作”的排障能力只单独练MGRE你又容易忽略链路层认证细节对上层隧道的影响。所以我把实验设计成这样一种结构两个分支站点之间的通信必须同时穿越一条PPP链路和一段MGRE隧道中间再由路由协议把overlay网络和物理链路串起来。这样配置、验证、排障的过程就是完整的一条链路端到端的检查你会真正体会到什么叫“二层不通三层白搭”。1.3 实验拓扑设计和地址规划为了贴合实际又不过度复杂我用了某企业“中心—分支”互联的场景模型。整个拓扑包含四台设备中心路由器R1作为MGRE隧道的hub端同时也是网络核心出口分支路由器R2和R3作为MGRE的spoke端通过隧道与中心互联串行链路设备R4通过PPP与R2点对点相连模拟运营商或另一部门的接入链路。IP地址规划时我特意把物理链路和隧道链路分成了不同的网段杜绝“地址巧合导致路由混乱”这种情况。物理链路使用10.1.x.x网段隧道overlay网络使用192.168.x.x网段用户侧则使用172.16.x.x网段。这样后面看路由表、ping测试时一目了然不用反复对着拓扑猜这个地址是哪条链路的。提示做二层综合实验最忌讳的就是IP地址规划随意。哪怕只是练习也要养成“网段分离、可读性强”的习惯否则实验一复杂排障时间全浪费在认地址上。2. PPP点对点协议核心细节与认证机制2.1 PPP协议栈拆解从LCP协商到NCP分配地址PPP并不是一个单一的协议它是一个协议族核心分成两层LCP链路控制协议和NCP网络控制协议。链路刚起来的时候PPP先通过LCP完成链路参数协商比如MRU最大接收单元、认证协议类型、是否启用压缩等。这就像两个人见面先握手、互相确认说话规则LCP里的Configure-Request、Configure-Ack、Configure-Nak、Configure-Reject这四种报文就是双方在“讨价还价”。LCP协商通过之后链路进入认证阶段再进入NCP阶段。NCP里最关键的是IPCP。IPCP负责在链路两端协商IP地址——比如一端给另一端分配地址或者双方确认自己的地址不会冲突。整个串行链路直到IPCP协商完成才会生成对应的直连路由三层才能通。我做实验时习惯先在物理接口上强制指定链路层协议再去看 LCP 协商情况interface Serial1/0/0 link-protocol ppp ip address 10.1.12.1 255.255.255.252然后用display ppp link查看协商状态。如果看到状态停留在Establish或Authenticate说明还没走完流程先别急着ping对端把链路层搞定再说。2.2 PAP与CHAP的取舍与配置差异PPP最核心的价值就是认证。认证方式主要有两种PAP和CHAP。PAP全称Password Authentication Protocol特点是把用户名和密码以明文方式发送给对端。配置相对简单但它的致命短板也在这里——抓包就能看到密码所以现在的生产环境基本不用PAP只在实验里图省事或者一些老旧设备上才看得到。CHAP全称Challenge Handshake Authentication Protocol是更安全的方案。它的思路是“挑战-响应”认证方先发送一个随机挑战值给对端对端用这个挑战值加上自己的密码做哈希运算把结果传回来认证方再用本地保存的密码做同样的哈希比对结果。整个过程中密码本身不会在链路上明文传输安全性高了一个量级。我建议备考和实战都直接上CHAP。配置示例# R2作为被认证端 interface Serial1/0/0 link-protocol ppp ppp authentication-mode chap ppp chap local-user R2 ppp chap password simple R2123# R4作为认证端 interface Serial1/0/0 link-protocol ppp ppp authentication-mode chap这里有个关键点CHAP的验证方向不一定是你想的那样。如果一边只配置了认证模式一边配置了本地用户名和密码那这个配置往往只验证了一条方向。想要双向认证两边都得互相配置对方能通过的本地用户。最省心的做法是两边都配置ppp authentication-mode chap ppp chap local-user 用户名 ppp chap password simple 密码两端都带local-user和passwordCHAP挑战谁、响应谁都能对上。这是我实验里踩过最多坑的地方——只配单向认证链路状态会在Authenticate阶段反复横跳就是起不来。2.3 PPP链路MTU、MRU和二层封装的关系PPP链路还有个很容易被忽略的问题MTU和MRU。很多人在实验里发现PPP链路能PING通但一传大文件就卡住多半是MTU不一致导致的。以太网默认MTU是1500字节但PPP链路因为要额外开销我一般会把串行接口的MTU显式设成1492甚至更小避免后端设备发出1500字节的报文到了PPP链路又需要分片引发“黑洞”。配置方法interface Serial1/0/0 mtu 1492 ppp mrru 1492如果要跑动态路由协议还建议配合调整协议报文的大小比如OSPF的ip ospf mtu-ignore选项否则双方Hello报文可能因为MTU不一致而一直卡在ExStart状态。注意改MTU这件事链路两端必须匹配。只改一端不改另一端LCP协商阶段就会被Reject链路直接起不来。除了MTUPPP还支持多链路捆绑也就是MPPPMultilink PPP。当你有多条串行链路需要合并带宽时可以通过interface Mp-group 1 ppp mp然后把多条物理串口加入同一个Mp-group。这个技术生产里用得不少考试里也爱考。综合实验如果想提升难度可以给R2加两条串口做捆绑顺便体会有状态负载均衡的效果。3. NBMA网络上MGRE隧道的原理与实现3.1 NBMA网络到底“不便”在哪里NBMA的全称是Non-Broadcast Multiple Access非广播多接入网络。字面上理解就是很多设备接在同一个网络上但这个网络不支持广播——即使你发一个广播帧也不是所有节点都能收到甚至正常情况下只有被明确指定的接收者能收到。这种网络形态在早期广域网里非常常见。典型就是帧中继和ATM。现在也有大量分支互联依赖运营商提供的MPLS或VPLS底层同样不给你广播能力。那问题来了TCP/IP协议族里的很多协议比如ARP、OSPF的Hello组播、部分路由协议的邻居发现机制都严重依赖广播/组播能力。你在NBMA网络上想跑这些协议就得想办法把底层不可广播的事实“藏起来”。传统的思路有两种一是子接口把NBMA网络切成多条逻辑点对点链路典型做法是帧中继里的point-to-point子接口二是全互联的PVC——但这种方式配置量大新增一个节点就要把所有PVC全部重配一遍扩展性极差。GRE隧道给了一个新思路用逻辑隧道把底层BSMA网络包装成一个虚拟的点对点或多点网络。你在NBMA底层之上建立GRE隧道叠加一层IP让路由协议跑在隧道里。这么一来底层的不便就被完全屏蔽了。3.2 MGRE如何通过NHRP协议实现动态映射普通GRE tunnel是point-to-point的你必须指定 destination。如果我有10个分支就要建9条隧道配置量非常大而且每条隧道都占用独立的逻辑接口资源管理起来很头疼。MGRE的进步就在于它把隧道定义成 multipoint也就是p2mp点对多点。可问题又来了既然是点对多点那隧道封装的时候到底该把GRE报文发给谁这就需要一个机制动态地把“隧道对端IP地址”和“底层物理NBMA地址”对应起来。这个机制就是NHRPNext Hop Resolution Protocol。NHRP的逻辑可以类比成电话黄页中心节点作为hub相当于总机每个spoke节点上线之后会主动向hub注册自己告诉hub“我的逻辑IP是什么、我的物理地址是什么”。hub把这些信息记录下来生成一张映射表。更关键的是如果某个spoke想访问另一个spoke它不需要把流量全部绕经hub。只要spoke先向hub询问“目标spoke的物理地址是多少”hub把记录告诉它然后它就可以直接封装GRE报文发给目标spoke。这就解决了“spoke-to-spoke直连”的问题同时避免了配置全互联隧道的噩梦。我搭建MGRE时核心配置在Tunnel接口上interface Tunnel0/0/1 tunnel-protocol gre p2mp source GigabitEthernet0/0/1 destination dynamic ip address 192.168.13.1 255.255.255.0 nhrp network-id 128 nhrp entry 192.168.13.2 register上面这段tunnel-protocol gre p2mp是MGRE的关键标志source指定物理接口不能写死IP地址方便物理IP变化时隧道仍能建立destination dynamic表示目标由NHRP动态解析nhrp entry ... register表示向hub注册自己。在hub端配置略有不同interface Tunnel0/0/1 tunnel-protocol gre p2mp source GigabitEthernet0/0/1 ip address 192.168.13.1 255.255.255.0 nhrp network-id 128 nhrp entry 192.168.13.2 nbma-address 200.1.1.2 nhrp entry 192.168.13.3 nbma-address 200.1.1.3hub端不需要动态注册自身它只需要维护一张静态注册表每个spoke的逻辑地址对应什么物理地址。spoke主动注册之后hub就能基于这张表转发NHRP响应。3.3 MGRE隧道上的路由协议运行方式隧道建立之后要让它真正跑业务还得在隧道接口上跑路由协议。这里有一个重要选择OSPF还是EIGRP在HCIP里OSPF为主。OSPF在MGRE上有两种典型玩法。第一种是非广播模式就是把网络类型手动设为nbma然后手动neighbor指定邻居OSPF的Hello通过单播发送。这种方式稳定但新增节点麻烦。第二种更常用把接口网络类型设为broadcast或p2mp。如果是广播模式OSPF会选举DR/BDR容易受到NBMA底层的影响我更推荐p2mp模式因为这种模式下OSPF可以自动发现邻居用组播发送Hello而且在部分mesh场景下也能正常工作interface Tunnel0/0/1 ospf network-type p2mp ospf timer hello 10配了OSPF之后别忘了在物理链路和隧道上都宣告对应网段。这样端到端路由才能通。4. 二层综合实验的完整搭建过程4.1 实验拓扑与地址规划清单我的实验拓扑至少包含四台设备为了便于理解下表是整体规划设备角色物理接口/地址隧道接口/地址说明R1MGRE HubGigabitEthernet0/0/1: 200.10.1.1/24Tunnel0/0/1: 192.168.13.1/24中心节点维护NHRP表R2MGRE Spoke PPPGigabitEthernet0/0/1: 200.10.1.2/24Serial1/0/0: 10.1.12.1/30Tunnel0/0/1: 192.168.13.2/24既做隧道分支又承载PPP链路R3MGRE SpokeGigabitEthernet0/0/1: 200.10.1.3/24Tunnel0/0/1: 192.168.13.3/24远端分支负责验证spoke直连R4PPP对接设备Serial1/0/0: 10.1.12.2/30—模拟运营商接入验证跨链路通信这里有一点值得说明我把R2既当作MGRE的spoke又当作PPP的对端目的是在同一个节点上验证“隧道overlay网络”和“物理串行链路”如何桥接。如果R2上把两条链路都宣告进路由协议那么R3去往R4的流量路径会非常有意思先是GRE到R2再从R2经PPP到R4链路层次感很清晰。4.2 从零开始的设备配置实操先把物理口配置好。R2的物理以太口对接MGRE底层串口对接PPP# 设备R2 interface GigabitEthernet0/0/1 ip address 200.10.1.2 255.255.255.0然后配置PP链路。两端都使用CHAP# 设备R2 interface Serial1/0/0 link-protocol ppp ip address 10.1.12.1 255.255.255.252 ppp authentication-mode chap ppp chap local-user R2 ppp chap password simple R2123# 设备R4 interface Serial1/0/0 link-protocol ppp ip address 10.1.12.2 255.255.255.252 ppp authentication-mode chap ppp chap local-user R4 ppp chap password simple R4123注意R2上我既配置了认证模式又配置了local-user这是为了让R2既能验证对端又能被对端验证实现双向CHAP。再配置MGRE。先做hub端R1# 设备R1 interface GigabitEthernet0/0/1 ip address 200.10.1.1 255.255.255.0 interface Tunnel0/0/1 tunnel-protocol gre p2mp source GigabitEthernet0/0/1 ip address 192.168.13.1 255.255.255.0 nhrp network-id 128 nhrp entry 192.168.13.2 nbma-address 200.10.1.2 nhrp entry 192.168.13.3 nbma-address 200.10.1.3然后是spoke端R2和R3# 设备R2 interface Tunnel0/0/1 tunnel-protocol gre p2mp source GigabitEthernet0/0/1 ip address 192.168.13.2 255.255.255.0 nhrp network-id 128 nhrp entry 192.168.13.2 registerR3同理把地址换成.3。spoke端的nhrp entry ... register是注册到hub的关键命令。到这里二层链路已经全部配置完毕。但要让流量端到端通还需要在隧道接口上跑一个动态路由协议。我用OSPF把overlay网段都宣告进去# 设备R1、R2、R3 隧道接口下 ospf network-type p2mp同时把R2的PPP链路也宣告进OSPF# 设备R2 ospf 1 area 0 network 10.1.12.0 0.0.0.3 area 0 network 192.168.13.0 0.0.0.255 area 0 network 200.10.1.0 0.0.0.255 area 0R4也可以跑OSPF只需要宣告PPP链路网段。这样理论上全网所有路由都能学到了。4.3 连通性验证和路径观察方法配置完毕之后不要急着庆祝一步一步验证。我用的是“从物理层到隧道层再到路由层”的验证顺序。先看PPP链路状态display ppp link正常情况能看到链路状态变成Link up认证也正常。如果卡在Authenticate阶段十有八九是CHAP的local-user和password不匹配。再看MGRE隧道display tunnel-info all能看到Tunnel0/0/1的状态Protcol是GRE P2MP。接着看NHRP学习结果display nhrp briefhub上应该能看到两个spoke注册的IP地址和物理地址。如果只有hub自身的条目没有spoke条目说明spoke的注册没到hub重点排查source地址和物理路由是否可达。确认链路以后测试端到端连通。先从R1 ping R3的隧道地址ping 192.168.13.3通了说明隧道广播域正常。然后再从R3 ping R4的串行接口地址10.1.12.2这个过程中流量要经过R2的隧道解封装再走PPP如果通了说明二层链路协作正常。想看实际路径可以用路由表和tracertdisplay ip routing-table 10.1.12.2 tracert 10.1.12.2正常情况下路径应该体现为R3到R2再到R4。如果路由表里优先级异常或者路径多绕了hub多半是OSPF网络类型配置不对或者NHRP spod直连没生效。4.4 实验完成标准和扩展点我给自己定的完成标准有三条第一所有物理链路和隧道接口都是up状态第二R1、R2、R3上都能看到OSPF邻居且路由表完整第三任意两台设备之间端到端丢包率为0。满足这三点之后还可以自己加难度比如在spoke和spoke之间断开物理链路观察隧道是否会因为NHRP缓存失效而中断或者在hub上设置过滤策略强制流量经过中心节点而不是spoke直连这种“中心化流量”和“分布化流量”的切换练习对理解MGRE非常有帮助。5. 实战中遇到的问题与排查速查手册5.1 隧道起不来时先查四样东西MGRE隧道建立不起来是我在实验里遇到最多的状况。后来我总结了一个四步排查法按顺序查基本能定位九成问题。第一步看底层物理链路。display ip interface brief里GigabitEthernet0/0/1必须是up的协议也必须up。如果物理口都不通后面全部白搭。第二步看source配置。MGRE要求source要么是物理接口、要么是物理IP地址如果写成looback口或者不存在的地址隧道肯定起不来。而且source对应的接口不能down否则tunnel上报源无效。第三步看NHRP。spoke端必须存在nhrp entry ... registerhub端必须存在对应spoke的静态映射。如果register漏了spoke永远注册不上。我在实际调试中遇到过一种很隐蔽的情况hub上的映射表存在但物理地址写错了spoke发来的注册请求hub根本没回应。排查时要核对注册进来的源地址是不是实际物理口IP。第四步看路由。隧道接口配了IP不够还得确保底层物理路由能互达。比如R1能ping通R2的物理地址这是NHRP注册成功的前提。如果物理路由有问题先把静态路由或OSPF在底层跑通再说。提示实验里我最常用的组合拳是display nhrp brief加display tunnel-info all。一个看NHRP映射是否学习到位一个看隧道封装模式是否正常。两个命令一对比八成问题都能定位。5.2 PPP链路反复重启、认证失败的典型解法PPP链路的问题多数集中在三个地方认证不匹配、MRU协商失败、时钟或DCE配置出错。认证不匹配最常见的现象是链路起来几秒钟又掉翻log能看到Failed to authenticate peer。如果你用CHAP检查两端的local-user和password是否和对方数据库一致。这里有个容易忽视的点CHAP验证用的密码不是“链路密码”而是“用户名对应的密码”。如果hub端的local-user变了但被验证端还是用老密码认证就失败必须两边同时更新。MRU协商失败的典型现象是链路一直发Configure-Nak。MRU不匹配或者MTU超过接口能力都会引发。解决方法很简单两端设置一致的mtu和mrru参数。实验设备默认MRU是1500实际串行链路经常不能到1500我习惯统一设1492避免大包问题。DCE/DTE的问题更基础。实验环境里如果用真机串口卡一端必须是DCE并配置时钟频率另一端是DTE。如果你是模拟器环境这一步可以跳过真机调试时别忘了在DCE端加clock rate 64000否则物理层根本不会up链路层更无从谈起。5.3 二层综合实验排障常用命令速查表我整理了一张自己实验时高频使用的命令表也分享给你贴在实验台旁边非常方便。检查目标命令判断标准物理接口状态display ip interface brief接口和协议均为up串行链路时钟display controllers serial看到Clock Rate信息PPP链路协商display ppp link状态为Link upPPP错误计数display ppp error无持续增长的错误计数隧道接口状态display tunnel-info all隧道模式为GRE P2MP状态upNHRP映射表display nhrp brief存在spoke的注册条目OSPF邻居display ospf peer邻居状态为Full路由表验证display ip routing-table所有预期网段均有路由端到端测试ping -a 源地址 目标地址丢包率为0路径验证tracert 目标地址路径符合预期这张表看起来简单但每次实验遇到“说不清哪里有问题”的时候按这个顺序过一遍基本能把问题压缩到某一个技术点上。这也是我比较推荐新手养成的习惯——不要一上来就抓路由表先把物理层和二层链路状态全部过一遍再往上层排。我个人在实际操作中还有一个习惯配置完每一个技术点之后立刻保存一次配置并用display命令留档。比如配完PPP就马上display ppp link看状态配完MGRE就马上display nhrp brief看映射。这样一旦后面出问题能很快判断是刚改的配置引入的还是前面就埋下了隐患。做综合实验最怕的就是一次性把所有配置全敲上去然后对着一个不通的现象从头猜到尾。最后再分享一个小技巧MGRE的spoke之间建立直连隧道后如果在hub上配置了基于隧道接口的访问控制要注意ACL影响的不仅仅是控制面还可能影响数据面的转发。如果实验里出现“NHRP能注册、路由能学到、但spoke间ping不通”的现象优先检查hub和spoke上的ACL是否放行了GRE协议号47以及ESP/NHRP相关报文。这个问题我当初排查了好几个小时纯属被ACL坑的体验提前给你排掉这个雷。