看起来你的核心网络通路是正常的（普通电脑不管用光纤还是以太网都能正常DHCP上网），但特定的小设备卡在了交换机这一关，我来给你梳理几个排查方向，你可以一步步尝试：

• 检查交换机端口的速率协商模式：很多IoT设备、无线AP或者电视棒这类设备，硬件上只支持10/100Mbps的速率，甚至部分老设备对自动协商的兼容性很差。你的10G SFP交换机默认可能把端口设成了强制1G/10G模式，或者自动协商的范围没包含低速率。你可以登录交换机的Web管理界面或者CLI，找到连接Cudy AP和Fire Stick的端口，把协商模式改成自适应（Auto-Negotiation），如果还是不行，试试手动指定为100Mbps全双工模式，大概率能解决兼容性问题。

• 排查VLAN配置问题：你的管理型交换机有没有划分过VLAN？如果普通电脑所在的VLAN和这两个设备的端口VLAN不一致，而且对应VLAN没配置DHCP中继（IP Helper），那DHCP请求就没法传到Cisco 4331路由器。你需要确认这两个设备的端口和正常电脑的端口处于同一个原生VLAN（Native VLAN）；如果确实用了多VLAN，要保证对应VLAN已经配置了指向路由器DHCP服务器地址的IP Helper规则。

• 检查DHCP Snooping和端口安全设置：管理型交换机很可能开启了DHCP Snooping功能来防止恶意DHCP服务器，但如果没把路由器连接的端口设为信任端口，交换机就会拦截其他端口发出的DHCP请求。另外，端口安全如果限制了MAC地址数量，也会导致新设备无法接入。你可以先临时关闭这两个功能，测试设备能不能正常获取IP，如果能的话，再重新配置信任端口和MAC地址规则。

• 验证链路硬件兼容性：虽然你用了和电脑一样的配置，但可能存在SFP模块或网线的兼容性问题——比如Cudy AP的WAN口是以太网口，你用的SFP转电口模块是不是和交换机不兼容？试试换一个SFP模块、换一根网线，或者把设备换到交换机上其他空闲端口，排除硬件或链路层面的故障。

• 排查ACL或QoS过滤规则：有没有可能交换机配置了ACL（访问控制列表）或者QoS策略，不小心把DHCP报文（UDP 67/68端口）给拦截了？你可以进入交换机的配置界面，检查有没有针对UDP 67/68端口的过滤规则，或者QoS里是否把DHCP报文的优先级设得过低导致丢包。

备注：内容来源于stack exchange，提问作者Allie