MAC地址过滤仅在二层设备（接入交换机端口、无线AP、NAC设备）有效，三层设备或家用路由器无法实现；思科交换机需按顺序启用port-security、设置白名单、限制数量及违规动作为restrict；Linux需用ebtables在bridge模式下配置；NAC对接须确保RADIUS授权属性、端口标识与优先级策略完整对齐。
MAC地址过滤必须在二层设备上做，三层设备或防火墙基本无效
纯靠路由器或linux iptables 拦mac是典型误区——ip层根本看不到原始mac，它早被交换机或网关剥离了。真正起作用的位置只有：接入交换机端口、无线ap的客户端控制、或者专用nac设备（如cisco ise、aruba clearpass）的准入策略。如果你手头是家用路由器，基本没戏；企业环境里，得确认你的交换机支持port-security或mac-access-list这类特性。
思科交换机启用端口级MAC白名单的实操要点
这是最常见且落地性强的方案，但容易因配置顺序或老化时间翻车：
- 必须先开
switchport port-security，再设switchport port-security mac-address <mac>，反着来会报错 -
switchport port-security maximum 1要显式指定，否则默认允许1个动态MAC，但不锁死——别人插线后可能顶掉原设备 - 务必加
switchport port-security violation restrict（不是shutdown），否则首次违规就断口，运维没法调试 - MAC地址格式必须全小写、无分隔符：
aabbcc112233，写成AA:BB:CC:11:22:33会被拒绝 - 注意
aging time：设太短（如1分钟）会导致合法设备因休眠短暂掉线后无法重连
Linux主机上用ebtables做MAC过滤的适用边界
仅适用于该主机作为网关/桥接点（比如OpenWrt软路由、KVM宿主机），且必须工作在bridge模式下：
-
ebtables -A FORWARD -s ! aabbcc112233 -j DROP是核心规则，-s匹配源MAC，!取反 - 必须确保
br_netfilter模块已加载，否则bridge链不生效 - 和
iptables共存时，ebtables在二层，iptables在三层，不要指望一条iptables规则能拦住MAC - 性能敏感场景慎用：每包都要查MAC表，万兆口+高并发下CPU占用明显上升
NAC设备对接时，RADIUS认证与MAC绑定的常见断点
很多团队以为配完MAC白名单就万事大吉，结果发现设备能连WiFi但上不了网——问题往往卡在授权属性下发环节：
- Cisco ISE中，必须在Result > Authorization Policy里勾选
CoA Reauth并设置Session-Timeout，否则终端MAC变更后不会主动踢下线 - Aruba ClearPass的
Enforcement Profile里，若只填MAC Authentication不勾Apply to all traffic，部分UDP流量（如DHCP续租）会绕过检查 - Radius
Called-Station-ID字段必须携带AP或交换机的端口信息，否则NAC无法定位到具体物理接口，MAC绑定失去意义 - 802.1X和MAC认证混用时，优先级配置错误会导致MAC认证永远不触发——查
authentication order和authentication priority
真正难的不是加一条MAC，而是确保从物理端口→接入设备→NAC策略→下发动作整个链路都严格对齐。少一个环节，过滤就形同虚设。
