Bar*_*rim 6 cisco routing switch
问题是……我们有一个包含很多 Cisco 交换机的网络。
有人在网络上插入了一个集线器，然后我们开始看到“奇怪”的行为；客户端和服务器之间的通信错误，或网络超时、网络连接中断等。似乎该集线器（或 SOHO 交换机）以某种方式特别吓坏了我们的 Cisco 3700 系列交换机。
断开那个集线器或网络设备类型的 SOHO 交换机，事情又恢复了。
我们正在尝试为 SNMP 和管理等获得一个集中的日志服务器，看看我们是否可以在有人在我们不知情的情况下做这种事情时捕获错误或缩小范围，因为事情似乎有效，因为大多数情况下，没有问题，我们只是在特定的交换机上遇到奇怪的奇怪事件，这些事件似乎没有任何解释，直到我们发现有人决定自己解决问题以扩展他们房间中的可用端口。
没有进入程序更改或锁定端口或“在我们的组织中他们会被解雇”的答案，有人可以解释为什么添加一个小型交换机或集线器，不一定是 SOHO 路由器（即使是一个愚蠢的集线器显然也导致 3700 吓坏了） ) 将 DHCP 请求发送出去，会导致问题吗？老板说这是因为 Cisco 越来越糊涂了，因为那个流氓集线器/交换机正在将多个 MAC/IP 桥接到 Cisco 交换机的一个端口中，他们只是因此而窒息，但我认为他们的路由表应该能够处理多台机器的到来进入港口。任何人之前都看到过这种行为并对发生的事情有更清晰的解释？
我想知道未来的故障排除和更好的理解，只是挥手说“你不能”。
这是一场表演赛
当前配置：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-队列输入带宽 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-Control-Trust
匹配 ip dscp cs3 af31
！
！
策略映射 AutoQoS-Police-CiscoPhone
类 AutoQoS-VoIP-RTP-Trust
设置 dscp ef
警察 320000 8000 超出行动policed-dscp-transmit
类 AutoQoS-VoIP-Control-Trust
设置 dscp cs3
警察 32000 8000 超出行动policyd-dscp-transmit
！
！
！
！
接口千兆以太网1/0/1
switchport中继封装dot1q
交换机端口中继本地 vlan 11
交换机端口模式中继
生成树 portfast
！
！
！
接口千兆以太网5/0/1
！
接口千兆以太网5/0/2
！
接口千兆以太网5/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 ############
登录
！
结尾
Bra*_*don 11
我们运营了几个网络实施，其中第三方连接链接到集中的 Cisco 骨干网（即多租户设置）。我可以说我已经看到许多不同的（好吧，贫民窟）设备连接到 Catalyst 平台，如果我学到了一件事，那就是 Cisco 平台对这些类型的事情非常有弹性。
但是，有一个致命弱点——配置正确的廉价集线器可以轻松地通过广播风暴摧毁整个网络，这甚至不是 Cisco 平台的错。我在生产配置中发现了这一点，我所做的唯一真正的研究是为该集线器找到最近的垃圾桶，但它是如何发生的：
一切顺利，直到该工作站发出广播通知。虽然集线器和 Cisco 足够聪明，可以防止其他广播数据包上的广播风暴，但集线器不够聪明，无法检测到它的两个端口相互连接，并且几乎会耗尽其 100% 的处理能力在无限循环中来回广播该数据包，以及所有其他端口（即到您的 Cisco 的上行链路）。
如果您的配置是这种情况，您会注意到在您的网络中，该广播 VLAN 上的所有端口都将变得疯狂，直到集线器无法维持容量并丢弃神奇的循环数据包（可能是几个分钟取决于竞争流量），然后一切都恢复正常。
在这种情况下，SNMP 将无济于事，因为该 VLAN 上的所有端口都因流量而发疯。然而，Wireshark 是您的朋友，因为它很容易捕获导致循环的 IP（有时还包括机器名称，如果它是广播数据包），并快速定位有问题的设备。
可能不是您遇到的确切情况，但这对我们来说有点困难，并且可能会给您一些想法来研究您的情况。
小智 5
微不足道的点，但我还没有看到他们提到：
确保您的交换机端口没有被强制为全双工，因为如果是，它们将无法与集线器一起使用。想想看 - 如果他们的双工或他们的速度被强制，他们可能无法正确连接到想要自动协商的 Netgear 类型的交换机
确保您的用户不会将交换机连接到两个网络插座，以“使其带宽翻倍”。
思科交换机曾经（也许现在仍然如此——我现在不再从事这项业务）有一项名为“Faststart”的功能。对于启用了 Faststart 的任何端口，交换机不会进行完整的生成树分析，并且通过启用该功能，管理员“承诺”不将交换机或集线器连接到该端口。这样做的原因是为了避免客户端 PC 的 DHCP 请求在 Cisco 决定启用端口是安全的之前超时。你可能也想看看。（如果我完全记错了这一切，我提前道歉，希望有更多最新知识的人能纠正我）
| 归档时间： |
|
| 查看次数： |
6295 次 |
| 最近记录： |