关键词不能为空

当前您在： 主页 > 英语 >

端口丢包原因解析与排查指南

作者：高考题库网
来源：https://www.bjmy2z.cn/gaokao
2021-02-12 09:09
tags:

-

2021年2月12日发(作者：困境英语)



mi


文件类型：



故障类



版本号：

V1.0


（


28/09/08


）< /p>



文档作者：王雁



文档密级：



受控（和页面一致）



内审人：




使用对象：一线工程师







端口丢包原因解析及排查指南


2010-9-28




福建星网锐捷网络有限公司





















版权所有




侵权必究










修


订


记


录





日期



2010-9-28








第一次发布







修订说明



王雁







执行人



目


录



1



数据包处理流程说明


.................. .................................................. .................................................. ................. 3



1.1



1.2



1.3



1.4



交换机芯片结构


.................... .................................................. .................................................. ........... 4



数据包处理流程


.................... .................................................. .................................................. ........... 5



缓冲区


.................................................. .................................................. ............................................... 6



IBP


与


HOL

.


.................................... .................................................. .................................................. .. 6



1.4.1



IBP ................................... .................................................. .................................................. ...... 6



1.4.2



HOL ................................... .................................................. .................................................. .... 6



1.4.3



IBP


与


HOL


的联系



........................... .................................................. ..................................... 7



端口丢包常见原因及处理办法


.............. .................................................. .................................................. ..... 9



2.1



端口计数器的说明


................... .................................................. .................................................. ...... 10



2.2



底层常见计数器说明


.................. .................................................. .................................................. ... 13



2.3



端口丢包常见原因


................... .................................................. .................................................. ...... 15



2.4



端口丢包和转发丢包的联系与区别


............ .................................................. ................................... 17



端口丢包故障处理案例


................. .................................................. .................................................. ............ 18



3.1



S86


端口下出现


output


方向的


dr op


计数



.


.................................................. ...................................... 19



3.2



S26


开启组播，组播画面出现马赛克


.................................................. ............................................ 22



常见


FAQ......... .................................................. .................................................. ............................................ 27



4.1



Storm- control


控制的报文方向



.. .................................................. .................................................. .... 28



4.2


< p>
QOS


限速导致的端口丢包是否会在


show interface gi xx


显示？


.................................................. 28



4.3



生成树


block


的端口，


outp ut


方向是否有丢弃包的计数？



.< /p>


........................................ ................... 28



2



3



4





1


数据包处理流程说明


1



1.1


交换机芯片结构



交换芯片是交换机的 灵魂，交换芯片注定了交换机的数据转发性能及部分功能。例如不同型号产品的


芯片型号 便有所不同，但芯片的总体逻辑架构基本都如下图所示，模块化的交换机也基本都是多线卡组合

< br>起来的，实质就是单芯片通过


Hi-Gig


口连接到背板 形成星型结构，由引擎来进行集中管理和控制功能。




说明：


强烈推荐大家阅读此篇文档，加深对交换机硬件的理解。



《千兆位以太网交换芯片


BCM5690< /p>


及其在交换机中的应用》





名词解释：



ASIC


（


MAC


芯片）：为所有端口提供线速交换，



ASIC


：


内部提供多种


tables


，


如


MAC


地 址表，


VLAN


表，


MSTP


表，


链路聚合表，


链路聚合流量平衡表，



IPMC


表（


IP


组播表），用于策略控制的


FFP(Fast Filter Process)


表等。这些都是在


MAC

芯片内部存贮，以


CAM


或


TAC M


的方式寻址，硬件实现，完全满足数据包需要线速处理和转发的需要。



MMU


：



memory management unit


，管理和存贮交换缓存单元，并暂存数据帧。




1.2


数据包处理流程




以上图片中是最常见的数据处理逻辑。



所有的数据流通过交换芯片都要经过输入部分


(Ingress)

、


内存管理单元


(MMU)


和输出 部分


(Egress)


这三


个流程


.


其数据流程如上图。


< br>Ingress(


输入逻辑


)


是 数据包在每端口上的逻辑流程


.


每端口都有自己的输入逻辑


,


输入逻辑负责所有包


的转发


(


交换


)


策略


,


（例如进行


MAC


表查询 、路由表查询、


FFP


过滤（


ACL< /p>


、


QOS


染色）等）决定将包送给


哪个端口


,


根据转发信息将数据包发送给


MMU,


进行缓冲和调度


,


并以线速对包进行处理


.


输入逻辑与大部分

< p>
交换功能关联。



MMU(


内存管理单元


)


主要负责数据包的缓冲与调度


,


它接收从输入逻辑过来的数据包并缓冲这些包


,


同


时对这些包进行调度并将它们送给输出逻辑


.


数据包进入


MMU


时将存储在


CBP


里


.CBP


有


1MB


（不同芯片容


量不一致）的大 小供所有端口共用


.MMU


主要有四部分功能

< br>:


资源计数、背压、


HOL


预 防机制、调度


.


其中


资源计数主要是统 计当前消耗的


CBP


单元数或


CBP< /p>


数据包个数


,


决定数据包什么时候进入背 压或


HOL


预防


;

调度则是根据优先级和


COS


的多种调度准则（也就是我们 常见的


QOS


调度）来确定包发送的先后顺序和权


重。



Egress(


输出 逻辑


)


主要从


MMU

< br>获取数据包并将其送入各个端口


,


这是整个流程中最简单 的一环


.


它先将


包发给输出端口


,


然后确定是否在发送的数据包上添加


tag .


具体流程如下


:


首先从


MMU


请求数据包


,


如果发 送


的包要求不带


tag,


则负责将


tag


去掉


;


然后 计算数据包的


CRC;


最后将包交给


M AC


发送


(


特殊情况

< br>下


,CMIC(CPU


管理接口


)


将直接把数据包以


DMA


方式发送给


CPU)


，基于端口的限速功能也在


E gress


阶段完


成。



了解以上数据在芯片中的调度转发流程有助于我们理解数据在哪些地方可能会被丢弃。



1.3


缓冲区



涉及到缓冲区的两个概念就是：


CBP


和


MMU


公共缓冲池


CBP

< br>CBP


实际上是


1M


共享的包缓 冲区


.


本案例中以


BCM5690


为参考进行介绍。


CBP


由


8192(8K)


个单元组成


,


每个单元


128


字节。设备里的每个数据包消耗一至多个单元 。



内存管理单元


MMU:BCM56 90


有一个单独的内存管理单元。


每个


MMU


与设备的功能块


(GPIC


、< /p>


IPIC


等


)


相关联。


GIGA


接口控制器


GPIC :


用于提供


GE


口与交换逻辑之间的接 口。内联端口


(HiGig)


控制器


I PIC:


主要


提供


HiGig


口与内部交换逻辑之间的接口


,


有时也被用于多 片


BCM5690


之间的堆叠操作


}



MMU


负责数据包的缓冲和调度


.


它首先接收数据包


,

然后再将数据包缓冲


,


并在发送时加以调度


,


同时它


还管理交换单元的流控特性

< br>.


概括来说


,


就是缓冲逻辑、调 度逻辑、流控逻辑


.


缓冲逻辑从


CP- BUS


（总线）接


收包并存放在


CBP ,


同样也从


CBP


获取包并将它们发送 到


CP-BUS


（总线）上去。包的发送顺序由调度逻辑


根据包的优先级别确定。流控逻辑包括


Head-of- Line


HOL


阻塞预防和


Back pressure


两种方式


.


缓冲区 的大小由芯片决定，但缓冲区的分配方式可以进行调整。例如每端口固定分配或动态共享。



BCM


芯片系列一般采用平均分配的方式，因为考虑到


Fair


公平性的原则，这是一种比较理想的设计。


目前的设计采用了静态


+


动态共享的方式（静态分配一 部分缓冲区


+


动态全局共享一部分，智能调整）



Mavell


芯片系列可以进行人工调整，例如可以 使用


buffer manage FC|QOS


来进行调整。


QOS


模式可以


共享缓冲区大小，并根 据报文的


COS


优先传输高优先级的报文，低优先级的报文进行 缓冲或给高优先级报


文提供更多的缓冲空间，


来不及缓冲的直接 丢弃。


当采用


FC


模式时，

< p>
平均分配缓冲区大小并通过发送


Pause


帧，< /p>


要求对方减少发送速率，


从而避免丢弃。


（当出现


no


buffer


丢包时，


发送


pause


帧，

< br>需要两端开启


Flow


control


）。



1.4


IBP


与


HOL


1.4.1


IBP


IBP


（


ingress black pressure


）


是一种关注每个


I ngress


入端口


CBP Bufffer

< br>率用率的方法，


当缓冲率用率达


到一定比率时，一个


Pause


帧就由


Ingress


口发出，如果对端支持流控，那么就会暂停一段时间，从而宏观上


减少了 发送速率，从而可以减小本机缓冲区的利用率，达到不丢包的目的。



1.4.2


HOL


HOL


（


head of line


队头阻塞）是一种关注每个


Egress


出端口


Buffer


利用率的方法，当利用率达到一定


比率时，从


CBP Buffer


送到端口的


TX


队列的 报文就会被丢弃。出端口其实并没有物理上的缓冲区，只是


做了一个出端口的队列（


Transaction Queue


，其实就是我们的

< p>
COS


队列），这个队列的指针指向


CBP


缓冲


区。队列根据端口的速率固定分配了长度，当报文在经历


Ingress


—


MMU


阶段中，会决定报文的某个


Egess


出接口，于是将


TX


队列尾指针指向


CBP

< br>中此报文的缓冲区位置，


HOL


就是关注这个

< p>
Transaction Queue


的使


用率，


当在实际应用中，


例如某个千兆口向百兆口快速发包就可能导致


TX


队列超出


limit


，那么后续需要将


CBP


报文写入

< br>TX


队列的报文将会被丢弃，


从而导致丢包，

< p>
如果入接口开启了流控，


HOL


溢出也会在入接口


发送


Pause


流控帧。



1.4.3


IBP


与< /p>


HOL


的联系



从上面


IBP


与


HOL


的描述，我们可以看出，


IBP


关注于：入接口的缓冲 区率用率情况。



HOL


关注于：


出接口的队列使用情况


（类似于缓冲区的率用率情况）


。


两者的关联关系可以这样描述：




所以入丢包和出丢包时两个不同的阶段，

HOL


丢包，不一定回同时有


IBP


事件产生。有


IBP


事件产生也


不一 定会导致


HOL


丢包，但有


IBP


存在的时候，


HOL


出现的几率更大。因为 某端口的入速率变大，那么往


另外一个某出口的出速率也可能增大，导致


HOL


溢出丢包。



当入端口 有限速（非


QOS


限速，即


rate- limit


）如果朝这个端口发包超过这个速率，也会导致此端口发

送


PAUSE


流控帧，如果配置了出端口限速（即


rate-limit


），那么交换机转发到此端口的速率超出了限制，


也会发生流控。另外，广播包


(


组播、 单播


)


限速（


storm contr ol


）和


COS


限速不会导致发生流控 ，而是直接


丢弃。



那么我们如何判定 是否有


IBP


的情况呢？怎样又表明


H OL


存在溢出导致的丢包呢？



IBP


导致的丢包，一般通过上层命令都可以查看到：



例如：



show interfaces gigabitEthernet 0/1


结果：




Index(dec):1 (hex):1


GigabitEthernet 0/1 is DOWN , line protocol is DOWN


Hardware is marvell GigabitEthernet


Description: TO-ZGE-S8610-2_GE2/1


Interface address is: no ip address


MTU 1500 bytes, BW 1000000 Kbit


Encapsulation protocol is Bridge, loopback not set


Keepalive interval is 10 sec , set


Carrier delay is 2 sec


RXload is 1 ,Txload is 1


Queueing strategy: WFQ


Switchport attributes:


interface's description:


medium-type is copper


lastchange time:0 Day: 0 Hour:45 Minute:26 Second


Priority is 0


admin duplex mode is AUTO, oper duplex is Unknown


admin speed is AUTO, oper speed is Unknown


flow control admin status is OFF,flow control oper status is Unknown


broadcast Storm Control is ON,multicast Storm Control is OFF,unicast Storm Control


is ON


5 minutes input rate 0 bits/sec, 0 packets/sec


5 minutes output rate 0 bits/sec, 0 packets/sec


37167599 packets input, 2566418459 bytes,


45 no buffer, 45 dropped//


丢包


45


个



Received 58764 broadcasts, 0 runts, 0 giants


0 input errors, 0 CRC, 0 frame, 0 overrun, 0 abort


37210638 packets output, 2565322398 bytes, 0 underruns , 0 dropped


0 output errors, 0 collisions, 0 interface resets



show interfaces gigabitEthernet 0/1 counters


InOctets : 2566418459


InUcastPkts : 88649


InMulticastPkts : 37020186


InBroadcastPkts : 58764


OutOctets : 2565322398


OutUcastPkts : 1238


OutMulticastPkts : 37161052


OutBroadcastPkts : 48348


Undersize packets : 0


Oversize packets : 0


collisions : 0


Fragments : 0


Jabbers : 0


CRC alignment errors : 0


AlignmentErrors : 0


FCSErrors : 0


dropped packet events (due to lack of resources): 45 //


丢包


45


个，由于


CBP


不足导致



packets received of length (in octets):


64 : 70436041



HOL


的丢包，一般需要在设备底层通过读取相关寄存器获取。底层 有


HOL


丢包在原来的版本中，


sho w


Interface counters


的时候也有显示， 但客户对


drop


计数会有不少抱怨，其实

HOL


溢出一般都是由于多端口向


某端口发包速率太快所致 ，是由于环境原因引起的。所以在后来的版本中，我们将


HOL


的计数都放在底层


显示了，如有流控机制会自动进行调整改善。



例如：



S26-Test(sd)#sh show cou


4 : 628,352 +130,128 519/s


4 : 877,970 +180,898 700/s


4 : 148,092 +29,930 150/s


4 : 159,845 +32,535 156/s


4 : 280,791 +57,243 207/s


4 : 785 +96


4 : 904,990 +186,772 721/s


4 : 9,873 +2,025 7/s


4 : 1,692 +360 2/s


4 : 26,045 +5,336 25/s


4 : 2,946 +576 2/s


4 : 122,657 +24,741 125/s


4 : 122,657 +24,741 125/s


4 : 1,068,988 +219,906 882/s


4 : 273,630,102 +55,501,231 261,676/s


4 : 628,352 +130,128 519/s


4 : 1,068,988 +219,906 882/s


4 : 60 +9


4 : 128 +1


4 : 1,555 +361 2/s


4 : 155 +18


4 : 69 +5


4 : 448 +2


4 : 24 +1


4 : 2,259 +387 2/s


4 : 555,542 +34,097 137/s


4 : 2,071 +377 2/s


4 : 2,259 +387 2/s


1 : 2,071 +377 2/s


1 : 65 +9


1 : 5,604 +1,975 15/s


第一列是累计值，第二列是 从上次


show


至今的累计值，第三列


是每秒丢丢包个数。


BCM


芯片一般


F e0


代表第一个接口即


fe1,1


代表 第二个接口。



2


端口丢包常见原因及处理办法


2



2.1


端口计数器的说明



通过查看端口的计数器，我们可以知道端口的收发包统计状况。



端口


counter


输出：

< p>


Switch#show int fastEthernet 0/1 counters


Interface : Fa0/1


5 minute input rate : 0 bits/sec, 0 packets/sec //5


分钟的平均速率



5 minute output rate : 0 bits/sec, 0 packets/sec


InOctets : 68023600


进入的包总数



InUcastPkts : 92842


单播包



InMulticastPkts : 36700


组播包



InBroadcastPkts : 75636


广播包



OutOctets : 3630373


出去的总包数



OutUcastPkts : 32053


单播包



OutMulticastPkts : 1059


组播包



OutBroadcastPkts : 13231


广播包



[1] Undersize packets : 0


[2] Oversize packets : 0


[3] collisions : 0


[4] Fragments : 0


[5] Jabbers : 0


[6] CRC alignment errors : 0


[7] AlignmentErrors : 0


[8] FCSErrors : 0


[9] dropped packet events (due to lack of resources): 0


[10] packets received of length (in octets):


64:119136, 65-127: 75769, 128-255: 12663,


256-511: 3149, 512-1023: 1955, 1024-1518: 38849




[1]


长度小于


64


字节，校验和正确的报文：和


Fragment


帧对应 ，区别在于校验和。



[2]


帧超长 且校验和正确的报文：和


Jabber


帧对应，区别在于校验和 。



[3]


冲突帧：多站点同时试图发送信息导致冲突，单双工遇到较多。



[4]


长度小于


64


字节，校验和错误的报文：和


Undersize


帧对 应，区别在于校验和。



[5]


帧超 长且校验和错误的报文：和


Oversize


帧对应，区别在于 校验和。



[6]


非超常帧且校验和 错误的报文：和


FCS


相同，


CRC< /p>


是发送方本地进行校验，对端收到后


重新进行计算，然后比对


FCS


字段。



[7]



接收的帧有重组错误：


没有通过帧校验且没有边界字节结束


（非整字节）

的帧，


bit


丢失。



[8]



帧的内容改变或者丢失：帧校 验


FCS


错误



[9]


丢弃报文统计：总和



[10]


根据长度统计接收的报文



以上原因基本都是由于网卡、端口、线路故障或接触不良导致的。可以先进行链路、端口 的


替换测试。对于以上内容需要了解更深入的，可以在线搜索相关详细解释。

< p>



端口输出：



switch#show interfaces gigabitEthernet 2/1


Index(dec):1 (hex):1


GigabitEthernet 2/1 is UP , line protocol is UP


Hardware is Broadcom 5464 GigabitEthernet //phy


型号



Interface address is: no ip address


MTU 1500 bytes, BW 1000000 Kbit //MTU


带宽



Encapsulation protocol is Bridge, loopback not set


Keepalive interval is 10 sec , set


链路脉冲



Carrier


delay


is


2


sec


载波延时，口链路的载波检测信号

DCD


从


Down


状态到


Up


状态的时间延时，


如果

DCD


在延时之内发生变化，那么系统将忽略这种的状态的变化而不至于上层的数据 链路层重新协商



RXload is 1 ,Txload is 1 //


接口负载利用率


1/25 5


，每


5


分钟统计。

< br>


Queueing


strategy:


FIFO //


这些都是给路由器用的，交换机不应该


show


这些信息，目前在新版本


10.4< /p>


（


2b2


）中已经不显示了。

< p>


Output queue 0/0, 0 drops;


Input queue 0/75, 0 drops


Switchport attributes:


interface's description:


medium-type is copper


lastchange time:5 Day: 7 Hour:47 Minute:40 Second//


接口自系统启动后发生


link


变化


的相对时间，可以结合


show ver


查看系统的启动时间，判断端口上次发生

< p>
up/down


的时间。



Priority is 0


admin duplex mode is AUTO


配置的双工为


auto, oper duplex is Full//


实际的双工状态



admin speed is AUTO, oper speed is 1000M


配置与实际的速率



flow control admin status is OFF,flow control oper status is OFF


流控



broadcast Storm Control is OFF,multicast Storm Control is OFF,unicast Storm


Control is OFF


5 minutes input rate 0 bits/sec, 0 packets/sec 5


分钟平均值



5 minutes output rate 20523 bits/sec, 9 packets/sec 5


分钟平均值



42388309 packets input, 2917143960 bytes, 0 no buffer, 0 dropped


重点关注


no buffer


和


droped


统计，


no buffer


就是由于缓冲区不足。



Received 76899 broadcasts, 0 runts, 1 giants


0 input errors, 0 CRC, 0 frame, 0 overrun, 0 abort


69858478 packets output, 6534138835 bytes, 0 underruns , 116 dropped


重点关注


droped


统计



0 output errors, 0 collisions, 0 interface


resets



ZGE-S8610-1#


虽然是


5


分钟的平均值，但实际上是


5


秒钟更新 一次，软件模块会


5


秒钟读取相关


MI B


并计算最近


5


分钟

< br>的数据然后进行更新。



大家一般对


input


以及


output


方向的


drop

< br>代表什么含义非常感兴趣，这里就和大家一起来分析一下。


端口的计数，我们实现都是根据


RFC


来进行定义的：



Inputdrop RFC1213


的定义如下：



ifInDiscards OBJECT-TYPE
















SYNTAX



Counter
















ACCESS



read-only
















STATUS



mandatory
















DESCRIPTION















































to be discarded even though no errors had been
























detected to prevent their being deliverable to a
























higher-layer protocol.



One possible reason for
























discarding such a packet could be to free up
























buffer space.
















::= { ifEntry 13 }


这个值仅表示接口下资源不足导致的丢包统计


,


资源不足主要是对端发包太快或


HOL


原因导致的入 缓


冲溢出引起的。（


HOL


是出方向对 头阻塞，但出方向对头阻塞的同时，可能会引起入缓冲溢出。）




Outputdrop RFC1213


定义如下：



ifOutDiscards OBJECT-TYPE
















SYNTAX



Counter
















ACCESS



read-only
















STATUS



mandatory
















DESCRIPTION















































to be discarded


even though no errors had been
























detected to prevent their being transmitted


.



One
























possible reason for discarding such a packet could
























be to free up buffer space.
















::= { ifEntry 19 }


这个值可以表示任何原因导致的出口丢包统计，所以描 述不是特别详细，目前我们也是根据


RFC


定义


的出口丢帧的原因以及产品芯片定义的一些出口丢帧的原因，出方向的


Drop


原因种类很多，总结包括如下


可能：



报文老化（因为出口


HOL


等原因，导 致报文在出口队列中待太久没有被调度到）



VLAN


出口检查错误，接口不属于要转发报文的


vlan


（极少见到）



还有一些属于应用策略丢弃的，比如需要用出 口转换表，结果报文在该表中无法查找到导致报文被丢


弃的（如


PVLAN


的一些应用），还例如


STP


的端口


BLOCK


。



报文超过


MTU


长度的，出口


MTU


检查超出了


MTU


限制。



所以仅从表面无法能够知晓


Drop


丢包的原因，通常情况下这种丢包也不会对网络正常使用造成影响，


从目前已有的故障案例中，排除例如端口阻塞的正常原因，基本都是环境因素导致的


MM U


资源不足。



遇到此类问题时，需要 参考


2.3


的方法进行详细的信息收集来综合判断。

< p>


2.2


底层常见计数器说明



底层的寄存器计 数非常真实的反映了芯片实时或累计的相关数据，具有非常好的参考意义，上层的所


有数 据统计其实都来源于底层的数据。



底层丢包我们重点关注有无


HOLD


溢出，并关注其累计值，实时值。其他数据仅作为参考 网络环境中


的报文流情况。



字段



第一列



第二列



第三列



第四列




进入底层后


Show counter all


可以查看到所有的寄存器的值，


show c


只显示字段有变化的值，通常我们


show c


就可以了。




21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


收到的单播包



21 : 0 +0


21 : 0 +0


说明



各个端口的各种计数器



计数器累计值



从上次执行


show counters


到当前，计数器的该变量



每秒速率



21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0 HOL


对头拥塞丢帧计数



21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


21 : 0 +0


收到的报文字节大小


64


21 : 0 +0


收到的报文字节大小


65-127


21 : 0 +0


收到的报文字节大小


128-255


21 : 0 +0


收到的报文字节大小


256-511


21 : 0 +0


收到的报文字节大小


512-1023


21 : 0 +0


收到的报文字节大小


1024-1518


21 : 0 +0


收到的


1519-1522


带


tag


的报文



21 : 0 +0


收到的报文字节大小


1519-2047



21 : 0 +0


21 : 0 +0


21 : 0 +0


收到的报文数



21 : 0 +0


收到的字节数



21 : 0 +0


收到的组播报文



21 : 0 +0


收到的广播报文



21 : 0 +0 FCS error


帧统计



21 : 0 +0


收到的控制帧统计（例如流控协商）



21 : 0 +0


收到的


pause


帧统计



21 : 0 +0


不支持的


op caode


控制帧



21 : 0 +0 Alignment error


帧



21 : 0 +0


长度不符的异常帧，相见参考表



21 : 0 +0 Code error


21 : 0 +0


收到的载波计数



21 : 0 +0 oversize


帧统计



21 : 0 +0 Jabber


统计



21 : 0 +0 MTU


检查失败统计



21 : 0 +0 runt


帧统计


-


-


-


-


-


-


-


-



本文更新与2021-02-12 09:09，由作者提供，不代表本网站立场，转载请注明出处：https://www.bjmy2z.cn/gaokao/642421.html

返回列表：英语

端口丢包原因解析与排查指南的相关文章

端口丢包原因解析与排查指南随机文章
端口丢包原因解析与排查指南热门标签