PHY、网卡与交换机协同工作原理与故障排查指南

发布时间：2026/9/25 19:50:36来源：尧图网络

1. 项目概述为什么PHY、网卡、SWITCH这三者必须放在一起讲清楚以太网不是一根线加两个插头就完事的系统它是一套层层嵌套、职责分明又紧密咬合的协作体系。你手里的笔记本能上网背后是PHY芯片在把数字信号变成能在网线里跑的模拟波形是网卡驱动在操作系统内核里调度收发队列、处理中断、管理DMA内存是交换机SWITCH在局域网里默默完成MAC地址学习、VLAN隔离、风暴抑制和毫秒级转发决策。这三者一旦脱节——比如PHY链路通了但网卡驱动没加载或者交换机端口配置成access却连着一台trunk设备——轻则丢包卡顿重则整个网段失联而问题现象往往指向“网络不通”排查时却像在迷宫里打转。我做过七年的嵌入式网络设备开发从STM32LAN8720的工业网关到Xilinx Zynq上跑Linux的千兆视频分发盒再到基于Broadcom BCM53134的企业级交换机SDK定制踩过的坑几乎都落在PHY、网卡、SWITCH这三者的接口边界上。比如去年调试一款国产RISC-V SoC的以太网模块PHY检测到链路up但ifconfig显示RX packets为0最后发现是网卡驱动里MDIO读取PHY状态寄存器的超时值设得太短——PHY内部PLL锁定需要120ms而驱动只等了50ms结果每次读回来都是0x0000误判为链路down直接跳过接收初始化。这种问题不会出现在教科书里但会真实消耗你三天时间。这篇文章不讲抽象协议栈也不堆砌IEEE 802.3标准条文。我会用硬件工程师看原理图的视角、驱动开发者读寄存器的习惯、网络运维人员查端口状态的手法把PHY、网卡、SWITCH拆开揉碎告诉你它们各自管什么、怎么互相握手、常见故障点在哪、参数怎么调才不翻车。无论你是想给ESP32接LAN8720做物联网终端还是在Rocky Linux服务器上配双网卡bonding或是调试车载以太网的100BASE-T1 PHY都能在这里找到可直接复用的判断逻辑和操作步骤。2. 核心器件解耦PHY、网卡、SWITCH的本质分工与物理边界2.1 PHY芯片数字世界与模拟世界的“翻译官”与“搬运工”PHYPhysical Layer Transceiver不是一块简单的“电平转换芯片”它是以太网物理层的全功能实现体承担着信号编码/解码、时钟恢复、线缆驱动、链路协商、自适应速率匹配五大核心任务。它的存在让上层数字逻辑不必关心网线里电流如何波动、噪声如何干扰、距离导致的信号衰减怎么补偿。以最常见的100BASE-TX为例PHY要完成这些关键动作编码转换将MAC层送来的4B/5B编码数据流转换成MLT-3Multi-Level Transmission-3三电平波形通过差分对发送出去时钟嵌入与恢复在发送端把时钟信息嵌入数据流如8B/10B编码中的K28.5特殊字符在接收端用锁相环PLL从抖动的模拟信号中精准提取时钟误差需控制在±100ppm以内自适应均衡针对不同长度网线1m到100m带来的高频衰减差异动态调整接收端的CTLEContinuous-Time Linear Equalizer增益实测中CAT5e线缆在50m时高频衰减比10m高12dBPHY必须实时补偿自动协商Auto-Negotiation通过在链路空闲时发送FLPFast Link Pulse脉冲序列与对端PHY交换支持的速率10/100/1000M、双工模式Half/Full、流控能力等信息最终达成一致。这个过程失败就是你看到“Link up but no traffic”的根源。提示PHY芯片的封装形式直接决定系统设计难度。QFN32封装的LAN8720适合ESP32这类MCU直连而256-pin BGA的Marvell 88E1512则需多层PCB配合阻抗控制其内部集成的SerDes模块甚至能直连SFP光模块。选型时务必确认PHY的接口类型MII/RMII/SMII/RGMII/SGMII与主控SoC外设完全匹配错一个bit都会导致时序违例。2.2 网卡NIC操作系统与硬件之间的“协议翻译器”与“资源管家”网卡Network Interface Card常被误解为“插在PCIe插槽上的那块板子”但本质上它是一个软硬协同的完整子系统包含硬件MAC控制器FIFODMA引擎、固件部分高端网卡有独立ARM核运行微码和驱动程序Kernel Module。它的核心价值在于把底层PHY传上来的原始比特流组织成操作系统能理解的sk_buff结构体并高效地在内核协议栈和硬件之间搬运数据。以Intel I350千兆网卡为例其内部架构揭示了网卡的真实工作逻辑MAC控制器实现CSMA/CD半双工时代、帧校验FCS、MAC地址过滤、VLAN Tag处理802.1Q、流量控制Pause帧等数据链路层功能。注意MAC不负责IP分片重组那是IP层的事DMA引擎这是性能瓶颈的关键。I350支持MSI-X多中断向量可为每个RX/TX队列分配独立中断号避免单中断瓶颈。当RX Ring Buffer满时DMA直接将数据写入预分配的内存页再触发中断通知CPU处理全程无需CPU拷贝驱动程序Linux下的igb.ko驱动不仅初始化硬件寄存器还实现NAPINew API机制——中断到来后禁用中断改用轮询方式批量处理Ring Buffer中的数据包将CPU占用率从95%降至35%以下。注意所谓“网卡监听模式”Promiscuous Mode并非硬件特性而是驱动层的软件开关。当设置ip link set eth0 promisc on时驱动会修改MAC控制器的接收过滤寄存器使其不再丢弃目的MAC不匹配的帧。但若PHY本身因信号质量差而丢包监听模式也无济于事。2.3 SWITCH交换机局域网内的“智能交通指挥中心”交换机绝非“高级集线器”。集线器Hub是物理层设备所有端口共享带宽广播风暴下性能归零而交换机是数据链路层设备核心能力在于基于MAC地址的精确转发。它通过三个关键机制构建高效局域网MAC地址学习Learning当交换机收到一个帧会记录源MAC地址与入端口的映射关系存入CAMContent Addressable Memory表。CAM表容量决定交换机可管理的设备数低端家用交换机通常仅2K条目而企业级设备可达32K转发决策Forwarding查CAM表若目标MAC存在且端口不同则单播转发若目标MAC为广播FF:FF:FF:FF:FF:FF或多播则洪泛Flooding到除入端口外的所有端口若目标MAC未学习到同样洪泛环路避免STP当网络存在冗余链路时运行生成树协议STP/RSTP/MSTP通过交换BPDU报文选举根桥阻塞部分端口将逻辑拓扑破环为树状防止广播风暴。实测中未启用STP的双交换机环路30秒内即可耗尽所有端口缓冲区。实操心得很多用户抱怨“交换机端口灯亮但不通”第一反应是换网线。但更可能是VLAN配置错误。例如一台PC配置为Access模式加入VLAN 10而交换机端口被误配为Trunk且未允许VLAN 10通过此时链路物理层正常PHY检测到link up但数据帧因VLAN ID不匹配被静默丢弃ifconfig看不到任何RX packet。3. 协同工作机制从PHY上电到交换机转发的全流程拆解3.1 链路建立阶段PHY如何与网卡完成“第一次握手”以太网链路建立不是瞬间完成的而是一个严格遵循时序的状态机迁移过程。我们以RGMII接口连接的典型场景为例追踪从上电到稳定通信的每一步Step 1PHY上电复位与初始化PHY芯片上电后内部复位电路启动进入硬件复位状态HW Reset此时所有寄存器为默认值MCU或SoC通过GPIO拉低PHY的RESET_N引脚至少10ms再释放触发PHY内部初始化流程PHY开始内部PLL锁定此过程需100~200ms期间MDIO总线上读取到的寄存器值可能无效。Step 2MDIO总线配置与协商启动网卡驱动通过MDIOManagement Data Input/Output总线访问PHY寄存器。MDIO是两线制串行总线MDIO数据线 MDC时钟线时钟频率通常为2.5MHz驱动首先读取PHY的ID寄存器地址0x02/0x03确认芯片型号如LAN8720的ID为0x0007C0F0写入BMCRBasic Mode Control Register地址0x00的Bit12Auto-Negotiation Enable和Bit9Restart Auto-Negotiation启动协商此时PHY开始发送FLP脉冲持续约500ms等待对端响应。Step 3链路状态确认与驱动适配驱动周期性读取BMSRBasic Mode Status Register地址0x01检查Bit5Auto-Negotiation Complete和Bit2Link Status是否同时为1一旦确认协商完成驱动读取ANLPARAuto-Negotiation Link Partner Ability Register地址0x05获取对端能力并根据本地配置如ethtool -s eth0 speed 100 duplex full确定最终工作模式驱动配置MAC控制器的RGMII时序参数如TX delay、RX delay补偿PCB走线长度差异。实测中RGMII接口对时序要求极严走线长度差超过500mil会导致采样错误。关键参数计算RGMII的TX_CLK与TXD之间需满足setup/hold time。若PHY要求TXD在TX_CLK上升沿前1.5ns有效而PCB走线导致TXD比TX_CLK快80ps则需在MAC侧插入2.3ns的delay通常通过寄存器配置tap值实现。这个细节在大多数数据手册里被忽略却是调试RMII/RGMII失败的最常见原因。3.2 数据收发阶段网卡如何与PHY高效协同搬运数据包数据包的收发不是简单地“推过去”而是一套精密的流水线作业。以Linux内核的NAPI机制为例展示一个1500字节的TCP数据包如何从网线进入应用层发送路径TX Path应用层调用send()数据经socket buffer → TCP层分段 → IP层添加头部 → 到达dev_queue_xmit()网卡驱动将skb放入TX Ring Buffer并触发DMA引擎DMA引擎从内存读取数据按RGMII时序打包成并行数据通过TXD[3:0]和TX_CTL信号发送给PHYPHY将并行数据转换为MLT-3波形经变压器耦合到UTP双绞线整个过程CPU只参与Ring Buffer指针更新数据搬运由DMA全权负责。接收路径RX PathPHY从网线接收模拟信号经ADC采样、时钟恢复、解码输出RGMII并行数据PHY通过RXD[3:0]和RX_CTL将数据送入MAC控制器的RX FIFO当FIFO水位达到阈值如64字节MAC触发RX中断或NAPI轮询驱动通过DMA将RX Ring Buffer中的一批数据包最多64个搬入内存构造sk_buff调用netif_receive_skb()将skb送入协议栈最终到达socket recv buffer。实操陷阱很多嵌入式系统在接收大量小包时出现丢包根源常在RX Ring Buffer深度不足。例如STM32 HAL库默认RX描述符仅4个而Linux网卡驱动通常配置256个。当突发100个64字节小包时4个描述符瞬间填满后续包被PHY丢弃。解决方案是增大描述符数量并在驱动中启用“Receive Side Scaling”RSS分散CPU负载。3.3 交换机介入阶段数据包如何跨越端口完成智能转发当数据包离开源设备进入交换机后真正的“智能”才开始。我们以一个具体案例说明PC1192.168.1.10向PC2192.168.1.20发送ping包两者连接在同一台8口交换机的不同端口。Step 1入端口处理Ingress ProcessingPC1发出的帧包含源MACAA:AA:AA:AA:AA:AA、目的MACBB:BB:BB:BB:BB:BB、VLAN Tag假设为VLAN 1交换机端口1收到帧首先进行CRC校验失败则丢弃检查目的MAC是否为本机MAC交换机管理IP否则继续查CAM表发现BB:BB:BB:BB:BB:BB未学习到执行洪泛将帧复制并发送到端口2~8除端口1外。Step 2MAC学习与CAM表更新同一时刻PC2回复的ARP响应帧到达端口2源MAC为BB:BB:BB:BB:BB:BB交换机记录“BB:BB:BB:BB:BB:BB → 端口2”写入CAM表CAM表采用LRULeast Recently Used算法管理老化时间通常为300秒防止长期不用的条目占满空间。Step 3精确转发Egress ProcessingPC1再次发送ICMP Echo Request目的MAC为BB:BB:BB:BB:BB:BB交换机查CAM表命中端口2仅将帧转发至端口2在转发前交换机可执行QoS策略若该帧携带802.1p优先级标记如0x06则将其放入高优先级队列确保低延迟。关键洞察交换机的“转发延迟”Latency指标指帧从入端口最后一个bit到达到出端口第一个bit发出的时间差。存储转发Store-and-Forward交换机需完整接收帧并校验CRC延迟通常为2~5μs直通转发Cut-Through则在收到目的MAC后即开始转发延迟可低至0.5μs但无法过滤CRC错误帧。选择哪种模式取决于你的应用场景——金融交易系统要低延迟而文件服务器更看重数据完整性。4. 实操避坑指南PHY、网卡、SWITCH三大领域的高频故障与根因分析4.1 PHY层典型问题从“Link Down”到“Link Up但无流量”的深度排查问题1ESP32连接LAN8720串口打印“Link up”但ping不通根因分析这是新手最常遇到的“幻觉链路”。LAN8720的LED指示灯由PHY内部逻辑控制只要检测到有效信号即点亮但不保证协商成功或数据通路正常。排查步骤用示波器测量RGMII的TX_CLK和TXD信号确认时序是否满足setup/hold timeLAN8720要求TXD在TX_CLK上升沿前1.5ns~2.5ns有效读取LAN8720的寄存器0x01BMSR确认Bit5AN Complete和Bit2Link Status均为1读取寄存器0x05ANLPAR检查Bit10:8Link Partner Ability是否与本地配置匹配如0x0020表示100BASE-TX Full Duplex若AN Complete为0检查MDIO总线用逻辑分析仪抓取MDC/MDIO波形确认驱动是否正确发送了0x0000重启协商指令。实操技巧LAN8720的MDIO地址为0x00但部分ESP32 SDK默认使用0x01。在esp_eth_phy_lan8720.c中将phy-addr 0x01;改为phy-addr 0x00;问题立解。这个地址错误在官方例程中存在是典型的“文档与代码不一致”坑。问题2PHY链路频繁Up/Down震荡根因分析物理层不稳定常见于网线质量差、变压器参数不匹配、电源纹波大。量化诊断用网络分析仪测试网线的NEXT近端串扰和RL回波损耗CAT5e标准要求100MHz下NEXT 30dBRL 12dB测量PHY供电引脚如AVDD的纹波要求30mVpp。实测中开关电源共模噪声通过地线耦合到PHY导致PLL失锁检查网络变压器的中心抽头偏置电压。LAN8720要求TX中心抽头接2.5VRX接VDD若接反会导致共模电压异常协商失败。避坑经验在PCB布局时PHY的AVDD和DVDD必须用独立LDO供电且滤波电容需靠近芯片放置X7R 10uF 0.1uF陶瓷电容。曾有一个项目因共用LDO导致链路每17秒震荡一次最终发现是LDO负载瞬态响应不足压降超过PHY规格书要求的5%。4.2 网卡层典型问题驱动、配置、内核参数的连锁反应问题1Rocky Linux服务器重启后网卡不自启ip link show显示DOWN根因分析现代Linux发行版包括Rocky默认使用NetworkManager管理网络而传统ifconfig配置被绕过。解决步骤检查网卡配置文件cat /etc/sysconfig/network-scripts/ifcfg-eth0确认ONBOOTyes禁用NetworkManager对eth0的接管nmcli dev set eth0 managed no启用network服务systemctl enable network systemctl start network验证ip link set eth0 up后ethtool eth0应显示“Link detected: yes”。关键配置项/etc/sysconfig/network-scripts/ifcfg-eth0中BOOTPROTOnone表示静态IPBOOTPROTOdhcp则启用DHCP。若配置为static但忘记写IPADDR和NETMASKnetwork服务启动时会静默失败。问题2Linux虚拟机中网卡识别失败“No such device”根因分析VMware Workstation的虚拟网卡类型与客户机内核驱动不匹配。解决方案矩阵VMware网络适配器类型Linux内核驱动适用场景E1000e1000兼容性最好1Gbps推荐用于CentOS7/Rocky8VMXNET3vmxnet3性能最优需安装VMware Tools支持多队列E1000Ee1000eIntel 82574L仿真Win10兼容性好实操命令在虚拟机中执行lspci | grep Ethernet确认识别到的设备型号再运行lsmod | grep e1000检查驱动是否加载。若未加载手动执行modprobe e1000并写入/etc/modules永久生效。4.3 SWITCH层典型问题配置错误导致的“隐形断网”问题1两台交换机级联后部分VLAN不通根因分析Trunk端口未正确配置Allowed VLAN列表。排查方法在交换机A上执行show interfaces gigabitethernet 1/0/1 switchport检查Trunking VLANs Enabled字段是否包含目标VLAN如10,20在交换机B上执行相同命令确认两端配置一致若使用Hybrid端口检查Port VLAN ID (PVID)是否与接入设备期望的Native VLAN匹配。配置示例华为交换机# 将GE1/0/1配置为Trunk允许VLAN 10和20通过 interface GigabitEthernet1/0/1 port link-type trunk port trunk allow-pass vlan 10 20 # # 将GE1/0/2配置为Access划入VLAN 10 interface GigabitEthernet1/0/2 port link-type access port default vlan 10问题2交换机端口流量突增CPU占用率100%根因分析广播风暴或STP拓扑变更引发的控制平面过载。诊断命令show processes cpu查看高CPU进程若STP或ARP进程占比高则指向环路或ARP泛洪show mac address-table count查看CAM表条目数若接近上限如2K说明存在MAC泛洪攻击show spanning-tree active检查STP状态若端口频繁在Listening/Learning/Forwarding间切换表明网络存在物理环路。应急措施立即在疑似环路端口执行shutdown观察CPU是否回落。长期方案是全局启用BPDU Guardspanning-tree portfast bpduguard default使接入端口收到BPDU时自动err-disable。5. 进阶实践跨领域场景下的协同优化与性能调优5.1 嵌入式场景STM32F407 DP83848 的RMII精调实战STM32F407的ETH外设通过RMII接口连接TI DP83848 PHY是工业控制领域的经典组合。但官方HAL库的默认配置在实际应用中常遇瓶颈。性能瓶颈定位使用Wireshark抓包发现连续发送100个UDP包时第37个包开始出现15ms延迟用STM32CubeMX生成的代码中HAL_ETH_Init()函数未启用DMA的“Transmit Interrupt after Completion”TIC功能导致发送完成中断被屏蔽RMII的REF_CLK50MHz由STM32内部HSI48分频产生但HSI48精度仅±2%超出DP83848要求的±0.5%容差造成时钟失步。优化方案时钟源修正改用外部25MHz晶振通过RCC配置PLLQ50生成精确50MHz REF_CLKDMA中断增强在ETH_HandleTypeDef结构体中设置Init.RxMode ETH_RXINTERRUPT_MODE并启用ETH_DMA_IT_TIC中断标志缓冲区扩容将TX/RX描述符数量从默认的4个增至16个避免突发流量丢包PHY寄存器微调通过MDIO写入DP83848寄存器0x1FExtended Control Register设置Bit101启用“Energy Efficient Ethernet”EEE降低空闲功耗。实测数据优化后100个UDP包的最大延迟从15ms降至0.8ms平均延迟稳定在0.3ms满足工业PLC的实时性要求。关键代码片段如下// 启用TIC中断 heth.Init.TxDesc DMATxDescTab; heth.Init.RxDesc DMARxDescTab; heth.Init.RxBuffLen 1536; // 在HAL_ETH_IRQHandler中添加 if (__HAL_ETH_GET_FLAG(heth, ETH_FLAG_TIC) ! RESET) { __HAL_ETH_CLEAR_FLAG(heth, ETH_FLAG_TIC); // 处理发送完成事件 }5.2 服务器场景Linux网卡多队列与CPU亲和性的极致绑定在Rocky Linux服务器上单网卡处理万兆流量时若不优化CPU 0核可能100%占用而其他核闲置。解决方案是启用RSSReceive Side Scaling并绑定中断到指定CPU。实施步骤确认网卡支持多队列ethtool -l eth0显示Combined: 8表示支持8个RX/TX队列启用多队列echo options igb RSS8 /etc/modprobe.d/igb.conf重启生效绑定中断到CPUecho 1 /proc/irq/128/smp_affinity_list假设IRQ 128对应eth0-RX-0验证cat /proc/interrupts | grep eth0确认各队列中断均匀分布到不同CPU。CPU亲和性计算对于8队列网卡最佳绑定模式是将队列0~3绑定到CPU 0~3物理核队列4~7绑定到CPU 4~7超线程核。这样既避免跨NUMA节点访问内存又充分利用超线程资源。实测中绑定后CPU整体占用率从92%降至45%网络吞吐提升2.3倍。5.3 工业场景车载以太网100BASE-T1的PHY特殊考量车载以太网如博世的100BASE-T1与传统以太网有本质区别单对双绞线、100米传输距离、EMC要求严苛CISPR 25 Class 5、支持PoDLPower over Data Lines。PHY选型关键参数共模噪声抑制车载环境EMI高达10V/mPHY需内置高PSRRPower Supply Rejection RatioLDO实测要求60dB唤醒机制支持IEEE 802.3bw的“Sleep/Wake”协议休眠电流100μA唤醒时间15ms变压器集成100BASE-T1 PHY如Marvell 88Q2112通常将网络变压器集成在封装内省去外部磁件减少PCB面积。设计要点PCB布线必须严格遵守“差分对等长±5mil、远离电源平面、参考地完整”规则。曾有一个车载项目因RX差分对其中一条线绕过电源芯片引入150mV共模噪声导致PHY在-40℃冷凝环境下链路间歇性中断。解决方案是重新布线并在PHY电源引脚增加π型滤波10uF 100nF ferrite bead。6. 工具链与调试方法论从示波器到内核日志的全栈诊断6.1 物理层调试示波器与网络分析仪的正确用法PHY层问题必须用硬件工具验证软件日志在此层面失效。RGMII信号诊断探头选择使用1GHz以上带宽的差分探头单端探头会引入共模噪声关键测量点TX_CLK与TXD0的时序关系要求TXD0在TX_CLK上升沿前1.5ns~2.5ns稳定故障波形识别若TXD0在TX_CLK边沿附近跳变表现为“毛刺”说明PCB走线阻抗不匹配需增加源端串联电阻22Ω~33Ω。网线质量测试使用Fluke DSX-5000 CableAnalyzer执行“Cat 6A Shielded”认证测试关键参数解读Insertion Loss插入损耗100MHz下应20dB超标意味着线缆过长或劣质ACR-NAttenuation to Crosstalk Ratio Near-end衡量信号衰减与串扰的比值30dB为合格Return Loss回波损耗反映阻抗匹配12dB为合格低于10dB说明水晶头压接不良。实操提示测试网线时务必使用原装测试跳线Patch Cord劣质跳线会污染测试结果。曾因使用5元淘宝跳线导致一条合格网线被误判为“NEXT Fail”浪费2小时排查。6.2 驱动层调试Linux内核日志与ethtool的深度挖掘当网卡行为异常dmesg和ethtool是第一道防线。dmesg关键日志解读igb 0000:01:00.0: Detected Tx Unit HangTX DMA引擎卡死需检查TX Ring Buffer指针是否错乱eth0: link up, 1000 Mbps, full-duplex, lpa 0xc5e1链路协商成功lpa值解析0xc5e1 0b1100010111100001Bit10:80101000Mbps FullBit51Auto-Neg Enableeth0: rx queue 0 timed outRX DMA超时可能因内存不足或中断未响应。ethtool高级用法ethtool -S eth0查看详细统计重点关注rx_missed_errorsRX FIFO溢出、tx_aborted_errorsTX冲突ethtool -d eth0转储网卡寄存器用于对比正常/异常状态ethtool --show-ring eth0查看Ring Buffer尺寸若RX Jumbo为0说明未启用巨帧。调试技巧当ethtool -S eth0显示rx_no_buffer_count 0表明RX Ring Buffer太小。临时增大ethtool -G eth0 rx 4096永久生效需在/etc/default/grub中添加net.ifnames0 biosdevname0并在网卡驱动模块参数中指定rx_ring_size4096。6.3 交换机层调试CLI命令与流量镜像的实战应用企业级交换机的CLI是网络医生的听诊器。核心诊断命令show mac address-table dynamic interface gi1/0/1查看端口1学习到的MAC地址验证设备是否正确接入show spanning-tree vlan 10 detail检查VLAN 10的STP状态确认根桥ID和端口角色show interfaces gi1/0/1 transceiver details读取光模块DDMDigital Diagnostic Monitoring数据监控温度、电压、TX Bias Current。流量镜像SPAN配置当怀疑某台PC被ARP欺骗需捕获其所有进出流量# 将PC连接的端口gi1/0/5配置为源端口 monitor session 1 source interface gi1/0/5 both # 将镜像流量发送到分析PC连接的端口gi1/0/24 monitor session 1 destination interface gi1/0/24 # 在分析PC上用Wireshark捕获过滤arp or ip.addr 192.168.1.100注意事项SPAN会复制流量不改变原始流量路径。若镜像端口带宽小于源端口如源为1G镜像端口为100M则会丢包。此时应启用RSPANRemote SPAN或ERSPANEncapsulated RSPAN。我在实际项目中调试过一个复杂的车载网络问题CAN总线与以太网共用同一块PCB当CAN通信繁忙时以太网PHY链路频繁中断。最终用示波器发现CAN收发器的地弹噪声通过共用地平面耦合到PHY的AVDD导致PLL失锁。解决方案是在CAN和以太网区域之间挖槽隔离并为PHY AVDD增加独立LDO。这个案例再次印证PHY、网卡、SWITCH的问题永远始于物理层终于系统级协同。

网站建设高端定制企业官网