您使用的平台基本上是一个错误软件,似乎这个转换是由一些实习生在第一次进行一些真正的(不是“无限金钱的 CVD”)网络之前进行的。
在核心部署的情况下,整个 DHCP 侦听基本上没有用 - 绑定数据库限制为 2000 个条目并且无法禁用构建它(数据库是 DAI 或 DHCPRELEASE 保护所必需的,但可以是可选的,并且仍然可以防止恶意 DHCP 服务器) .
您正在寻找的旋钮只是丢失了。就像 MAC ACL(原文如此!)...请注意,即使使用 TCAM 雕刻的 ARP ACL...它们也只能匹配any
MAC 地址(只能在 ARP 数据包中进行 IP 过滤)。至少你可以使用port-security
feature
和选择一些接口......直到你达到 8000 个条目的限制。
无论如何,即使使用 DHCP 侦听,也没有被阻止的流氓服务器的日志(即使使用logging level dhcp_snoop 7
),这使得该功能仅有效地使用了一些语法糖。
建议的解决方法:使用普通 ACL 过滤恶意 DHCP 服务器。
所有这些都使该交换机成为非核心解决方案。不幸的是,由于硬 QoS 设置(CoS 与 ToS/DSCP 映射及其各自的信任状态)、缺少 MAC 过滤和环路保护,它在访问边界方面也不太擅长。不是 *STP 的东西,而是真正的恶意(以及所有其他 BPDU 过滤的)循环。只有mac address-table loop-detect port-down
开/关开关,没有每端口配置(可信,优先!),也没有 MAC 移动阈值配置。也没有流量分段(祝私有 VLAN 好运)也没有 VLAN 转换(仅适用于 ...VXLAN)。
还请记住,该交换机的 CPU 会从网络获取所有 ARP 数据包。而“全部”我的意思正是这个——单播、桥接数据,应该保留在数据平面中,被投射到控制平面,天知道为什么。您可以在 tcpdump fromrun bash
或直接通过ethanalyzer local interface inband
... 或 by观看它们show policy-map interface control-plane class copp-s-arp
。没错,整个网络中 200 pps 的 ARP(CoPP 最大约为 6700 pps)使您的交换机在任何桥接的 VLAN(而不是交换机上的 L3 终止)中的某些 ARP 风暴期间在其带内管理接口上不可用。除非您制定单独的 CoPP 规则(有 4 个可用插槽,万岁!)来处理真正发往 CPU 的 ARP,这似乎是内核中 n3k 的另一个必备条件。
更新:关于 DHCP 侦听操作,还有一件更重要的事情需要了解。与阻止不受信任的响应(即 OFFER、ACK、NAK)的其他设备相反,该交换机显然不会将客户端请求(DISCOVER、REQUEST)转发到不受信任的端口,因此流氓服务器没有什么可回复的。尽管这看起来很聪明,但也有后果。首先,上面提到 - 没有此类服务器的日志。其次 - 任何连接错误的设备的所有者都不会看到太多设备请求地址和最终资源匮乏。这是使用普通 ACL 阻止有问题的 DHCP 的下一个原因 - 在全局阻止 DHCP 之前,可以附加一些诊断框并将所有内容传递给它。这对于客户端终止于哑交换机的网络尤其重要,在那里 DHCP 侦听不会