华为交换机ETH-TRUNK的自协商陷阱

大清早，远郊3个机房覆盖的用户反映上网异常。

这三个机房都是EPON+EOC的方式覆盖，PPPOE拨号无法拨通。机房汇聚交换机和OLT设备都能正常登陆，因此怀疑是OLT的PON板硬件故障。

大雨的天，走高架，一片白茫茫，只有眼前不远的车和路依稀可见。开了快一个钟头到了机房，挂ONU，测拨号，能走到账号密码验证这一步。用pppoe-discovery能看到Bras服务器，说明二层链路到Bras是能走通的。

没准是Bras问题，于是让人在中心机房同一个Vlan测PPPOE拨号。意外的是，竟然中心机房这个Vlan下上网是正常的，

看来还是本地网络问题，于是请坐镇中心的大师兄出手，发现JS到TQ的9306交换机之间，ETH-Trunk链路的两个Gige口中，有一个是Down的。

Eth-Trunk本来就是为了做链路备份，断一个口应该能工作，况且这条链路上的设备都能正常登陆。不过现在故障仍在，也只查到这么一个bug，只好试试看了。于是拔了这一路的纤，再拨号，居然好了。

于是开始分析，eth-trunk为何没起保护作用。看收发光，掀地板，摸尾纤，发现ETH-TRUNK中一个Gige口的两根尾纤，被老鼠咬断了一根。于是这对尾纤的一端，Gige口能收到光，另一端收不到光，于是两边设备产生了分歧，一边以为链路是通的，另一边以为是断的。于是出现了上述怪异故障，设备能登陆，拨号却不通。

auto-negotiation导致的问题。

---

后记

2016年底，又出了类似的问题，这次折腾了更久。

华为9306交换机和华为MA5800 OLT 同样问题，表现极其像路由问题，浪费了好久时间在查路由上。