对于 nexus3048交换机,在使用过程中,如果通过 SNMP 监控,或者命令行show interface 查看,可能发现接口的 input discard持续增长;假设此时网络数据传输有问题,那么是否是 input discard 导致?这篇文章主要是讲解如何排除干扰项,逐步定位 input discard,并且消除此问题。
LAB 测试环境:
N3K e1/1 -------- e1/5 N9363, 两台 nexus 设备之间通过 trunk link 互连。
LAB 测试步骤:
N9396 配置 SVI 10, SVI 11, 在 N3K 只配置SVI 10;N9K 和 N3K 的 trunk allow VLAN all. 测试开始之前,需要在 N3K clear counter, 将 counter 归零。之后,使用 N9K SVI 11 ping 同网段任意地址,由于 N9K 无法完成dst ip 的 ARP 解析,因此会在 VLAN 11 泛洪/flood 此 ping 报文,通过 trunk,ping 包会到达 N3K,最终丢弃。
LAB 设备 N3K 的表现与输出:
按照正常逻辑,N3K 将 N9K SVI11 的 ping/ARP request 丢弃,过程中并不会产生任何接口相关的 error counter 增长。但是在 N3K 早期版本,n3k 接口 counter 统计会将以上 LAB 测试中,VLAN mismatch 产生的丢包,显示性的记录在接口的 input discard,此行为会对用户造成一定的干扰和误导。
解决方案:
从测试过程和结果去看,这种行为必须合理的规避,以避免对正常网络运维、监控产生的影响。有两种方案可以选择,第一种是在 N3K 与 N9K 中间互连的 trunk link,只放行两端同时存在的 VLAN,在这个 LAB, 配置为 switchport trunk allowed vlan 10. 配置对应的命令以后,VLAN-STP mismatch 而产生的报文,不会 flood 到 N3K, 也就不会被N3K 错误的记录 counter。假设客户的网络中有很多类似的 trunk link 的配置需要优化,此过程需要较长时间并且有潜在配置错误的风险,那么可以采用第二种方式,是参照CSCuo57455, 对 N3K 进行版本升级,6.0(2)U4(1) 以及 6.0(2)A4(1) 或者之后的 nx-os 版本,已经修复此问题。
结论:
N3K input discard 并不一定代表网络中存在丢包,有可能是 VLAN-STP mismatch 导致的本不应该出现的 counter 增长,建议先按照本文的方式排查,如果 match bug,可以使用以上两种方案之一来解决。