故障排除
从上面可以看出：该端口不能强制进行IEEE 802.1Q的Trunk设置，其他接口情况都一样。此时想到超级引擎SUP720模块上还有一个接口没有用，看它能不能进行强制封帧。进入该端口的Trunk配置，看到如下信息。
6509#conf t Enter configuration commands, one per line. End with CNTL/Z. 6509(config)#interface gigabitEthernet 5/2 6509(config-if)#switchport trunk ? allowed Set allowed VLAN characteristics when interface is in trunking mode encapsulation Set trunking encapsulation when interface is in trunking mode native Set trunking native characteristics when interface is in t runking mode pruning Set pruning VLAN characteristics when interface is in trunking mode |
下画线标示出的比在gigabitEthernet 3/48接口上看到的多了一个encapsulation选项，由此可见，在超级引擎模块的接口上可以强制进行IEEE 802.1Q的Trunk设置。
输入如下命令：
6509(config-if)#switchport trunk encapsulation ？得到： dot1q Interface uses only 802.1q trunking encapsulation when trunking isl Interface uses only ISL trunking encapsulation when trunking negotiate Device will negotiate trunking encapsulation with peer on interface 继续： 6509(config-if)#switchport trunk encapsulation dot1q 回车； 6509(config-if)#end 6509#write Building configuration... [OK] |
*注：该6509所用的IOS版本是Version 12.2（17a）SX。
我们将跳线接到该接口上，再来测试网络，原来的问题已不复存在。这两个VLAN内的用户访问网页恢复正常，带有附件的邮件又可以轻松发送了。
经验总结
由于Cisco的6509 核心交换机上48口的快速交换电模块是默认对干线进行IEEE 802.1Q封帧的，而我们的安奈特网管交换机强制对干线进行IEEE 802.1Q封帧，这是两个厂家的产品，因此可能会导致数据包传输进行协议的协商时不能很好匹配的情况。
此时我们又想到，在出现这个问题之前很长一段时间，我们的网络都是正常的，而当时我们的做法是：一开始只有收发器接在6509 超级引擎SUP720模块gigabitEthernet 5/2口上，我们在此接口上进行了强制IEEE 802.1Q封帧，后来由于48口的快速交换电模块有空余接口，我们就将其改在了gigabitEthernet 3/48口上，使用了默认IEEE 802.1Q封帧，但网络使用一直正常。这次我们对网络进行了一些调整，重新启动了一次我们的核心交换机，结果就出现了这个问题。这说明如果先将超级引擎强制进行IEEE 802.1Q的Trunk设置，待网络稳定后，再将跳线接回gigabitEthernet 3/48接口，此时Cisco 6509 将使用默认的IEEE 802.1Q封帧，同安奈特进行干线协议的协商，这样数据包在传输时进行协议的协商就不会出现问题，VLAN6和VLAN7就可以正常上网。我们后来又这样试验了一下，事实证明确实如此。
；QQ联络：1360095750。