你遇到的情况很典型，根本原因通常不在于端口认证模式，而在于 Guest VLAN（访客VLAN） 或类似的认证绕过机制被错误地启用了。

display mac-address 中 AUTH 状态的MAC地址，正是那些未通过认证、但因配置策略获得了有限网络权限的终端。

🔍 问题原因

你看到的“只有一个是dot1x，剩下的是AUTH”是正常的。基于MAC的认证（macbased）模式下，每个终端都需要独立认证。已认证的显示为 dot1x，未认证的显示为 AUTH。

问题的关键在于，为什么 AUTH 状态的终端能上网？这通常是由以下配置导致的：

• Guest VLAN（访客VLAN）：这是最常见的原因。当端口配置了 dot1x guest-vlan，未认证的终端会被自动划入这个访客VLAN。如果该VLAN被允许访问外网或关键内网资源，就会出现“不用认证也能上网”的现象。

• MAC地址认证绕过（MAC Authentication Bypass, MAB）：配置了 dot1x mac-auth-bypass 或类似命令后，交换机可能允许特定MAC地址的终端免认证接入。

• Free IP（免认证IP）：如果配置了 dot1x free-ip，指定IP网段内的终端可能无需认证即可访问网络。

🛠️ 解决方案

请按以下步骤操作：

1. 确认当前认证模式
   执行命令确认端口工作模式是 macbased：

   bash

   display dot1x interface GigabitEthernet 1/0/X

   查看 Port access method 字段。如果显示为 portbased，请用以下命令修改：

   bash

   system-view interface GigabitEthernet 1/0/X dot1x port-method macbased quit

2. 排查并处理Guest VLAN（最关键）
   检查端口下是否存在Guest VLAN配置：

   bash

   display current-configuration interface GigabitEthernet 1/0/X | include guest-vlan

   • 如果存在：说明这就是“免认证上网”的原因。

   • 处理方式：

     • 方案一（推荐）：直接删除Guest VLAN。

       bash

       system-view interface GigabitEthernet 1/0/X undo dot1x guest-vlan quit

     • 方案二（如业务需要）：如果必须保留Guest VLAN，请严格限制其访问权限，确保它只能访问认证服务器，不能访问外网或其他业务网段。

3. 排查其他认证绕过配置
   检查是否存在MAC地址免认证或Free IP配置：

   bash

   display dot1x mac-user all display current-configuration | include free-ip

   如果存在，根据实际需求决定是否删除。

交换机端口下 Hub 多终端 802.1X‑macbased 问题分析

现象：端口下接 Hub，多台 PC 接入；已经配置dot1x port‑method macbased（默认就是该模式）。display mac‑address int G1/0/X看到：1 个 MAC 状态是 dot1x，其余 MAC 状态为 AUTH；部分 PC 不用认证就可以上网H3C。

名词解释

• dot1x标记：该 MAC 完成 802.1X EAP 认证，生成 dot1x 会话。
• AUTH标记：该 MAC 没有 802.1X 会话，只是端口二层学习到的普通 MAC 表项，没有经过 802.1X 授权。

⚠️macbased≠自动拦截未认证终端；macbased 只是支持一个端口多个用户独立认证，不等于端口会直接阻断未认证 MAC 报文。

根本原因（3 个高频根因，按概率排序）

根因 1：端口开启了port‑security（端口安全），最大安全 MAC 数大于 1

端口安全允许学习多个静态 / 动态安全 MAC。当第一个终端 802.1X 认证成功，该 MAC 加入安全 MAC 表；Hub 下其他终端的 MAC 被 port‑security 动态学习为安全 MAC，直接放行流量，跳过 802.1X 认证。

表现：其余 MAC 显示 AUTH，不需要 iNode 就直接上网。

如果看到max‑mac‑count >1，就是这个问题。port‑security 动态学习会把 Hub 下面其他终端 MAC 直接放通，绕过 dot1x 校验。

根因 2：混淆「macbased」和「端口安全 need‑to‑know（NTK）」

dot1x port‑method macbased：只是允许多个用户独立做 802.1X 认证，本身不做二层隔离。

NTK（need‑to‑know）功能才是：未通过认证的 MAC，二层报文直接丢弃。 默认 NTK 没有开启，Hub 下其他终端报文在二层可以正常转发，MAC 表显示 AUTH，没有 dot1x 会话，直接上网。

重要区分：

1. dot1x port‑method macbased：允许多个用户分别发起 802.1X；不会自动拦截不发起 EAPOL 的终端。
2. port‑security ntkonly：开启 NTK，只有已经认证成功的 MAC 允许转发，其他全部丢弃，Hub 场景必须配置该命令，否则未认证终端直接通行。

根因 3：混合认证模式、MAB/MAC‑authentication 干扰

端口同时存在mac‑authentication，或者 port‑security 混合认证模式，部分终端触发 MAC 旁路认证直接上线，没有走 802.1X‑dot1x 会话，MAC 表显示 AUTH。

排查命令

正确状态：Hub 下所有 PC，全部要出现在display dot1x connection会话列表；如果只 1 条会话，其他终端不在此输出，说明没有经过 802.1X 认证就放行了。

正确 Hub 下多终端 802.1X (macbased) 完整配置

需求：Hub 下每一台 PC 都必须 iNode 做 802.1X 认证；未认证终端二层报文直接丢弃，不能直接上网。

port‑security ntkonly 是解决 “未认证终端直接上网” 最核心命令，只靠 macbased 做不到阻断未认证终端H3C。

现象解释：为什么 display mac‑address 看到 AUTH

1. PC1 iNode 认证成功：生成dot1x会话，MAC 表标记dot1x。
2. PC2 没有运行 iNode，不发送 EAPOL 报文。

• 没有配置 ntkonly：交换机学习到 PC2 的源 MAC，MAC 表标记AUTH，二层直接转发，PC2 直接上网，没有 802.1X 会话。
• 配置 ntkonly：交换机收到 PC2 报文，MAC 学习到 AUTH 标记，但 NTK 校验不通过，报文直接丢弃，PC2 不能上网。

常见误区总结

1. ❌误区：dot1x port‑method macbased开启，端口就会拦截没有做 802.1X 的终端。

纠正：macbased 只是支持多用户分别认证；不会拦截不发起 EAPOL 报文的终端，必须搭配 port‑security ntkonly 实现二层阻断。

2. ❌port‑security max‑mac‑count 设置过大，动态学习 Hub 下终端 MAC，绕过 802.1X 直接放行。
3. ❌Hub 场景不用 NTK，二层报文裸转发，未认证终端直接通行。
4. ✅display dot1x connection才是真正 802.1X 上线用户；不要只看 display mac‑address，MAC 表 AUTH 不等于已经准入认证。

验证：配置 ntkonly 之后，Hub 下没有 iNode 的 PC，获取不到 IP，无法访问网络；运行 iNode 认证成功后，display dot1x connection可以看到该 MAC 会话，MAC 表标记 dot1x。