VTP冲突的排查与解决

* 案例名称：

《 VTP 冲突的排查与解决》

 

* 技术范围：

      交换

 

技术关键词：

VTP

 

* 案例描述：

用户新建一个厂房，600多个信息点通过楼层交换机接入新机房核心设备Cisco 6509。同时，新厂房的网络通过Cisco 6509与原有网络的核心Cisco 4507R级联实现互连互通。整个网络的核心是Cisco 4507R，因为用户的服务器和Internet出口都在原有机房内。

 

原本，这是个并不复杂的网络构建项目。只需通过光纤将新厂房各楼层接入交换机级联到Cisco 6509，然后6509再通过光纤接入4507R，网络的搭建就算完成了。之前的楼层交换机接入没有遇到什么问题，但在6509接入4507R后，遇到了一个非常奇怪的问题。每隔大约20分钟时间，4507R就会处于“假死机”状态，之所以称之为“假死机”是因为它并没有完全不能访问，telnet连接正常，也能用show命令查看端口状态，STP状态等；但show running-configure后光标就停了不动，没有信息显示；更要命的是DHCP无法获取地址，PC和IP电话无法使用。

 

解决思路：

 

    首先想到的是重启，4507R配备了双引擎冗余。重启之后，4507R自动切换到了slot 2＃的backup引擎。于是，很自然的怀疑可能主引擎卡坏了。用强制引擎切换的命令redundancy force-switchover来加以验证，结果出人意料，成功切换到了主引擎，与6509的连接正常（当时用ping在不间断测试）且DHCP也正常。不过，将近20分钟后出现了相同的故障，4507R再次“假死”。将4507R和6509之间的光纤链路断开，再测试4507R是否会出现同样的问题。过了将近40分钟，没有问题，故大致判定问题应该出在6509那边。据此，得出问题应该不是出在引擎身上。

 

排除了引擎的可能性，接下来想到的是查看设备日志，希望借此找到一些蛛丝马迹。用show logging命令查看，但只看到冗余引擎之间同步的一些日志，并没有我想要的报错或警告信息，这条路很快就走不通了。

 

一下子没了方向，不知道接下来该排查什么地方。强迫自己冷静下来（在排错的过程中，最忌讳的也是最容易犯的毛病就是急躁，一两次尝试失败以后，就开始变得着急起来，但这个时候最重要的就是冷静，盲目的尝试往往会南辕北辙，弄巧成拙），仔细想了想4507R与6509之间相互有联系的一些东西，于是想到了VTP。

原有网络中启用了VTP，4507R是VTP server，其余设成了VTP client。而在新建网络中，用户也启用了VTP，但设成了VTP transparent模式。当时，听用户描述时，我并没有觉得会有什么问题。但光听显然是不够的，每次听用户描述网络时，听得最多的就是网络应该没什么问题，配置都是正确的。

 

在4507R上，用show vtp status命令查看，没看出什么问题，用show vtp counters命令，发现居然收到了来自其他设备的VTP configuration version通告。正常情况下，4507R作为网络中唯一的VTP server，应该只有它才会发送VTP configuration version通告，用于通知其他client进行更新vlan信息。看到这里，基本上已经能够确定网络中肯定有其他的VTP server存在，而且是同一个域的，从而产生了冲突，导致vlan信息混乱和丢失。为了确信自己的猜测，在4507R上用show vlan命令查看一下VLAN信息。果然，vlan信息显示不全，DHCP server所在的VLAN丢失，这就是为什么PCs和IP 电话无法获取IP的根本原因了。

 

确定了故障的原因后，一切就变得简单很多。那个冲突的VTP server肯定在新厂网络中，于是到每台交换机上检查，最终在四台楼层交换机上找到了重复的VTP server，差点吐血，居然都和4507R上的配置一模一样！之前配置的工程师肯定是把4507R的相关配置copy过来后忘了改了，由于他的粗心，牺牲了我们一个晚上。

 

在把这四台交换机的VTP改成transparent模式后，恢复6509与4507R的连接，再次测试，过了1个小时，一切正常。就此判定问题就是出在VTP冲突，解决后就OK了。

 

    关键技术：

 

   VTP协议

   VLAN 中继协议（VTP）是思科第2层信息传送协议，主要控制网络范围内 VLANs 的添加、删除和重命名。VTP 减少了交换网络中的管理事务。当用户要为 VTP 服务器配置新 VLAN 时，可以通过域内所有交换机分配 VLAN，这样可以避免到处配置相同的 VLAN。VTP 是思科私有协议，它支持大多数的 Cisco Catalyst 系列产品。　

 

    备注：

 

    很多时候，网络工程师在做一些设备配置时，喜欢参考以前的配置甚至完全copy过来。写这篇文章的目的是想告诉有这种习惯的朋友，参考特别是copy一定要建立在对命令完全理解的基础上，很多网络问题都是由于配置不当产生的，而往往这种故障，最容易被忽视而不易排除。

本文出自 “自#己@自$在~” 博客，谢绝转载！