一、引言：一场突如其来的网络“分裂”
在云南做IT运维18年，服务过上百家中小企业，我深知网络故障对业务的冲击。2024年3月，昆明一家中小型制造企业突然向我求助：核心业务系统无法访问，员工电脑能ping通网关但无法跨部门通信。客户描述：“所有电脑都能上网，但财务系统连不上，ERP登录超时，车间终端全部掉线。” 这显然不是简单的网络断开，而是典型的跨VLAN通信故障。
我驱车1小时赶到现场，发现网络拓扑简单：一台华为三层交换机作为核心，下联多个接入交换机，划分了5个VLAN（办公、财务、生产、服务器、访客）。故障发生前，客户刚进行了网络改造——添加了新的ACL（访问控制列表）以限制访客VLAN访问内部资源。没想到，这条ACL成了“罪魁祸首”。
故障现象总结：
- 所有终端能获取IP地址，网关可通
- 同一VLAN内通信正常，跨VLAN全部失败
- 核心交换机CPU和内存使用率正常
二、排查过程：从现象到根因的三步走
第一步：基础连通性验证
我首先登录核心交换机，使用display ip interface brief检查所有VLAN接口状态，发现VLAN 10（办公）和VLAN 20（财务）的接口状态均为UP。接着用ping -a从核心交换机向两个VLAN的网关地址发送测试包，均正常响应。但ping跨VLAN的终端IP时，出现“Request time out”。
这确认了问题出在三层转发层面。我用display ip routing-table检查路由表，发现直连路由正常，但缺少默认路由或静态路由？不对，客户网络无需静态路由，因为所有VLAN都在同一台交换机上，路由通过接口自动生成。但为什么不通？
第二步：抓包分析——发现丢弃现象
我启用交换机的mirror端口功能，将VLAN 10和VLAN 20之间的流量镜像到我的笔记本Wireshark上。抓包显示：PC1（VLAN 10，IP 192.168.10.2）向服务器（VLAN 30，IP 192.168.30.10）发送ARP请求，但服务器无应答。奇怪的是，核心交换机应负责ARP代理，但日志中没有任何响应。
我检查了display arp all，发现ARP表项中只有同网段条目，跨网段ARP请求被丢弃。这说明核心交换机没有执行跨VLAN的ARP代理转发。问题指向ACL或端口安全配置。
第三步：ACL规则审查——罪魁祸首现身
我使用display acl all查看所有ACL规则，发现一条编号3001的ACL被应用到VLAN 10的入方向：
acl number 3001
rule 5 deny ip source 192.168.10.0 0.0.0.255 destination 192.168.30.0 0.0.0.255
rule 10 permit ip source any这条规则明确禁止了VLAN 10访问VLAN 30（服务器网段）。但客户最初的需求是限制访客VLAN（VLAN 50）访问服务器，而不是办公VLAN。显然，配置人员将ACL应用错了接口或写错了源地址。
进一步检查display traffic-policy applied-record，发现该ACL被绑定到了VLAN 10的入接口，导致办公区所有流量被拦截。我深吸一口气——这是一个典型的“配置漂移”错误。
三、修复方案：精准调整与验证
步骤1：移除错误ACL
我首先在全局配置模式下，使用undo traffic-policy inbound命令解除VLAN 10上的ACL绑定，然后删除错误的ACL条目。但注意：不要直接删除整个ACL，因为可能还有其他规则引用。我仅删除了rule 5：
acl number 3001
undo rule 5步骤2：重新配置正确的ACL并应用
我创建了一个新ACL编号3002，专门限制VLAN 50（访客）访问服务器VLAN 30：
acl number 3002
rule 5 deny ip source 192.168.50.0 0.0.0.255 destination 192.168.30.0 0.0.0.255
rule 10 permit ip source any然后，在VLAN 50的接口视图下应用入方向策略：
interface Vlanif50
traffic-policy inbound acl 3002步骤3：全网连通性测试
配置完成后，我立即用PC1（办公区）ping服务器IP，成功收到回复。接着测试财务系统、ERP和车间终端，全部恢复正常。客户激动地反馈：“所有系统都活了！”
但我没有止步：我使用display acl all再次确认所有ACL规则无误，并保存配置。同时，在核心交换机上开启日志记录，以便后续审计：
info-center enable
info-center loghost 192.168.30.10 facility local0四、经验总结与避坑指南
这次故障虽然看似简单，但暴露了中小企业IT运维中的常见问题：
- 变更管理缺失：客户未经测试就直接应用ACL到生产环境，导致全网断流。建议所有网络变更先在测试环境验证。
- 日志监控不足：如果启用了ACL日志，交换机在丢弃数据包时会生成日志，能快速定位问题。本例中客户未配置日志，只能靠抓包。
- ACL顺序陷阱：ACL规则按顺序匹配，一旦匹配即停止。本例中正确的做法是deny后紧跟permit any，但应用错误接口才是根因。
针对云南地区中小企业，我建议：
- 使用网络管理工具（如SolarWinds或Zabbix）实时监控ACL流量丢弃情况。
- 制定配置模板，避免手动输入错误。例如，访客限制ACL应标准化为“源=访客网段，目标=服务器网段”。
- 定期进行网络健康检查，使用脚本批量比对运行配置与基线配置。
最后，我提醒所有IT运维人员：ACL虽小，坑却不少。一条错误的规则就能让全网瘫痪。希望本文的实战经验能帮助你在云南的IT服务中少踩坑、多救火。