问题是……我们的网络有很多思科交换机。
有人在网络上插入了一个集线器,然后我们开始看到“奇怪”的行为;客户端和服务器之间的通信出现错误,或者网络超时、网络连接断开等。似乎该集线器(或 SOHO 交换机)特别扰乱了我们的 Cisco 3700 系列交换机。
断开该集线器或 netgear 类型的 SOHO 交换机,一切又恢复正常。
我们正在尝试获取用于 SNMP 和管理等的集中式日志服务器,以查看是否可以捕获错误或缩小有人在我们不知情的情况下进行此类操作的范围,因为大多数情况下,一切似乎都正常,没有问题,我们只是在特定的交换机上遇到了一些奇怪的事件,这些事件似乎没有任何解释,直到我们发现有人决定自己动手来扩展他们房间中的可用端口。
无需讨论程序更改或锁定端口或“在我们的组织中他们会被解雇”之类的答案,有人能解释一下为什么添加小型交换机或集线器(不一定是 SOHO 路由器,即使是愚蠢的集线器也显然会导致 3700 崩溃)发送 DHCP 请求会导致问题吗?老板说这是因为思科感到困惑,因为流氓集线器/交换机将多个 MAC/IP 桥接到思科交换机的一个端口上,他们只是因此而受阻,但我认为他们的路由表应该能够处理进入端口的多台机器。有人以前见过这种行为,并且对发生的事情有更清晰的解释吗?
我希望知道,以便将来进行故障排除并更好地理解,而不是挥挥手说“你不能”。
以下是演出内容
当前配置:25591 字节
!
版本 12.2
无服务台
服务时间戳调试日期时间毫秒
服务时间戳日志日期时间毫秒
服务密码加密
!
主机名 ###########
!
开机启动标记
引导结束标记
!
启用秘密 5 ############
!
!
!
没有 aaa 新款
交换机 1 配置 ws-c3750g-24ps
交换机 2 配置 ws-c3750-48ts
交换机 3 配置 ws-c3750-48ts
交换机 4 配置 ws-c3750-48ts
交换机 5 配置 ws-c3750-48ts
系统 mtu 路由 1500
身份验证 mac-move 许可证
ip 子网零
IP 路由
!
!
!
mls qos 映射 policed-dscp 24 26 46 至 0
mls qos 映射 cos-dscp 0 8 16 24 32 46 48 56
mls qos srr-queue 输入带宽 90 10
mls qos srr 队列输入阈值 1 8 16
mls qos srr 队列输入阈值 2 34 66
mls qos srr-queue 输入缓冲区 67 33
mls qos srr-queue 输入 cos-map 队列 1 阈值 2 1
mls qos srr-queue 输入 cos-map 队列 1 阈值 3 0
mls qos srr-queue 输入 cos-map 队列 2 阈值 1 2
mls qos srr-queue 输入 cos-map 队列 2 阈值 2 4 6 7
mls qos srr-queue 输入 cos-map 队列 2 阈值 3 3 5
mls qos srr-queue 输入 dscp-map 队列 1 阈值 2 9 10 11 12 13 14 15
mls qos srr-queue 输入 dscp-map 队列 1 阈值 3 0 1 2 3 4 5 6 7
mls qos srr-queue 输入 dscp-map 队列 1 阈值 3 32
mls qos srr-queue 输入 dscp-map 队列 2 阈值 1 16 17 18 19 20 21 22 23
mls qos srr-queue 输入 dscp-map 队列 2 阈值 2 33 34 35 36 37 38 39 48
mls qos srr-queue 输入 dscp-map 队列 2 阈值 2 49 50 51 52 53 54 55 56
mls qos srr-queue 输入 dscp-map 队列 2 阈值 2 57 58 59 60 61 62 63
mls qos srr-queue 输入 dscp-map 队列 2 阈值 3 24 25 26 27 28 29 30 31
mls qos srr-queue 输入 dscp-map 队列 2 阈值 3 40 41 42 43 44 45 46 47
mls qos srr-queue 输出 cos-map 队列 1 阈值 3 5
mls qos srr-queue 输出 cos-map 队列 2 阈值 3 3 6 7
mls qos srr-queue 输出 cos-map 队列 3 阈值 3 2 4
mls qos srr-queue 输出 cos-map 队列 4 阈值 2 1
mls qos srr-queue 输出 cos-map 队列 4 阈值 3 0
mls qos srr-queue 输出 dscp-map 队列 1 阈值 3 40 41 42 43 44 45 46 47
mls qos srr-queue 输出 dscp-map 队列 2 阈值 3 24 25 26 27 28 29 30 31
mls qos srr-queue 输出 dscp-map 队列 2 阈值 3 48 49 50 51 52 53 54 55
mls qos srr-queue 输出 dscp-map 队列 2 阈值 3 56 57 58 59 60 61 62 63
mls qos srr-queue 输出 dscp-map 队列 3 阈值 3 16 17 18 19 20 21 22 23
mls qos srr-queue 输出 dscp-map 队列 3 阈值 3 32 33 34 35 36 37 38 39
mls qos srr-queue 输出 dscp-map 队列 4 阈值 1 8
mls qos srr-queue 输出 dscp-map 队列 4 阈值 2 9 10 11 12 13 14 15
mls qos srr-queue 输出 dscp-map 队列 4 阈值 3 0 1 2 3 4 5 6 7
mls qos 队列设置输出 1 阈值 1 138 138 92 138
mls qos 队列设置输出 1 阈值 2 138 138 92 400
mls qos 队列设置输出 1 阈值 3 36 77 100 318
mls qos 队列设置输出 1 阈值 4 20 50 67 400
mls qos 队列设置输出 2 阈值 1 149 149 100 149
mls qos 队列设置输出 2 阈值 2 118 118 100 235
mls qos 队列设置输出 2 阈值 3 41 68 100 272
mls qos 队列设置输出 2 阈值 4 42 72 100 242
mls qos 队列设置输出 1 缓冲区 10 10 26 54
mls qos 队列设置输出 2 个缓冲区 16 6 17 61
服务质量
!
!
!
!
!
生成树模式 pvst
生成树以太通道防护配置错误
生成树扩展系统 ID
!
vlan 内部分配策略升序
!
!
类映射匹配所有AutoQoS-VoIP-RTP-Trust
匹配 ip dscp ef
类映射匹配所有AutoQoS-VoIP-控制-信任
匹配 ip dscp cs3 af31
!
!
策略图AutoQoS-Police-CiscoPhone
类 AutoQoS-VoIP-RTP-Trust
设置 dscp ef
警察 320000 8000 超出行动管制-dscp-传输
类 AutoQoS-VoIP-Control-Trust
设置 dscp cs3
警察 32000 8000 超出行动管制-dscp-传输
!
!
!
!
接口GigabitEthernet1/0/1
交换机端口中继封装 dot1q
交换机端口中继本机 VLAN 11
交换机端口模式中继
生成树快速端口
!
!
!
接口GigabitEthernet5/0/1
!
接口GigabitEthernet5/0/2
!
接口GigabitEthernet5/0/3
!
接口千兆以太网5/0/4
!
接口 Vlan1
IP 地址 ############## 255.255.0.0
!
无类别 IP
IP 路由 0.0.0.0 0.0.0.0 ##############
没有 IP http 服务器
没有 ip http 安全服务器
!
!
ip sla 启用反应警报
!
!
!
线路连接 0
线路 vty 0 4
密码 7 ############
登录
线路 vty 5 15
密码 7 ############
登录
!
结尾
答案1
我们运营着几个网络实施,其中第三方连接链接到集中式 Cisco 主干网(即多租户设置)。我可以说,我见过大量不同的(好吧,贫民窟)设备连接到 Catalyst 平台,如果说我学到了什么,那就是 Cisco 平台对这类事情具有极强的弹性。
不过,有一个致命弱点——一个廉价的轮毂在正确的配置下可能会容易地广播风暴会破坏整个网络,这甚至不是思科平台的错。我在生产配置中发现了这一点,我所做的唯一真正的研究就是找到离该集线器最近的垃圾箱,但事情是这样发生的:
- 使用上行链路端口将集线器正常连接到思科交换机
- 将工作站连接到集线器端口(在我们的例子中,运行 Windows XP 操作系统,但没关系)
- 将集线器上的另外两个端口连接在一起(可以使用单个 CAT5 直接连接,也可以通过另一个集线器间接连接)。
一切顺利直到该工作站发出广播公告。虽然集线器和 Cisco 足够智能,可以防止其他广播数据包上的广播风暴,但集线器不够智能,无法检测到其两个端口相互连接,并且将使用几乎 100% 的处理能力来无限循环地来回广播该数据包,以及所有其他端口(即到 Cisco 的上行链路)。
如果您的配置是这种情况,您会注意到,在整个网络中,该广播 VLAN 上的所有端口都会变得疯狂,直到集线器无法维持容量并丢弃神奇的循环数据包(可能需要几分钟,具体取决于竞争流量),然后一切恢复正常。
在这种情况下,SNMP 不会帮助你,因为全部该 VLAN 上的端口会因流量过大而变得异常繁忙。不过,Wireshark 可以帮您解决这个问题,因为它可以轻松捕获导致循环的 IP(如果是广播数据包,有时还可以捕获机器名称),并快速找到有问题的设备。
这可能不是您所遇到的确切情况,但这个情况对我们影响很大,可能会给您提供一些研究您情况的想法。
答案2
一些琐碎的观点,但我还没有看到有人提及:
确保交换机端口未强制设置为全双工,因为如果强制设置为全双工,它们将无法与集线器配合使用。仔细想想,如果强制设置为全双工或全双工,它们很可能无法正确连接到需要自动协商的 Netgear 型交换机
确保您的用户不会将交换机连接到两个网络插座“以增加其带宽”。
Cisco 交换机曾经(现在可能仍然有 - 我现在已经不做这个行业了)有一项名为“Faststart”的功能。对于启用了 Faststart 的任何端口,交换机都不会进行完整的生成树分析,通过启用该功能,管理员“承诺”不会将交换机或集线器连接到该端口。这样做的原因是为了避免在 Cisco 决定可以安全启用该端口之前客户端 PC 的 DHCP 请求超时。您可能也想看看这一点。(如果我完全记错了,我提前道歉,希望有更了解最新情况的人能纠正我)
答案3
如果您在端口上使用端口安全性,那么只要给定端口上的 MAC 数量超过预期,就会出现问题。将集线器插入交换网络的主要问题是,最终会得到更大的冲突域(而不是“交换机 + 终端单元”,最终会得到“交换机 + 集线器上的所有下游设备”),可能会导致交换环路(如果集线器连接到两个交换机),并且最终可能会得到一个足够大的网络,以至于广播域“太宽”(LAN 绝对需要足够小,以便从一个极端到另一个极端的数据包可以在以太网前导码中看到;由于集线器往往更不擅长让数据包快速通过(更便宜),最终可能会违反这一点)。
如果您有一个较大的冲突域,则任何尝试与该冲突域通信的内容最终都会具有较低的吞吐量。
如果有交换环路,则可能会出现广播风暴,并且由于生成树关闭了转发端口,端口可能会随机不转发流量。
如果您的广播域太宽,那么由于发生延迟冲突,最终会导致虚假重新传输。
答案4
我在非 Cisco 环境中遇到过这种情况。将集线器插入网络端口,然后有三台计算机连接到该端口。一位用户,没有问题。当其他人开始使用时,它开始切断与终端服务器的 RDP 连接。拔出集线器,问题就解决了。