Kuberbetes网络排错

最新推荐文章于 2023-10-08 09:35:35 发布
最新推荐文章于 2023-10-08 09:35:35 发布
阅读量661 收藏 2
点赞数

通用：

本章主要介绍各种常见的网络问题以及排错方法，包括 Pod 访问异常、Service 访问异常以及网络安全策略异常等。

说到 Kubernetes 的网络，其实无非就是以下三种情况之一

  • Pod 访问容器外部网络

  • 从容器外部访问 Pod 网络

  • Pod 之间相互访问

当然，以上每种情况还都分别包括本地访问和跨主机访问两种场景，并且一般情况下都是通过 Service 间接访问 Pod。

排查网络问题基本上也是从这几种情况出发，定位出具体的网络异常点，再进而寻找解决方法。网络异常可能的原因比较多，常见的有

  • CNI 网络插件配置错误，导致多主机网络不通，比如

    • sysctl net.ipv4.ip_forward

    • sysctl net.bridge.bridge-nf-call-iptables

    • IP 网段与现有网络冲突

    • 插件使用了底层网络不支持的协议

    • 忘记开启 IP 转发等

  • Pod 网络路由丢失，比如

    • kubenet 要求网络中有 podCIDR 到主机 IP 地址的路由，这些路由如果没有正确配置会导致 Pod 网络通信等问题

    • 在公有云平台上，kube-controller-manager 会自动为所有 Node 配置路由，但如果配置不当（如认证授权失败、超出配额等），也有可能导致无法配置路由

  • 主机内或者云平台的安全组、防火墙或者安全策略等阻止了 Pod 网络，比如

    • 非 Kubernetes 管理的 iptables 规则禁止了 Pod 网络

    • 公有云平台的安全组禁止了 Pod 网络（注意 Pod 网络有可能与 Node 网络不在同一个网段）

    • 交换机或者路由器的 ACL 禁止了 Pod 网络

Flannel Pods 一直处于 Init:CrashLoopBackOff ：

Flannel 网络插件非常容易部署，只要一条命令即可

 
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

然而，部署完成后，Flannel Pod 有可能会碰到初始化失败的错误

 

$ kubectl -n kube-system get podNAME                            READY     STATUS                  RESTARTS   AGEkube-flannel-ds-ckfdc           0/1       Init:CrashLoopBackOff   4          2mkube-flannel-ds-jpp96           0/1       Init:CrashLoopBackOff   4          2m

查看日志会发现

 

$ kubectl -n kube-system logs kube-flannel-ds-jpp96 -c install-cnicp: can't create '/etc/cni/net.d/10-flannel.conflist': Permission denied

 

这一般是由于 SELinux 开启导致的，关闭 SELinux 既可解决。有两种方法：

  • 修改 /etc/selinux/config 文件方法：SELINUX=disabled

  • 通过命令临时修改（重启会丢失）：setenforce 0

Pod 无法分配 IP：

Pod 一直处于 ContainerCreating 状态，查看事件发现网络插件无法为其分配 IP：

 

  Normal   SandboxChanged          5m (x74 over 8m)    kubelet, k8s-agentpool-66825246-0  Pod sandbox changed, it will be killed and re-created.  Warning  FailedCreatePodSandBox  21s (x204 over 8m)  kubelet, k8s-agentpool-66825246-0  Failed create pod sandbox: rpc error: code = Unknown desc = NetworkPlugin cni failed to set up pod "deployment-azuredisk6-56d8dcb746-487td_default" network: Failed to allocate address: Failed to delegate: Failed to allocate address: No available addresses

查看网络插件的 IP 分配情况，进一步发现 IP 地址确实已经全部分配完，但真正处于 Running 状态的 Pod 数却很少：

 

# 详细路径取决于具体的网络插件，当使用 host-local IPAM 插件时，路径位于 /var/lib/cni/networks 下面$ cd /var/lib/cni/networks/kubenet$ ls -al|wc -l258
$ docker ps | grep POD | wc -l7

 

这有两种可能的原因

  • 网络插件本身的问题，Pod 停止后其 IP 未释放

  • Pod 重新创建的速度比 Kubelet 调用 CNI 插件回收网络（垃圾回收时删除已停止 Pod 前会先调用 CNI 清理网络）的速度快

对第一个问题，最好联系插件开发者询问修复方法或者临时性的解决方法。当然，如果对网络插件的工作原理很熟悉的话，也可以考虑手动释放未使用的 IP 地址，比如：

  • 停止 Kubelet

  • 找到 IPAM 插件保存已分配 IP 地址的文件，比如/var/lib/cni/networks/cbr0（flannel）或者 /var/run/azure-vnet-ipam.json（Azure CNI）等

  • 查询容器已用的 IP 地址，比如 kubectl get pod -o wide --all-namespaces | grep <node-name>

  • 对比两个列表，从 IPAM 文件中删除未使用的 IP 地址，并手动删除相关的虚拟网卡和网络命名空间（如果有的话）

  • 重启启动 Kubelet

  •  
  •  
# Take kubenet for example to delete the unused IPs$ for hash in $(tail -n +1 * | grep '^[A-Za-z0-9]*$' | cut -c 1-8); do if [ -z $(docker ps -a | grep $hash | awk '{print $1}') ]; then grep -ilr $hash ./; fi; done | xargs rm

而第二个问题则可以给 Kubelet 配置更快的垃圾回收，如

  •  
  •  
  •  
--minimum-container-ttl-duration=15s--maximum-dead-containers-per-container=1--maximum-dead-containers=100

Pod 无法解析 DNS：

如果 Node 上安装的 Docker 版本大于 1.12，那么 Docker 会把默认的 iptables FORWARD 策略改为 DROP。这会引发 Pod 网络访问的问题。解决方法则在每个 Node 上面运行 iptables -P FORWARD ACCEPT，比如

  •  
  •  
  •  
echo "ExecStartPost=/sbin/iptables -P FORWARD ACCEPT" >> /etc/systemd/system/docker.service.d/exec_start.confsystemctl daemon-reloadsystemctl restart docker

 

如果使用了 flannel/weave 网络插件，更新为最新版本也可以解决这个问题。

除此之外，还有很多其他原因导致 DNS 无法解析：

（1）DNS 无法解析也有可能是 kube-dns 服务异常导致的，可以通过下面的命令来检查 kube-dns 是否处于正常运行状态

 

$ kubectl get pods --namespace=kube-system -l k8s-app=kube-dnsNAME                    READY     STATUS    RESTARTS   AGE...kube-dns-v19-ezo1y      3/3       Running   0           1h...

如果 kube-dns 处于 CrashLoopBackOff 状态，那么可以参考 Kube-dns/Dashboard CrashLoopBackOff 排错 来查看具体排错方法。

（2）如果 kube-dns Pod 处于正常 Running 状态，则需要进一步检查是否正确配置了 kube-dns 服务：

 

$ kubectl get svc kube-dns --namespace=kube-systemNAME          CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGEkube-dns      10.0.0.10      <none>        53/UDP,53/TCP        1h
$ kubectl get ep kube-dns --namespace=kube-systemNAME       ENDPOINTS                       AGEkube-dns   10.180.3.17:53,10.180.3.17:53    1h

如果 kube-dns service 不存在，或者 endpoints 列表为空，则说明 kube-dns service 配置错误，可以重新创建 kube-dns service，比如

 

apiVersion: v1kind: Servicemetadata:  name: kube-dns  namespace: kube-system  labels:    k8s-app: kube-dns    kubernetes.io/cluster-service: "true"    kubernetes.io/name: "KubeDNS"spec:  selector:    k8s-app: kube-dns  clusterIP: 10.0.0.10  ports:  - name: dns    port: 53    protocol: UDP  - name: dns-tcp    port: 53    protocol: TCP

 

（3）如果 kube-dns Pod 和 Service 都正常，那么就需要检查 kube-proxy 是否正确为 kube-dns 配置了负载均衡的 iptables 规则。具体排查方法可以参考下面的 Service 无法访问部分。

DNS解析缓慢：

由于内核的一个 BUG，连接跟踪模块会发生竞争，导致 DNS 解析缓慢。

临时解决方法：为容器配置 options single-request-reopen

 

        lifecycle:          postStart:            exec:              command:              - /bin/sh              - -c               - "/bin/echo 'options single-request-reopen' >> /etc/resolv.conf"

修复方法：升级内核并保证包含以下两个补丁

  1. "netfilter: nf_conntrack: resolve clash for matching conntracks" fixes the 1st race (accepted).

  2. "netfilter: nf_nat: return the same reply tuple for matching CTs" fixes the 2nd race (waiting for a review).

其他可能的原因和修复方法还有：

  • Kube-dns 和 CoreDNS 同时存在时也会有问题，只保留一个即可。

  • kube-dns 或者 CoreDNS 的资源限制太小时会导致 DNS 解析缓慢，这时候需要增大资源限制。

更多 DNS 配置的方法可以参考 Customizing DNS Service。

Service 无法访问：

访问 Service ClusterIP 失败时，可以首先确认是否有对应的 Endpoints

 

  •  
kubectl get endpoints <service-name>

如果该列表为空，则有可能是该 Service 的 LabelSelector 配置错误，可以用下面的方法确认一下

  •  
  •  
  •  
  •  
# 查询 Service 的 LabelSelectorkubectl get svc <service-name> -o jsonpath='{.spec.selector}'# 查询匹配 LabelSelector 的 Podkubectl get pods -l key1=value1,key2=value2

 

如果 Endpoints 正常，可以进一步检查

  • Pod 的 containerPort 与 Service 的 containerPort 是否对应

  • 直接访问 podIP:containerPort 是否正常

再进一步，即使上述配置都正确无误，还有其他的原因会导致 Service 无法访问，比如

  • Pod 内的容器有可能未正常运行或者没有监听在指定的 containerPort 上

  • CNI 网络或主机路由异常也会导致类似的问题

  • kube-proxy 服务有可能未启动或者未正确配置相应的 iptables 规则，比如正常情况下名为 hostnames 的服务会配置以下 iptables 规则

     

  • $ iptables-save | grep hostnames-A KUBE-SEP-57KPRZ3JQVENLNBR -s 10.244.3.6/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000-A KUBE-SEP-57KPRZ3JQVENLNBR -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.3.6:9376-A KUBE-SEP-WNBA2IHDGP2BOBGZ -s 10.244.1.7/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000-A KUBE-SEP-WNBA2IHDGP2BOBGZ -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.1.7:9376-A KUBE-SEP-X3P2623AGDH6CDF3 -s 10.244.2.3/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000-A KUBE-SEP-X3P2623AGDH6CDF3 -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.2.3:9376-A KUBE-SERVICES -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-SVC-NWV5X2332I4OT4T3-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-WNBA2IHDGP2BOBGZ-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-X3P2623AGDH6CDF3-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR

Pod 无法通过 Service 访问自己：

这通常是 hairpin 配置错误导致的，可以通过 Kubelet 的 --hairpin-mode 选项配置，可选参数包括 "promiscuous-bridge"、"hairpin-veth" 和 "none"（默认为"promiscuous-bridge"）。

对于 hairpin-veth 模式，可以通过以下命令来确认是否生效

 

$ for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done1111

而对于 promiscuous-bridge 模式，可以通过以下命令来确认是否生效

  •  
  •  
$ ifconfig cbr0 |grep PROMISCUP BROADCAST RUNNING PROMISC MULTICAST  MTU:1460  Metric:1

无法访问 Kubernetes API：

很多扩展服务需要访问 Kubernetes API 查询需要的数据（比如 kube-dns、Operator 等）。通常在 Kubernetes API 无法访问时，可以首先通过下面的命令验证 Kubernetes API 是正常的：

 

$ kubectl run curl  --image=appropriate/curl -i -t  --restart=Never --command -- shIf you don't see a command prompt, try pressing enter./ #/ # KUBE_TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)/ # curl -sSk -H "Authorization: Bearer $KUBE_TOKEN" https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT/api/v1/namespaces/default/pods{  "kind": "PodList",  "apiVersion": "v1",  "metadata": {    "selfLink": "/api/v1/namespaces/default/pods",    "resourceVersion": "2285"  },  "items": [   ...  ] }

 

如果出现超时错误，则需要进一步确认名为 kubernetes 的服务以及 endpoints 列表是正常的：

 

$ kubectl get service kubernetesNAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGEkubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   25m$ kubectl get endpoints kubernetesNAME         ENDPOINTS          AGEkubernetes   172.17.0.62:6443   25m

 

然后可以直接访问 endpoints 查看 kube-apiserver 是否可以正常访问。无法访问时通常说明 kube-apiserver 未正常启动，或者有防火墙规则阻止了访问。

但如果出现了 403 - Forbidden 错误，则说明 Kubernetes 集群开启了访问授权控制（如 RBAC），此时就需要给 Pod 所用的 ServiceAccount 创建角色和角色绑定授权访问所需要的资源。比如 CoreDNS 就需要创建以下 ServiceAccount 以及角色绑定：

 

# 1. service accountapiVersion: v1kind: ServiceAccountmetadata:  name: coredns  namespace: kube-system  labels:      kubernetes.io/cluster-service: "true"      addonmanager.kubernetes.io/mode: Reconcile---# 2. cluster roleapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:  labels:    kubernetes.io/bootstrapping: rbac-defaults    addonmanager.kubernetes.io/mode: Reconcile  name: system:corednsrules:- apiGroups:  - ""  resources:  - endpoints  - services  - pods  - namespaces  verbs:  - list  - watch---# 3. cluster role bindingapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:  annotations:    rbac.authorization.kubernetes.io/autoupdate: "true"  labels:    kubernetes.io/bootstrapping: rbac-defaults    addonmanager.kubernetes.io/mode: EnsureExists  name: system:corednsroleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: system:corednssubjects:- kind: ServiceAccount  name: coredns  namespace: kube-system---# 4. use created service accountapiVersion: extensions/v1beta1kind: Deploymentmetadata:  name: coredns  namespace: kube-system  labels:    k8s-app: coredns    kubernetes.io/cluster-service: "true"    addonmanager.kubernetes.io/mode: Reconcile    kubernetes.io/name: "CoreDNS"spec:  replicas: 2  selector:    matchLabels:      k8s-app: coredns  template:    metadata:      labels:        k8s-app: coredns    spec:      serviceAccountName: coredns      ...

 

内核导致的问题：

除了以上问题，还有可能碰到因内核问题导致的服务无法访问或者服务访问超时的错误，比如

  • 未设置 --random-fully 导致无法为 SNAT 分配端口，进而会导致服务访问超时。注意， Kubernetes 暂时没有为 SNAT 设置 --random-fully 选项，如果碰到这个问题可以参考这里 配置。

lusic01
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
华为HCIA之网络排错大讲解.docx
09-08
华为HCIA之网络排错大讲解.docx
k8s网络之Flannel网络（三）
u012171444的博客
03-22 1814
1 简介 Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。 在默认的Docker配置中，每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是，不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够之间通过IP地址相互找到，也就是相互ping通。 Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的
【博客496】k8s dns解析与服务发现原理
qq_43684922的博客
09-16 2347
基于环境变量的服务发现其功能简单、易用，但存在一定的局限，例如，仅有那些与创建Pod对象在同一名称空间中且事先存在的Service对象的信息才会以环境变量的形式注入，那些处于非同一名称空间，或者是在Pod资源创建之后才创建的Service对象的相关环境变量则不会被添加。Kubernetes 中，域名的全称，必须是 service-name.namespace.svc.cluster.local 这种模式，服务名，就是Kubernetes中 Service 的名称。
Linux排错记录关于net.ipv4.ip_forward
爱码士的博客
12-18 8026
背景 今日，使用docker部署应用的时候，无法使用IP地址访问，防火墙已经关闭，可以ping通，应用已经配置0.0.0.0 解决 经过查阅资料。 学习网络传输中有一个 net.ipv4.ip_forward的参数 主要是目的是 当linux主机有多个网卡时一个网卡收到的信息是否能够传递给其他的网卡 如果设置成1 的话 可以进行数据包转发 可以实现VxLAN 等功能. cat /etc/sysctl.conf 发现没有值，而且net.ipv4.ip_forward=0，不能转发ip，于是猜测是这个问题。
K8S CNI及各CNI网络解决方案简述
不忘初心，方得始终
09-19 4101
CNi：什么是CNI？CNI是Container Network Interface的缩写，是一个标准的通用的接口。为了让用户在容器创建或销毁时都能够更容易地配置容器网络，现在容器平台：docker，kubernetes，mesos。 CNI如何实现？CNI用于连接容器管理系统和网络插件。提供一个容器所在的network namespace，将network interface插入该network......
7 张图解 CrashLoopBackOff，如何发现问题并解决它？
热门推荐
因上努力，果上随缘。但行好事，莫问前程。
08-31 2万+
是一种 Kubernetes 状态，表示 Pod 中发生的重启循环：Pod 中的容器已启动，但一遍又一遍的崩溃然后又重新启动。Kubernetes 将在重新启动之间等待越来越长的BackOff时间，以便您有机会修复错误。因此，CrashLoopBackOff 本身并不是一个错误，而是表明发生了一个错误，导致 Pod 无法正常启动。Pod 在 Running、Failed 和 Waiting 之间循环请注意，它重新启动的原因是因为它设置为Always（默认情况下）或OnFailure。...
网络故障排错
05-20
网络故障诊断应该实现三方面的目的：确定网络的故障点，恢复网络的正常运行；发现网络规划和配置中欠佳之处，改善和优化网络的性能；观察网络的运行状况，及时预测网络通信质量。 网络故障诊断以网络原理、网络配置...
VOIP 网络排错
01-09
### VOIP网络排错知识点详解 #### 一、概述 VOIP（Voice over Internet Protocol）即互联网协议语音传输，是一种通过互联网实现语音通信的技术。在实际应用过程中，VOIP网络可能会遇到各种问题，如通话质量不佳、...
计算机网络排错常用命令大全
12-11
### 计算机网络排错常用命令大全 #### 一、Ping命令详解 **1. Ping本机IP** - **用途**: 检查本地网络配置是否正确。 - **操作**: `ping 本机IP` - **结果分析**: 若收到响应, 表明本地网络配置正常; 若未收到响应...
网络排错案例分析与技巧交流
01-29
明确地定义什么是网络的“故障”和“排错”不是一件容易的事情。网络的“故障”往往是用户在某种应用不能正常实现时感知到的，有的业务场合，要迅速地找到故障并加以排除的要求是相当严格的。除了设备在正常运行中...
k8s - 如何变更CNI网络插件IP池?
dotNET跨平台
02-17 1049
作者：justmine头条号：大数据与云原生微信公众号：大数据与云原生创作不易，在满足创作共用版权协议的基础上可以转载，但请以超链接形式注明出处。为了方便阅读，微信公众号已按分类排版，后...
kubernetes-CNI网络插件
renren_100的博客
03-12 1993
flannel-github下载链接 壹，在253上 cd /opt/src/ 上传软件 mkdir /opt/flannel-v0.11.1 tar -zxvf XXXX.tgz -C /opt/flannel-v0.11.0/ ln -s /opt/flannel-v0.11.0/ /opt/flannel mkdir /opt/flannel/cert/ cd /opt/flannel/cert/ scp 192.168.6.245:/opt/certs/ca.
Kubernetes容器网络及Flannel插件详解
边缘计算社区
05-25 1597
本文来源于：巨子嘉，对云原生、K8s感兴趣的朋友可以关注一下！1.1.容器网络基础Kubernetes是一个开源容器调度编排引擎，管理大规模容器化应用，采用典型的Master-Worker主从分布式技术架构，由集中式管理节点（Master Node）,分布式的工作节点（Worker Node）组成。向下屏蔽底层差异化的分布式基础设施，以应用为中心构建云计算的基础操作系统能...
k8s flannel 网络抓包实践
newbei5862的博客
03-22 1041
初始环境如下，对两台机器的 docker0、flannel0、veth设备对进行了tcpdump抓包。 从busybox 发起ping nginx pod。 日志如下，以下的按照抓包的时间先后列出日志： 1、发起ping 的服务器：192.168.2.103 veth Last login: Sun Mar 22 15:13:25 2020 from 192.168.2.1...
深入了解：Kubernetes pod状态出现CrashLoopBackOff 的原因
最新发布
牛肉胡辣汤
10-08 1万+
在这个示例中，我们假设您的后端服务是使用Python编写的，并且使用了一个名为"app.py"的主应用程序文件。这只是一个简单的示例，您可以根据您的实际需求进行调整和扩展。在这个示例中，我们定义了一个名为"my-app"的Deployment，它包含一个容器名为"my-app-container"的镜像。在实际应用中，您可能还需要定义其他资源，如服务（Service）、持久卷（PersistentVolume）、配置映射（ConfigMap）等，以满足您的应用需求。
Linux - Hosts域名解析服务
⚡
08-28 1259
vim /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 127.0.0.1 www.baidu.com...
k8s注册节点出现kube-flannel-ds-amd64-5jqjj 服务状态为 Init:0/1
qq_46436508的博客
02-22 4703
** 在搭建完k8s之后，出现一点小问题，服务状态为 lnit:0/1，在删除重建后变为running ** 删除node节点 [root@master ~]# kubectl delete node node1 node "node1" deleted 生成注册命令 [root@master ~]# kubeadm token create --print-join-command kubeadm join 192.168.31.128:6443 --token pfw8xg.6wnbq3xav
k8s问题 CrashLoopBackOff
weixin_47151717的博客
10-13 9534
我们创建资源发现资源出现CrashLoopBackOff解决 CrashLoopBackOff 告诉我们，Kubernetes 正在尽力启动这个 Pod，但是一个或多个容器已经挂了，或者正被删除。 [root@localhost ~]# kubectl get pods NAME READY STATUS RESTARTS AGE mypod 0/1 CrashLoopBackOff 2
2022-04-27 openshift集群kubelet中出现unable to fetch pod logs错误问题定位
技术之路
04-27 2273
集群kubelet中出现unable to fetch pod logs错误 问题描述: 查看kubelet日志命令: journalctl -xefu kubelet 现象描述: http://cdp.cestc.cn/product/#/project/defect/list?projectId=1501448966260252673 release image：0.0.0-rc.1-20220425214427-20220426011558 kubelet ver...
华为HCIA网络排错全攻略：必备知识与方法
在华为HCIA网络排错大讲解文档中，首先强调了进行有效网络排错的基础条件。这些条件包括： 1. 熟悉OSI七层模型和TCP/IP协议栈：理解网络通信的基本框架是至关重要的，OSI七层模型描绘了数据传输的全过程，TCP/IP...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值