交换机DHCP中继配置：SVI与三层口的接口类型选择与实操

1. 项目概述：SW转发与接口类型DHCP配置到底在解决什么问题？

“SW转发与接口类型DHCP配置”这个标题乍看像一串技术术语堆砌，但背后其实直指一个每天都在真实网络环境中高频发生、却常被新手忽略甚至误配的核心场景：当一台交换机（Switch）不再只是透明地转发二层帧，而是需要主动参与IP地址分发流程时，它该如何在不同接口角色下正确承担DHCP中继（DHCP Relay）或DHCP服务器（DHCP Server）功能？这不是理论考题，而是某高校实验室改造无线覆盖、某中小型企业部署新办公网、某智能楼宇系统接入IoT终端时，工程师在机房里反复调试、抓包验证、最终拍着桌子说“就是这里没配对”的那个关键节点。

关键词“SW转发”明确指向交换机的数据平面行为——它不再仅做MAC地址学习+泛洪/单播转发，而是要理解并处理DHCP协议报文（尤其是DHCP Discover、Offer、Request、Ack这四步交互中的源/目的IP、端口、Option字段）；而“接口类型”则直接划定了操作边界：是连接终端的Access口？是连接另一台交换机或路由器的Trunk口？是作为网关的三层SVI（Switch Virtual Interface）？还是启用路由功能的三层物理口？每种类型下，DHCP报文的处理逻辑、需要启用的特性、甚至底层硬件ASIC的转发路径都截然不同。我试过在一台支持L3功能的盒式交换机上，把DHCP中继配置在Trunk口而非SVI上，结果所有VLAN的客户端都拿不到地址——因为Trunk口本身不终结VLAN，它只透传带Tag的帧，而DHCP中继必须工作在能识别VLAN ID并封装Option 82的三层接口上。这种细节，文档里往往一笔带过，但实操中就是卡点。

这个内容适合三类人：一是刚从校园网运维转岗到企业网络的工程师，手握CCNA证书却在真实设备上配不出跨VLAN DHCP；二是负责智能硬件联网方案的嵌入式开发者，需要理解为什么自家设备插在交换机某个口能自动获取IP，换个口就失败；三是备考HCIA-Datacom或H3CSE认证的考生，DHCP中继原理图背得滚瓜烂熟，但一看到设备CLI里的ip dhcp relay和ip helper-address并存就犯晕。它不教你怎么画拓扑图，而是告诉你：当交换机开始“思考”IP层事务时，每一个接口的物理属性、逻辑角色、协议栈状态，都必须被精确建模。接下来的内容，全部基于真实设备（以主流厂商三层交换机为蓝本，命令语法兼顾通用性）、真实排错过程、真实参数取值展开，没有假设，只有可验证的操作。

2. 核心设计思路拆解：为什么DHCP中继不能简单“开个开关”？

2.1 交换机角色转变：从二层透明桥接器到三层协议参与者

传统认知里，交换机是“傻瓜式”的：收到帧，查MAC表，转发或泛洪。但DHCP中继彻底打破了这一范式。当一台交换机启用DHCP中继功能时，它实质上在数据平面执行了三项关键动作：报文截获、IP头重写、Option字段注入。这不是软件CPU软转发的权宜之计，而是现代交换芯片（如Broadcom Trident系列、Marvell Prestera）通过TCAM（Ternary Content-Addressable Memory）硬件表项实现的线速处理。我拆解过某款国产交换机的SDK日志，发现当ip dhcp relay enable命令下发后，芯片内部会动态生成一条ACL规则：“匹配UDP目的端口67且源端口68的报文，重定向至CPU子系统”，但紧接着，驱动层会将这条规则升级为“匹配UDP 67/68 + VLAN ID + 接口索引”，并触发硬件TCAM写入一条新的转发指令——这才是真正影响性能的关键。

为什么必须强调硬件层面？因为很多故障源于对“转发路径”的误判。例如，当DHCP客户端发出Discover广播帧（目的MAC：FF:FF:FF:FF:FF:FF，目的IP：255.255.255.255），二层交换机默认会在本VLAN内泛洪。但如果该端口启用了DHCP中继，芯片必须在泛洪前完成判断：这个帧是否需要被截获？判断依据不是MAC地址，而是IP层信息。但问题来了——广播帧的IP头里，源IP通常是0.0.0.0，目的IP是255.255.255.255，标准IP ACL根本无法匹配！所以实际实现中，芯片会采用“端口级协议嗅探”机制：只要某物理口或SVI启用了DHCP中继，该接口收到的所有UDP 67/68报文，无论IP地址如何，一律触发重定向。这就是为什么你不能在同一个SVI上同时启用DHCP Server和DHCP Relay——硬件逻辑冲突，报文会被重复处理或丢弃。

2.2 接口类型决定协议栈位置：Access、Trunk、SVI、Routed Port的本质差异

“接口类型”绝非配置菜单里的一个下拉选项，而是定义了交换机协议栈的“锚点”。我们逐个拆解：

• Access口：纯二层接口，属于单一VLAN。它永远无法直接运行DHCP中继，因为中继需要三层IP地址作为源地址封装Relay Agent Information Option（Option 82）。但Access口可以作为DHCP客户端的接入点——此时交换机自身作为DHCP Client，向上游获取管理IP。我见过最典型的错误，是管理员在Access口下敲ip helper-address 10.1.1.1，结果毫无反应，因为Access口没有IP协议栈，ip helper-address命令根本不可用。

• Trunk口：同样是二层接口，但承载多个VLAN。它和Access口一样，不具备IP终结能力。试图在Trunk口配置DHCP中继，命令行会直接报错：“This command is only available on routed interface or SVI”。它的价值在于透传——当DHCP Discover帧带着VLAN Tag到达Trunk口，它会被无损转发给下游的SVI或三层口。这里有个隐藏陷阱：如果Trunk允许的VLAN列表（switchport trunk allowed vlan）没有包含客户端所在VLAN，Discover帧根本到不了中继点，自然无法触发后续流程。

• SVI（Switch Virtual Interface）：这是最常见的DHCP中继部署点。SVI是VLAN的三层终结点，拥有独立IP地址（如VLAN 10的SVI IP为192.168.10.254/24）。当客户端在VLAN 10内发出Discover，交换机在SVI上收到该广播帧后，将其转换为单播Unicast帧，源IP设为SVI的IP（192.168.10.254），目的IP设为DHCP服务器地址（如10.1.1.100），并在UDP载荷中插入Option 82，记录入接口、VLAN ID等信息。SVI的优势是天然绑定VLAN，配置简洁；劣势是每个需中继的VLAN都要创建一个SVI，管理IP地址池易碎片化。

• Routed Port（三层物理口）：这是更“硬核”的选择。当交换机物理口被no switchport命令关闭二层功能后，它就变成纯粹的三层接口，可直接配置IP地址。此时DHCP中继配置在该口上，意味着所有发往该口的DHCP报文（无论来自哪个VLAN）都会被中继。这适合极简架构，比如核心交换机直连DHCP服务器，所有接入交换机通过该物理口上联。但风险在于：它失去了VLAN粒度控制，一个口故障会影响所有业务VLAN。

提示：SVI和Routed Port的选择，本质是“VLAN感知”与“端口聚合”的权衡。SVI精细但配置量大；Routed Port粗放但可靠性高。我建议新项目优先用SVI，成熟环境可考虑Routed Port配合BFD快速检测。

2.3 DHCP中继与DHCP服务器的共生与互斥关系

标题中“SW转发”隐含了一个关键前提：交换机通常不作为主DHCP服务器（那是服务器或专用设备的事），而是中继。但现实中，小型网络确实会让交换机兼做DHCP Server。这时，“接口类型”的选择就上升为架构级决策。例如，在一个只有20台PC的办公室，管理员可能在核心交换机的VLAN 10 SVI上启用DHCP Server，直接为该VLAN分配地址；同时，在VLAN 20的SVI上启用DHCP Relay，将请求转发给总部的DHCP服务器。这种混合模式完全可行，但必须满足两个铁律：第一，Server和Relay不能配置在同一SVI上——否则Discover报文进来，交换机既想自己响应，又想转发给别人，逻辑死锁；第二，Server的地址池必须与SVI的子网严格一致，而Relay的helper-address必须指向合法的DHCP服务器IP，且该服务器必须信任此中继（即配置了对应中继代理IP白名单）。

我踩过的最大坑，是在一台交换机上为VLAN 10配置了DHCP Server，地址池192.168.10.100-192.168.10.200，但忘了把SVI的IP（192.168.10.254）加入排除列表。结果某天新员工插上网线，DHCP分配了192.168.10.254给他的笔记本——SVI瞬间失联，整个VLAN管理中断。这个教训让我养成了固定习惯：每次配置DHCP Server，第一件事就是ip dhcp excluded-address <SVI_IP>，第二件事是show ip dhcp binding | include <SVI_IP>做交叉验证。

3. 核心配置细节与实操要点：从命令行到芯片寄存器的全链路解析

3.1 基础环境准备：确认交换机能力与版本兼容性

在敲下第一个enable命令前，必须完成三项“体检”，否则后续所有配置都是空中楼阁：

第一步：确认硬件是否支持DHCP中继。并非所有交换机都具备此能力。低端百兆交换机（如某品牌S2300系列）仅支持二层转发，其芯片TCAM表项中根本没有DHCP协议识别模块。验证方法极其简单：进入特权模式，输入show version，重点查看System Model和Software Version。若型号为S5700-28P-LI，软件版本V200R019C10，则明确支持；若为S1700-26TR，版本V100R006，则基本不支持（需查官方文档确认）。更直接的方法是尝试ip dhcp relay命令，如果提示Unknown command，说明固件未编译该功能模块。

第二步：检查IOS/VRP/Comware版本是否存在已知Bug。DHCP中继是网络基础服务，但小版本间的差异足以致命。例如，某厂商V200R010C00版本存在一个严重Bug：当SVI配置了ip dhcp relay information option insert（强制插入Option 82）后，若客户端发送的Discover报文中已包含Option 53（Message Type），交换机会错误地将Option 53复制两遍，导致DHCP服务器解析失败。该Bug在V200R010C01中修复。因此，务必访问厂商支持网站，搜索你的型号+版本号+“DHCP relay bug”，下载最新补丁。我曾为定位一个“间歇性DHCP失败”问题，连续抓包三天，最终在Wireshark里发现Option 53重复，才想起查版本公告。

第三步：规划IP地址与VLAN拓扑。这是最容易被跳过的步骤，却是排错效率的分水岭。拿出一张纸，画出三个关键元素：客户端所在VLAN及网关SVI IP、中继交换机上联口IP（如果是Routed Port）、DHCP服务器IP及所属网段。特别注意：中继交换机到DHCP服务器的路径，必须是三层可达的，且中间不能有ACL拦截UDP 67/68端口。我习惯用ping -c 4 <DHCP_Server_IP>和telnet <DHCP_Server_IP> 67（测试端口连通性）双验证。曾经一个项目，所有配置完美，但客户端始终超时，最后发现防火墙策略只放行了TCP 67，忘了UDP——DHCP协议全程使用UDP。

注意：DHCP中继不要求中继设备与DHCP服务器在同一网段，但要求路由可达。这是初学者最大误区——以为必须直连。实际上，中继可以跨越多个路由器，只要IP路由表中有到达服务器的路径即可。

3.2 SVI接口下的DHCP中继标准配置流程

以最常见的“接入交换机（L2）→ 汇聚交换机（L3，启用中继）→ DHCP服务器（独立设备）”三层架构为例，详细拆解汇聚交换机的SVI配置。假设客户端在VLAN 100，网关SVI IP为192.168.100.254/24，DHCP服务器IP为10.1.1.100。

Step 1：创建并激活SVI

# 进入全局配置模式 system-view # 创建VLAN 100 vlan 100 quit # 创建SVI接口Vlanif100 interface Vlanif100 # 配置SVI的IP地址，这是中继的源IP ip address 192.168.100.254 255.255.255.0 # 启用接口（确保不被shutdown） undo shutdown quit

关键点：ip address命令必不可少，且必须是该VLAN的网关地址。如果此处配错（如配成192.168.100.1），DHCP服务器回复的Offer报文会发往错误地址，客户端收不到。

Step 2：在SVI上启用DHCP中继并指定服务器

# 进入SVI接口配置 interface Vlanif100 # 启用DHCP中继功能（部分厂商命令为ip dhcp relay enable） dhcp select relay # 指定DHCP服务器地址，即helper-address ip helper-address 10.1.1.100 # （可选）启用Option 82插入，提供客户端位置信息 ip dhcp relay information option quit

关键点：dhcp select relay是模式切换命令，告诉交换机“从此SVI开始，我不再是普通三层接口，而是DHCP中继点”。ip helper-address可配置多个，用多条命令添加，交换机会轮询发送（类似DNS查询）。ip dhcp relay information option虽非必需，但强烈建议开启——它让DHCP服务器能记录客户端接入的交换机端口和VLAN，为后续审计、策略控制（如按端口限速）提供数据基础。

Step 3：验证SVI中继状态

# 查看SVI接口状态，确认UP且IP正确 display ip interface brief | include Vlanif100 # 查看DHCP中继配置详情 display dhcp relay interface Vlanif100 # 查看DHCP中继统计信息（关键！） display dhcp relay statistics

display dhcp relay statistics输出中，重点关注Relay packets received（收到的Discover/Request数量）和Relay packets sent（发出的Discover/Request数量）。理想情况下，两者应基本相等。如果received很大而sending为0，说明中继未启用或配置错误；如果sending很大但客户端仍无响应，则问题在服务器侧或网络路径。

实操心得：我习惯在配置完立即执行reset dhcp relay statistics清空计数器，然后让一个客户端发起DHCP请求，再秒级刷新display dhcp relay statistics，观察计数器跳变。这种“实时反馈”比静态检查配置有效十倍。

3.3 Routed Port接口下的DHCP中继配置与特殊考量

当网络架构极简，或需要将中继功能集中到物理口时，Routed Port是优选。假设汇聚交换机有一个物理口GigabitEthernet1/0/24，配置为三层口，IP为10.1.1.254/24，直连DHCP服务器所在网段。

Step 1：将物理口转为三层模式

# 进入接口配置 interface GigabitEthernet1/0/24 # 关闭二层功能，启用三层 undo switchport # 配置IP地址 ip address 10.1.1.254 255.255.255.0 # 启用接口 undo shutdown quit

关键点：undo switchport是不可逆操作，执行后该口失去所有二层特性（如STP、VLAN划分）。务必确认此口确实只用于上联，不再接入任何终端或交换机。

Step 2：在Routed Port上启用中继

# 进入接口配置 interface GigabitEthernet1/0/24 # 启用DHCP中继（注意：命令与SVI相同） dhcp select relay # 指定DHCP服务器——这里有个重要区别！ ip helper-address 10.1.1.100 # （可选）启用Option 82 ip dhcp relay information option quit

关键点：ip helper-address在此处的语义与SVI不同。在SVI上，它表示“将本VLAN的请求转发至此服务器”；在Routed Port上，它表示“将所有发往本物理口的DHCP请求（无论源VLAN）都转发至此服务器”。这意味着，如果你有多个VLAN的接入交换机都上联到此口，它们的DHCP请求都会被统一中继。这简化了配置，但也带来了安全风险——恶意用户可能伪造Discover报文，耗尽服务器资源。因此，必须在Routed Port上配置ACL进行源IP过滤：

# 创建ACL，只允许来自可信VLAN网关的DHCP报文 acl number 3000 rule 5 permit udp source 192.168.100.0 0.0.0.255 destination 0.0.0.0 255.255.255.255 destination-port eq 67 rule 10 permit udp source 192.168.200.0 0.0.0.255 destination 0.0.0.0 255.255.255.255 destination-port eq 67 rule 15 deny udp destination-port eq 67 # # 将ACL应用到Routed Port的入方向 interface GigabitEthernet1/0/24 traffic-filter inbound acl 3000

Step 3：验证Routed Port中继

# 查看接口状态 display ip interface brief | include GigabitEthernet1/0/24 # 查看中继配置 display dhcp relay interface GigabitEthernet1/0/24 # 查看ACL匹配计数（验证过滤是否生效） display acl 3000

注意：Routed Port模式下，display dhcp relay statistics显示的是该物理口的全局统计，无法区分VLAN。因此，当多VLAN共用一个中继口时，必须依赖ACL日志或服务器侧日志来定位具体VLAN的问题。

3.4 DHCP Server与Relay共存的混合配置实践

在小型网络中，让一台交换机同时承担VLAN A的DHCP Server和VLAN B的DHCP Relay是常见需求。以下是经过生产环境验证的配置模板（以VLAN 10为Server，VLAN 20为Relay为例）：

Step 1：为Server VLAN配置SVI和地址池

# 创建VLAN 10 vlan 10 quit # 创建SVI interface Vlanif10 ip address 192.168.10.254 255.255.255.0 undo shutdown quit # 启用DHCP Server模式 dhcp enable # 创建地址池 ip pool pool_v10 network 192.168.10.0 mask 255.255.255.0 gateway-list 192.168.10.254 dns-list 8.8.8.8 # 排除SVI自身IP，防止分配冲突 excluded-ip-address 192.168.10.254 quit # 将地址池绑定到SVI interface Vlanif10 dhcp select global quit

Step 2：为Relay VLAN配置SVI和中继

# 创建VLAN 20 vlan 20 quit # 创建SVI interface Vlanif20 ip address 192.168.20.254 255.255.255.0 undo shutdown quit # 启用DHCP中继（注意：此处不能用dhcp select global，必须用relay） interface Vlanif20 dhcp select relay ip helper-address 10.1.1.100 ip dhcp relay information option quit

Step 3：关键隔离与验证

# 确认两个SVI互不干扰 display dhcp server statistics # 查看Server统计 display dhcp relay statistics # 查看Relay统计 # 抓包验证：在VLAN 10客户端侧抓包，应看到Offer来自192.168.10.254 # 在VLAN 20客户端侧抓包，应看到Offer来自10.1.1.100

警告：绝对禁止在同一个SVI上同时配置dhcp select global和dhcp select relay！命令行会允许，但运行时必然冲突。我曾因此导致VLAN 10的客户端偶尔收到错误的Offer（来自10.1.1.100），排查了两天才发现是配置叠加。

4. 实操全流程与核心环节实现：从客户端插网线到IP获取的逐帧解析

4.1 客户端发起DHCP Discover：广播帧的诞生与交换机的第一次抉择

一切始于客户端（如一台Windows PC）开机并启用DHCP。它的网络栈执行以下动作：

1. 构造一个UDP数据包，源端口68，目的端口67；
2. UDP载荷中填充DHCP Discover报文，其中ciaddr(Client IP) = 0.0.0.0，yiaddr(Your IP) = 0.0.0.0，giaddr(Gateway IP) = 0.0.0.0；
3. 将UDP包封装进IP包，源IP = 0.0.0.0，目的IP = 255.255.255.255；
4. 将IP包封装进以太网帧，源MAC = PC的MAC（如00:11:22:33:44:55），目的MAC = FF:FF:FF:FF:FF:FF（广播）；
5. 发送该帧到接入交换机的Access口。

此时，接入交换机（假设为纯L2设备）收到帧，执行标准二层处理：

• 查MAC表，发现目的MAC为广播，于是向本VLAN内所有其他端口（除接收口外）泛洪；
• 如果该VLAN配置了Trunk口上联到汇聚交换机，泛洪帧会带上VLAN Tag（如802.1Q Header中VID=100）发送出去。

关键点在于：纯L2交换机对DHCP Discover完全“无感”，它只是忠实地泛洪。真正的“智能”始于汇聚交换机的SVI或Routed Port收到这个带Tag的广播帧。

4.2 汇聚交换机的SVI截获与中继报文构造：从广播到单播的魔法

汇聚交换机的SVI（如Vlanif100）收到带VLAN 100 Tag的广播帧后，协议栈开始工作：

阶段一：帧解封装与协议识别

• 剥离以太网头和802.1Q Tag；
• 解析IP头：发现目的IP=255.255.255.255，源IP=0.0.0.0；
• 解析UDP头：发现目的端口=67，源端口=68；
• 此时，芯片TCAM匹配到预设的DHCP中继规则，将报文重定向至CPU。

阶段二：CPU处理与报文重写

• CPU读取报文，确认giaddr=0.0.0.0（表明这是首次Discover）；
• 构造新的UDP报文：
  • giaddr字段填入SVI的IP地址（192.168.100.254），这是中继代理的标识；
  • ciaddr保持0.0.0.0；
  • yiaddr保持0.0.0.0；
  • 在DHCP Options中插入Option 82（如果启用），Suboption 1（Circuit ID）填入Vlanif100，Suboption 2（Remote ID）填入交换机MAC；
• 封装新UDP报文：源端口=67（中继代理端口），目的端口=67（DHCP服务器端口）；
• 封装新IP报文：源IP=192.168.100.254（SVI IP），目的IP=10.1.1.100（helper-address）；
• 封装新以太网帧：源MAC=SVI对应的交换机MAC，目的MAC=下一跳路由器或DHCP服务器的MAC（通过ARP解析获得）。

阶段三：硬件转发

• 新构造的单播报文交由交换芯片，根据目的IP查路由表，找到出接口（如GigabitEthernet1/0/1）；
• 芯片执行三层转发，添加新以太网头，发送出去。

整个过程在毫秒级完成。我用debug dhcp packet命令在交换机上抓取过原始报文，对比前后，发现除了IP头、UDP头、DHCP头的几个关键字段被重写，其余载荷一字未动。这就是DHCP中继的精妙之处：它不改变客户端意图，只做“信使”的角色升级。

4.3 DHCP服务器响应与中继回传：Offer报文的双向旅程

DHCP服务器（10.1.1.100）收到中继发来的单播Discover后，执行标准流程：

• 查看giaddr=192.168.100.254，知道请求来自VLAN 100；
• 根据giaddr匹配地址池（如192.168.100.0/24），分配一个可用IP（如192.168.100.101）；
• 构造DHCP Offer报文：yiaddr=192.168.100.101，siaddr(Next Server)=服务器自身IP，giaddr=192.168.100.254；
• 封装UDP：源端口=67，目的端口=68；
• 封装IP：源IP=10.1.1.100，目的IP=192.168.100.254（giaddr）；
• 发送单播报文给中继。

中继交换机收到此Offer报文（目的IP=192.168.100.254，即自己的SVI IP）后：

• 协议栈识别出这是DHCP协议响应；
• 提取yiaddr=192.168.100.101，giaddr=192.168.100.254；
• 构造新的广播帧：
  • 目的MAC=FF:FF:FF:FF:FF:FF；
  • 目的IP=255.255.255.255；
  • yiaddr保持192.168.100.101；
  • siaddr保持10.1.1.100；
  • giaddr清零（因为这是发给客户端的，不再需要中继标识）；
• 将此帧从SVI对应的VLAN 100泛洪出去。

客户端收到Offer后，选择接受，并发送DHCP Request，流程类似，只是request IP字段填入192.168.100.101。中继再次截获，重写giaddr，转发给服务器。服务器回复ACK，中继再广播回客户端。至此，IP获取完成。

实操验证技巧：在客户端执行ipconfig /release后ipconfig /renew，同时在汇聚交换机上开启debug dhcp packet，你会清晰看到四次报文交互的完整序列，以及每次giaddr和IP头的变化。这是理解中继原理最直观的方式。

5. 常见问题与排查技巧实录：那些年我们追过的DHCP超时

5.1 典型故障现象与根因分析速查表

5.2 深度排错实战：一次真实的“间歇性DHCP失败”案例复盘

现象：某公司新办公楼，200个工位，接入交换机（L2）连接汇聚交换机（L3），汇聚上配置了VLAN 100-120的SVI中继。大部分客户端能正常获取IP，但约5%的客户端（集中在3楼东区）反复超时，重启网卡或更换端口后有时恢复。

排查过程：

1. 初步检查：display dhcp relay statistics显示所有SVI的received计数正常，sent也正常，排除中继配置问题。
2. 抓包定位：在3楼东区一台故障PC上抓包，发现它发出了Discover，但从未收到任何Offer。而在隔壁工位正常PC上抓包，Offer秒回。问题锁定在“从PC到汇聚交换机”的路径。
3. 物理层检查：用测线仪测试网线，通断正常；更换网线，问题依旧。
4. 交换机端口检查：登录接入交换机，display interface GigabitEthernet0/0/10（故障PC所连端口），发现input errors和CRC计数在缓慢增长。
5. 根源发现：检查该接入交换机的电源模块，发现其12V输出电压波动（万用表测量为11.2V-12.8V），低于标称值。进一步检查，该交换机安装在弱电井内，散热不良，高温导致PHY芯片（物理层芯片）信号完整性下降，产生大量CRC错误。DHCP Discover帧因CRC错误被接入交换机丢弃，根本无法到达汇聚交换机。

解决方案：

• 更换该接入交换机的电源模块；
• 在弱电井加装小型风扇改善散热；
• 为所有接入交换机配置display transceiver diagnosis（光模块诊断）和`display