對於 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 的 ping 丟棄，過程中並不會產生任何接口相關的 error counter 增長。但是在 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 增長，建議使用以上兩種方案之一來解決。