思科综合实验：从VLAN到OSPF的完整实战配置与排错指南

干网络这一行，我始终觉得，命令背得再熟，不如在设备上完整跑一遍思科综合实验。模拟器里敲命令和真机上敲命令，完全是两种手感：真机开机时风扇的轰鸣声、Console线驱动装不上时的手足无措、网线插错口后接口死活不UP的焦灼，这些都是模拟器给不了的第一手经验。这次整理了一套适合练手的思科综合实验，把VLAN、Trunk、STP、链路聚合、HSRP、OSPF、NAT、ACL、DHCP这些高频技术全部串进一个拓扑里，实机操作过程中踩过的坑也会一并写出来，希望对准备考网络认证、或者刚进运维岗的朋友有帮助。

1. 综合实验设计与拓扑规划思路

1.1 为什么用核心-汇聚-接入三层架构

很多人在实验室里喜欢把所有交换机堆在一起，用一台三层设备直接接所有终端，这样不是不行，但离真实园区网的形态太远。真实场景里，业务规模一大，网络就必须分层：接入层负责收敛终端，汇聚层负责VLAN间路由和策略控制，核心层只做高速转发。这种架构的好处是故障域可以隔离，哪个接入交换机坏了最多影响一个区域，不会把全网拖垮。

生活里比较好理解的类比是物流系统：接入层是各个小区门口的快递驿站，汇聚层是城市转运中心，核心层就是全国枢纽机场。如果所有驿站直接把包裹送到机场，线路乱、成本高、一旦某条线路拥堵全城瘫痪。网络分层是一样的逻辑，模块化设计之后，扩容、排错、安全策略落地都有清晰的着力点。

我这次设计的拓扑是标准的三层架构加双出口边界：核心层两台三层交换机，汇聚层两台，接入层四台，边界路由器一台，外加一台设备模拟运营商侧。双核心、双汇聚的好处是任意一条链路故障都不会导致业务全部中断，正好可以把HSRP、STP、OSPF冗余这几类技术全部练到。

1.2 地址规划与VLAN划分

实验里最忌讳的事就是随手配IP，配到后面自己都看不懂。我习惯先把整个地址规划表写出来，再动手敲命令。规划的时候要留出扩展余地，不要把一个C类地址塞得满满当当。

这次实验的业务VLAN规划如下，方便你直接抄：

核心交换机之间的互联网段用 10.0.10.0/30，核心与汇聚之间的互联用 10.0.20.0/30 和 10.0.21.0/30，边界路由器与核心之间用 10.0.30.0/30。Loopback地址分配给每台三层设备，用作OSPF的Router-ID，这是实机配置里的好习惯，后面会细说。

地址表定好后，另一个关键点是设备角色划分。我这里的核心交换机用两台三层交换机，跑HSRP和OSPF；汇聚交换机负责VLAN Trunk和生成树；接入交换机只划分VLAN、做端口安全；边界路由器负责NAT和DHCP中继。如果你手里只有低端设备，也可以把汇聚交换机的功能合并到核心交换机上，拓扑适当简化，但实验的核心逻辑不变。

1.3 实机操作环境准备

做这套实验，我建议先在Packet Tracer或者GNS3里把配置流程跑通，再上真机。原因很简单：模拟器里永远无法复现实机的很多“玄学”问题，比如光纤模块兼容性、Console线驱动、设备老化导致的接口协商异常。但反过来，模拟器能让你快速验证配置逻辑是否正确。逻辑通了，上实机只是时间问题。

真机操作前，有几样东西必须提前确认。首先是设备的IOS版本和特性集，不同版本某些命令细节不一样。比如老版本3560上配置HSRP v2要用standby version 2，有些精简版IOS甚至连这个命令都不认。其次是Console线驱动，实机连接前先在设备管理器里确认端口被正确识别，波特率一般用9600。最后是配置准备，把基础配置写成文本放旁边，逐条敲而不是整段粘贴，这样可以强迫自己理解每条命令的作用。

2. 二层链路搭建与冗余部署

2.1 接入层VLAN划分与端口配置

拓扑中的接入交换机，角色就是给终端划分VLAN，并把这些VLAN通过Trunk汇聚到上层。先看接入交换机的配置：

SW5#configure terminal SW5(config)#vlan 10 SW5(config-vlan)#name OFFICE SW5(config-vlan)#exit SW5(config)#vlan 20 SW5(config-vlan)#name FINANCE SW5(config-vlan)#exit SW5(config)#vlan 30 SW5(config-vlan)#name GUEST SW5(config-vlan)#exit SW5(config)#vlan 40 SW5(config-vlan)#name SERVER SW5(config-vlan)#exit SW5(config)#interface GigabitEthernet0/1 SW5(config-if)#switchport mode access SW5(config-if)#switchport access vlan 10 SW5(config-if)#spanning-tree portfast SW5(config-if)#spanning-tree bpduguard enable SW5(config-if)#exit

这里有两个细节值得注意。switchport mode access要写在访问VLAN前面，有些老设备上如果先设置了access vlan，再切access模式，接口会重新协商，可能导致终端暂时断网。portfast和bpduguard是给终端口用的，portfast让端口在接入设备后不等待生成树收敛直接进入转发状态，bpduguard防止有人往这个口上插交换机形成环路。两个命令同时使用，可以大幅提升终端接入速度和安全性。

对于上联到汇聚交换机的接口，配置就完全不一样了：

SW5(config)#interface GigabitEthernet0/24 SW5(config-if)#switchport mode trunk SW5(config-if)#switchport trunk allowed vlan 10,20,30,40 SW5(config-if)#switchport trunk native vlan 200 SW5(config-if)#no shutdown

上联口做Trunk时，建议显式指定放行的VLAN列表，而不是用默认的允许所有VLAN。原因有两个：一是减少广播域扩散范围，二是当新增VLAN时，如果默认放行所有VLAN，某些你不想放行的VLAN也会悄悄穿越链路，给排错增加难度。Native VLAN我单独抽出来做设备管理（VLAN 200），尽量与业务VLAN分离，这是实机运维的通用做法。

2.2 Trunk协商与DTP的坑

模拟器里敲switchport mode trunk一般不会出问题，但实机上存在一个隐藏的坑：DTP动态Trunk协商。思科交换机默认的端口模式是动态自动（Dynamic Auto），有可能和对端协商成Trunk，也可能协商成Access，视对端DTP模式而定。如果你一端配了trunk，另一端还是默认的dynamic auto，实机可能出现接口状态正常但VLAN流量无法穿越的现象，因为两端的Trunk没有真正协商成功。

解决方法是把所有和交换机互联的端口显式配置成switchport trunk encapsulation dot1q和switchport mode trunk，并且把对端同样配置成trunk模式。如果接口偶尔在access和trunk之间来回跳，可以考虑在端口下敲switchport trunk encapsulation dot1q后，再在接口模式里关闭DTP，用switchport nonegotiate实现。

Trunk检查命令是show interfaces trunk。我实际排错中见过太多案例，配置看着都对，就是从对端Ping不通，一查trunk状态，发现端口根本没起来，原因就是native VLAN不一致。两台交换机Trunk的native VLAN必须完全一致，否则会生成两层标签的帧，这种帧在多数设备上会被直接丢弃，表现出来就是同VLAN内通信故障。

2.3 生成树协议：冗余链路不能裸奔

有了Trunk之后，如果两台汇聚交换机之间再做了冗余链路，就必须考虑二层环路。网络中一旦出现环路，广播风暴能在几秒钟内把设备CPU打满。生成树协议的存在就是为了在物理环路的拓扑中逻辑上阻断冗余路径，同时保留故障切换的能力。

我在这套实验里把SW3设成VLAN 10和20的根桥，SW4设成VLAN 30和40的根桥，让不同VLAN的流量走不同的上行路径，实现负载分担。配置方式如下：

SW3(config)#spanning-tree vlan 10,20 root primary SW3(config)#spanning-tree vlan 30,40 root secondary SW4(config)#spanning-tree vlan 30,40 root primary SW4(config)#spanning-tree vlan 10,20 root secondary

用spanning-tree root primary而不是手动修改优先级，原因是这个命令会自动根据当前网络中的根桥优先级来调整值，保证自己成为根桥，省去人工计算优先级的麻烦。手动设置优先级也不是不行，但容易出现两台设备都觉得自己是根桥，导致生成树反复收敛。

生成树收敛期间，网络切换会有十几秒的延迟，这在实机操作时感受非常明显。为了减少切换时间，我在接入层终端的端口上开了portfast，前面配置里已经写到了。还要强调一个原则：Trunk端口永远不要开portfast，否则链路一抖动就可能引发临时环路。

2.4 链路聚合：让Trunk带宽翻倍

如果汇聚和核心之间的流量大，单条千兆链路会成瓶颈。链路聚合可以把多条物理链路绑成一条逻辑链路，带宽翻倍的同时，单条链路故障不影响业务。这属于综合实验里比较能体现实战水平的部分。

我用的是LACP动态聚合：

SW3(config)#interface range GigabitEthernet0/1-2 SW3(config-if-range)#channel-group 1 mode active SW3(config-if-range)#interface Port-channel1 SW3(config-if)#switchport mode trunk SW3(config-if)#switchport trunk allowed vlan 10,20,30,40

链路聚合有两个容易踩的坑。第一个是成员接口配置必须一致，包括VLAN模式、Trunk允许列表、Native VLAN，如果不一致，聚合组根本起不来。第二个是不要直接在物理接口上配置Trunk，要配置在Port-channel逻辑接口上，因为真正决定链路状态的是这个逻辑接口。

链路聚合检查命令是show etherchannel summary。正常情况下你会看到Port-channel1的状态是SU，SU表示Layer2（二层端口）且在使用。如果状态是SD，表示有成员接口Down，需要检查物理链路。SD状态非常常见，很多时候只是因为物理接口没有no shutdown，或者是光纤接到了错误的光口上。

3. 三层网关设计与冗余协议

3.1 核心交换机上的网关SVI

终端设备的网关一般放在核心交换机上，通过SVI（Switch Virtual Interface）来实现VLAN间路由。把网关放在核心层的原因，是让流量路径尽量短。如果网关放在汇聚层，而服务器在核心层，那么办公用户访问服务器就必须绕行核心，路径长了不说，汇聚设备压力也大。

SVI配置看起来简单：

SW1(config)#interface Vlan10 SW1(config-if)#ip address 192.168.10.2 255.255.255.0 SW1(config-if)#no shutdown

但实机上有个反直觉的坑：SVI哪怕配了IP，只要对应的VLAN里没有任何物理接口处于up状态，这个SVI就不会起来。比如VLAN 10只配置在SW1上，但SW1下行接口全部是shutdown，那interface Vlan10就算配置了地址也是down状态。排查VLAN间路由不通时，第一件事就是show ip interface brief，看SVI是不是up/up。

另一个坑是SVI接口默认不会自动开启。很多人在模拟器里忘了敲no shutdown，模拟器可能睁一只眼闭一只眼，但实机绝对不会。实机上新配的SVI接口状态默认是管理的down状态，必须手工no shutdown才能起来。我见过不止一次，核心交换机SVI配完地址后Ping不通，查了半天发现是接口被shutdown。

3.2 HSRP：双核心下的网关冗余

单台核心交换机一旦宕机，所有终端就失去了网关，业务全停。HSRP的原理是让两台核心交换机共用一个虚拟IP作为网关，平时由一台转发，另一台实时待命。终端感知不到切换过程，只有主备切换那几秒钟可能出现丢包。

我在两台核心上给每个业务VLAN配置HSRP：

SW1(config)#interface Vlan10 SW1(config-if)#standby version 2 SW1(config-if)#standby 10 ip 192.168.10.254 SW1(config-if)#standby 10 priority 120 SW1(config-if)#standby 10 preempt SW1(config-if)#standby 10 track interface GigabitEthernet0/1 20 SW1(config-if)#exit SW2(config)#interface Vlan10 SW2(config-if)#standby version 2 SW2(config-if)#standby 10 ip 192.168.10.254 SW2(config-if)#standby 10 priority 100 SW2(config-if)#exit

HSRP组号10是自由指定的，要和VLAN ID对应起来，排错时方便识别。优先级默认是100，SW1抢到了120的优先级，所以它是VLAN 10的Active设备，承载该VLAN的转发流量。preempt表示当SW1恢复并重新拥有更高优先级时，自动抢回Active角色，否则会出现主设备一直由SW2担任的尴尬情况。

track接口非常关键，它监听的是核心交换机的上联物理接口。如果上联断了，而且路由器侧没做其他的网络切换，这个track会触发优先级降低，让另一台核心接管网关，保证流量不中断。我这次把track对象的代价设为20，意味着当GigabitEthernet0/1 down掉后，SW1的HSRP优先级从120降到100，低于SW2的100？其实是等于100，这时候需要进一步的判断。为避免两台状态模糊，一般track扣分值要大于优先级差值，比如这里差值20，扣20正好打平，不够明确。稳妥的设置是扣25，确保SW2胜出。实际操作中我把扣分值改成了25。

HSRP排错优先用show standby brief，它会输出每个组的Active和Standby地址，一眼就能看出主备是否正常。如果看到两台设备同时显示Active，说明优先级或preempt配置出了问题，这就是经典的“双主”现象，会导致广播风暴和流量路径异常。

3.3 OSPF：让全网路由动态收敛

OSPF是这套实验里最核心的动态路由协议。我计划让核心交换机、汇聚交换机、边界路由器全部跑OSPF，把所有三层互联网段和业务网段宣告进区域0。区域0是骨干区域，所有非骨干区域必须连接到区域0，这是OSPF的最基本规则。

Router-ID我统一用Loopback地址。Loopback地址的好处是永远不down，稳定性极高，比用物理接口地址更不容易导致OSPF邻居震荡。配置示例：

SW1(config)#interface Loopback0 SW1(config-if)#ip address 1.1.1.1 255.255.255.255 SW1(config-if)#exit SW1(config)#router ospf 1 SW1(config-router)#router-id 1.1.1.1 SW1(config-router)#network 10.0.20.0 0.0.0.3 area 0 SW1(config-router)#network 192.168.10.0 0.0.0.255 area 0 SW1(config-router)#network 192.168.20.0 0.0.0.255 area 0 SW1(config-router)#passive-interface default

OSPF的区域网段宣告用的是反掩码（wildcard mask），这个新手经常搞混。反掩码是子网掩码取反，比如/24网段，子网掩码是255.255.255.0，反掩码就是0.0.0.255。/30网段的反掩码是0.0.0.3。如果写错反掩码，OSPF会把更多或更少的网络宣告出去，导致路由表异常。

passive-interface default这个命令我个人强烈建议用，它的作用是默认所有接口都停止发送OSPF hello包，然后再对真正需要建立邻居的接口单独开启。好处是可以避免将OSPF hello包发给终端VLAN，减少不必要的时间探活报文，同时也能防止某些安全设备对OSPF报文产生告警。

OSPF的hello间隔和死亡间隔在以太网链路上默认是10秒和40秒，两端必须一致，否则邻居关系卡在Init状态。实机排错时先看show ip ospf neighbor，如果邻居出现在Init状态，重点排查接口两端hello间隔、区域ID、认证是否一致，还要确认接口没有被配置成被动模式。

4. 出口NAT、ACL与DHCP服务落地

4.1 DHCP自动分配地址与跨网段中继

网关配好后，终端如果还要手工配IP，显然不符合实际运维习惯。DHCP服务器可以直接放在核心交换机上，也可以放在边界路由器的外部，我这里为了减少设备数量，把DHCP配置放在核心交换机。

核心交换机上的DHCP池配置要注意两点：第一，保留地址段里的网关地址和交换机管理地址，否则这些地址可能被终端抢走；第二，默认网关参数必须和HSRP虚拟地址一致，不能填成某台物理设备的真实IP。

SW1(config)#ip dhcp excluded-address 192.168.10.1 192.168.10.3 SW1(config)#ip dhcp excluded-address 192.168.10.254 SW1(config)#ip dhcp pool VLAN10 SW1(dhcp-config)#network 192.168.10.0 255.255.255.0 SW1(dhcp-config)#default-router 192.168.10.254 SW1(dhcp-config)#dns-server 192.168.40.10 SW1(dhcp-config)#exit

如果DHCP服务器在核心交换机上，而终端在接入层，只要SVI已经起了VLAN间路由，DHCP请求可以正常跨网段？其实不行。DHCP discover是广播包，路由器默认不会转发广播，所以必须借助DHCP中继。我需要在接入层或者汇聚层的SVI上配置ip helper-address 192.168.40.254（指向DHCP服务器所在的SVI地址），这样广播的DHCP请求会被封装成单播发往DHCP服务器。

ip helper-address会默认转发很多UDP广播服务，除了DHCP之外，还包括TFTP、DNS等。如果你只是想转发DHCP，可以用ip forward-protocol关闭其他端口，避免无意中把不该广播的服务转发出去。这个细节在真实网络中也容易被忽略。

4.2 NAT与PAT：让内网访问外网

边界路由器R1是内外网的分界点。内网接口配置成inside，连接运营商侧的接口配置成outside，然后启用PAT，让所有内网用户共享公网接口地址访问外网：

R1(config)#interface GigabitEthernet0/0 R1(config-if)#ip address 192.168.40.1 255.255.255.0 R1(config-if)#ip nat inside R1(config-if)#exit R1(config)#interface GigabitEthernet0/1 R1(config-if)#ip address 203.0.113.1 255.255.255.252 R1(config-if)#ip nat outside R1(config-if)#exit R1(config)#access-list 1 permit 192.168.0.0 0.0.255.255 R1(config)#ip nat inside source list 1 interface GigabitEthernet0/1 overload

这里不能用简单的ACL匹配出所有需要的网段。注意ACL 1里写了permit 192.168.0.0 0.0.255.255，它匹配的是所有192.168.x.x地址，包括VLAN 10、20、30、40和互联网段。如果你只写单个网段，其它网段访问外网就会失败。标准ACL只能匹配源地址，无法区分访客还是办公用户，这个任务要交给下面的扩展ACL来细化。

边界路由器上还应该配置一条默认路由指向运营商侧，否则NAT转换后的流量不知道往哪送。我在实验里用R2模拟运营商侧，R1上配了静态默认路由指向10.0.30.2，并且把该路由重分布到OSPF，这样整个内网都知道去往外网的路径。

NAT验证命令是show ip nat translations。正常情况下你会看到内网地址和公网接口地址的映射关系，以及端口号。如果外网地址显示为空，很可能是inside和outside接口放反了。这一条，实机操作时真的坑过不少人，因为命令不报错，你很难分辨。

4.3 ACL策略：不同业务的访问控制

ACL是网络工程师的基本功，也是这套实验的重点。我用扩展ACL实现以下策略：

• 办公VLAN 10可以访问服务器区任意端口和外网；
• 财务VLAN 20只能访问服务器区的数据库端口和特定业务端口；
• 访客VLAN 30只允许访问外网的HTTP和HTTPS，禁止访问内网所有业务VLAN。

配置访客VLAN的ACL如下：

R1(config)#ip access-list extended GUEST-OUT R1(config-ext-nacl)#permit tcp 192.168.30.0 0.0.0.255 any eq 80 R1(config-ext-nacl)#permit tcp 192.168.30.0 0.0.0.255 any eq 443 R1(config-ext-nacl)#deny ip 192.168.30.0 0.0.0.255 192.168.0.0 0.0.255.255 R1(config-ext-nacl)#permit ip 192.168.30.0 0.0.0.255 any R1(config-ext-nacl)#exit R1(config)#interface GigabitEthernet0/0 R1(config-if)#ip access-group GUEST-OUT in

ACL的匹配规则是自上而下顺序匹配，一旦命中立即执行，不再继续向下匹配。所以我先放行了80和443端口，再拒绝访问内网网段，最后放行其他所有流量。如果把deny语句放在最后，前面的permit any就已经放行所有流量了，后面的deny永远没机会执行。这种顺序错误在实机配置中极其常见，而且不像语法错误会被设备拒绝，它表现出的行为是：策略看似生效了，但某个不该通的流量恰恰通了。

此外，ACL配置完一定要在用show access-lists查看匹配计数。每一条规则后面都会有match计数，如果某条规则的计数始终为0，说明流量并没有走到这一条，先检查ACL应用接口和方向是否正确，再检查是否存在更靠前的规则把流量拦截或放行了。

5. 实机操作经验：从模拟器到真机的跨越

5.1 真机启动、Console登录与密码恢复

模拟器点开设备就能敲命令，真机则不然。实机操作的第一关是Console连接。很多新手的第一个坑出现在驱动上：Console线插上电脑后没有识别到COM口，或者识别到了但SecureCRT/PuTTY里回车没反应。最常见的原因是驱动没装好，其次是波特率设置不对。思科设备的Console默认波特率是9600，数据位8，停止位1，无校验，流控关闭。如果这些设置不对，屏幕上要么是乱码，要么完全没反应。

设备上电后要留意自检信息。Flash中的IOS加载异常时，设备会进入ROM Monitor模式，提示符是rommon>。这种情况通常需要重新引导或重新传IOS。我在实验里没见过这么严重的故障，但听说过真机掉电导致Flash损坏的案例，所以养成习惯是：上电后第一时间show version，确认当前运行的IOS符合预期，特性集支持你要用的功能。

密码恢复是网工迟早要面对的场景，真机上密码忘了也能进入配置模式。恢复过程通常是在设备上电自检时按Break键进入ROM Monitor模式，然后修改配置寄存器，重新引导后进入无密码的启动配置，最后再修改密码并恢复寄存器值。注意恢复完一定要把配置寄存器的值改回0x2102，否则下次重启还会跳过startup-config，配置全部丢失。这种密码恢复属于设备管理维护范畴，但前提是你对设备有合法的管理权限。

5.2 配置保存与备份

模拟器里你关掉设备前不保存配置，下次重开会丢失；真机也一样。但真机比模拟器更严肃的一点是：配置如果不保存，一旦设备重启，一切回到出厂状态，业务会直接中断。实机配置的关键节点，必须执行write memory或copy running-config startup-config。

我个人更推荐用copy running-config startup-config，因为它的输出信息更完整，会显示配置写入的目标文件路径。保存完成后，建议用show startup-config对比一下启动配置里的内容和运行配置是否一致。如果发现保存失败，多半是Flash空间不足，或者文件系统的写保护被开启。

除了本地保存，还要把配置备份到外部。最直接的方式是开启设备的TFTP客户端，把配置文件传到一台内网电脑上管理，命令是copy startup-config tftp:。备份配置文件的同时，也用同样的方式备份一份IOS镜像到本地，这样就算设备Flash故障，也能通过网络把IOS重新灌进去。

5.3 实机连线与接口状态检查

实机上经常出现“配置都对，就是链路不UP”的情况。我先说网线和光纤的区别：普通以太网口用网线，接反了会提示接口down，数通设备上基本不会因为线序问题导致物理层长期up不起来。光纤则不同，光口必须使用匹配的SFP模块，两端的光模块波长和速率要一致，连接时还要注意TX和RX方向。纤芯接反的典型表现是接口一直down，而且设备上会有LOS告警。

接口状态的排查顺序是：先看物理层，再看数据链路层。物理层的表现是接口状态为up/up，如果显示为up/down或down/down，说明数据链路层或物理层有问题。用show interface status可以查看接口是否被禁用以及VLAN信息，用show interfaces GigabitEthernet0/1可以查看详细的duplex、speed、CRC错误计数。CRC错误计数持续增长，通常是双工模式不匹配或网线质量差导致的，这时需要调整两端设备的双工模式，让它们一致。

实机操作还有一个模拟器永远无法还原的体验：设备的接口命名和实际物理端口位置可能对不上。比如你配置的是GigabitEthernet0/1，但物理上这个端口是设备前面板的第三个口。每次配置前，先贴着设备标签确认端口位置，省得把线插错地方，一查接口状态才发现配错了口。

6. 常见问题速查与排错方法

6.1 综合实验常见故障速查表

实机操作的过程中，我把容易遇到的故障整理成一张速查表，方便排查时快速定位方向：

这张表里的每一条，我在实操中都遇到过，后面逐个展开。

6.2 从物理层到应用层的排错逻辑

网络排错不要一上来就查路由协议，最有效的顺序是从底层往上走。先看物理层：接口是不是up/up，光模块有没有告警。再看链路层：Trunk状态是否正常，生成树端口是不是阻塞状态。然后看网络层：终端能不能Ping通网关，路由表里有没有对应条目。最后才是应用层：DHCP能不能拿到地址，ACL有没有拦截数据。

我举个真实例子。有次实验里，VLAN20的终端无法访问服务器区，但是VLAN10的同款终端完全正常。如果一上来就怀疑OSPF配置，那就跑偏了。合理路径是：先确认VLAN20的SVI是否正常工作，再检查HSRP是否把VLAN20的Active设备切到了另一台核心，最后检查ACL。结果真凶是财务VLAN的ACL里多写了一条deny tcp any any，把包括服务器区在内的所有TCP流量都拦截了。这种策略错误，不把ACL匹配计数调出来看，光靠猜根本碰不到。

用Ping做二层和三层的连通性测试也有讲究。在核心交换机上直接Ping终端地址，能通说明三层可达；在接入交换机上Ping终端地址，能通说明二层链路正常。如果核心能Ping通终端、但终端Ping不通网关，要怀疑终端的网关地址配置，或者HSRP虚拟地址不响应ARP请求。

6.3 用抓包工具辅助验证

抓包是排错时的放大器，尤其是学习阶段，它能让你把抽象协议变得具体。抓OSPF邻居建立过程，你能看到Hello报文的发送周期；抓HSRP转换过程，你能看到Active设备发出的hello报文间隔；抓DHCP四步交互，你能看到Discover/Offer/Request/Ack的完整流程。这一套抓下来，协议的理解深度就完全不一样了。

在模拟器里可以直接用内置的抓包功能，实机可以用Wireshark接在设备镜像端口上。对于综合实验来说，最值得抓的报文是HSRP的hello报文，因为它的组播地址是224.0.0.2，周期是3秒，能看到Active和Standby设备的优先级字段，这对理解主备切换机制很有帮助。OSPF的hello报文周期是10秒，组播地址是224.0.0.5，抓包时注意过滤条件，否则会被其它广播报文淹没。

抓包也不是万能钥匙，它只能证明当前链路上实际流动的报文是什么，无法自动告诉你配置哪里错误。关键还是结合配置去推导预期行为，再拿抓包结果验证预期，这样才能快速定位到异常点。

7. 实操心得与个人体会

这套思科综合实验，我前后在模拟器里完整跑过三遍，再用实机复现时，依然踩了好几个模拟器发现不了的坑。比如实机光模块兼容性问题，比如某台设备IOS特性集不支持HSRP v2，比如Console线驱动版本不对导致回车没反应。这些问题的共同点是：模拟器环境太干净了，任何一根线缆插上都是理想状态，而实机是物理世界，各种工程细节都会影响结果。

我的建议是，模拟器用来练逻辑，真机用来练手感。把拓扑图、地址规划表、设备配置脚本打印出来放在旁边，一条一条命令手工敲，边敲边用show命令验证效果，不要整段粘贴。改配置之前先show running-config备份一份，出了问题才能快速回退。

真正让你成长的往往不是记住某条命令，而是网络故障发生时，你能从交换机灯光变化、日志告警、配置差异中一步步定位根因。这个过程没有捷径，只能靠一次一次实机操作去积累敏感度。如果你现在手头有思科设备，建议直接把这套实验搭起来跑一遍；如果没有真机，用新版模拟器把逻辑跑通，再去参加一些有真机实操条件的训练营或课程。等你在真机上独立完成过一次全网通调，你会发现之前背的那些协议原理，突然全部串起来了。