mzhan017的博客

当ARP aging time设为5分钟且已存在某IP的ARP缓存时，收到相同IP但不同MAC的UDP包，通常不会更新ARP表。这是因为： 普通数据包（如UDP）不会触发ARP表更新，只有ARP响应或Gratuitous ARP才会更新 这种机制是防止ARP欺骗攻击的安全设计 更新ARP表需要主动的ARP协议交互 例外情况包括收到ARP响应或缓存超时重新学习。建议通过调整ARP老化时间或配置安全机制来处理MAC变更问题。

在一台虚拟机上设置大量IP地址（如1000个）时，若业务虚拟机发生切换，另一台虚拟机会添加这些IP并通过GARP广播其MAC/IP。由于短时间内发送大量ARP请求，可能导致交换机（如HP5500）在一秒内无法响应任何ARP请求。HP5500交换机的ARP速率限制默认设置为50包/秒，最新版本已提升至400包/秒。设计时应考虑此限制，避免因外部设备性能瓶颈导致功能失效。此外，需评估是否真有必要在一台机器上设置如此多的IP地址，或考虑其他虚拟化替代方案以优化网络性能。

Wireshark的扩展功能非常强大，能够帮助用户进行深入的问题分析。它支持大量的自定义字段读取功能，并且兼容多种协议。例如，在Wireshark的文档中，frame.time_delta和frame.time_delta_displayed是两个常用的字段，分别表示从上一个捕获帧和上一个显示帧的时间差。这些功能从版本1.0.0到4.4.6都得到了支持，展示了Wireshark在协议分析和时间管理方面的强大能力。通过这些工具，用户可以更高效地进行网络数据包的分析和调试。

在DPDK与Intel网卡结合使用时，Intel X710/XL710千兆以太网控制器的队列是成对配置的，即一个接收队列（RX queue）和一个发送队列（TX queue）组成一个队列对。默认情况下，每个虚拟功能（VF）有4个队列对，最多可配置为16个。文档中强调了队列必须成对使用，但未明确说明如果RX和TX队列数量不一致会有什么具体影响。这种配置可能会导致未定义行为，类似于C++中的未定义行为，结果不可预测。因此，建议严格按照文档中的建议，确保RX和TX队列数量一致，以避免潜在问题。

在分析ip link set eno2 down/up的日志时，发现之前对某些日志信息的理解存在错误。日志[779001.387818] IPv6: ADDRCONF(NETDEV_UP): eno2: link is not ready实际上表示在执行up操作时，网络链接尚未准备好，而不是在down操作时出现的。同样，Broadcom驱动打印的日志NIC Link is Down也是在执行up操作时出现的，而不是在down操作时。这些发现表明，需要修正对这些日志信息的潜意识理解，以更准确地解读网络接口状态

这个原因是：route cache的最大个数值设置的太小，只有4K。如果系统需要的cache记录很多，导致后续的添加不上了，就会出现destination unreachable。在内核的log里应该会有很多相关的日志。最近看到一个destination unreachable的例子，这个问题的情况还是第一次遇到，记录在这里以防下次碰到类似的问题。后来系统的默认设置都非常大。应该出现的几率非常小。

这个知识点绝对有隐蔽性，一般上层很少需要关注这类细节。

在修改设备的ip6MTU的时候，使用sysctl设置的这条路和ip link 修改的这条路是不一样的。这里注册的时候设置的。这里的extra2就是最大值的一个限制。

然后做了一个ping操作，要ping消息的大小是1400（但是加上ICMP6，IP6的头信息，总长度会超过1400）因为在GRE6隧道的peer端路由有一个设置，2620:0:62:124::911这个IP是隧道的另一端IP。去掉GRE需要的 44个字节，再去掉分片头8个encaplimit的预留，就是1396。在gre6的tunnel接口上设置的是1456；看了半天也没搞懂为什么本机回的这个mtu：1396是在哪里设置上去的！这里的580 sec，是大约10分钟的时长，就是这个MTU的有效时间。

这个是必须知道的一个知识点。要不就不要自己设置gre6相关MTU，以及相关route的MTU。

VMware平台维护的同事说修改了一下配置，将IGMP的配置设置为默认值，并且将下面这个组播地址添加进来：Multicast range (224.1.1.0/24).后续的就没有问题再出现。看来VMware平台维护的人动了IGMP相关的配置。最近发现从其他VM过来的组播包，不时的有丢包的问题，从VM上抓包，源地址已经发了，就是在目的VM上抓不到。你要是问我具体是什么原因，我上回答不上来，因为没有再往下继续研究，因为访问不到底层的信息。这个时候就是没有别的办法了，就是VMware底层提供的虚拟网络有问题。

因为业务量增加导致有些UDP的包丢了，继而导致业务处理受到影响。最后查看是因为socket的receive buff size设置是128K（内核里乘2是256K)这个文件的最后一列是drop的计数。修改buff到256K（内核512K）业务恢复正常。相应的错误计数使用netstat -s查看。

最近遇到一个现象上看是: 网络丢包的问题，问题点是host主机上创建的一个tap设备，名称是vnet22，和对应虚拟机上的virtio-net设备，名称是int0，之间，从vnet22上抓包可以看到，但是在int0上没有抓到。后续仔细看wireshark，根据IP里的id字段看，是vnet22发的包到了int0，但是时间上有delay，而后续重传的包没有deliver到int0，这个可能是qemu-kvm的实现机制问题。进一步分析为什么有delay，发现虚拟机上起了太多的高消耗CPU进程。

捕获缓冲区大小不足：tcpdump 使用的捕获缓冲区大小可能不足以容纳所有的数据包。捕获过滤器效率低：如果使用的捕获过滤器效率低，可能会导致内核处理更多的数据包，从而增加丢包的可能性。系统资源不足：如果系统的CPU或内存资源不足，可能会导致内核无法及时处理所有捕获的数据包，从而导致数据包丢失。网络流量过高：当网络流量非常高时，内核可能无法及时处理所有的数据包，导致部分数据包被丢弃。系统配置问题：某些系统配置可能会影响数据包捕获的性能，例如网络接口的配置、内核参数等。优化捕获过滤器，减少不必要的数据包捕获。

如果注册的是arp层的raw socket，最终二层ARP的处理是通过遍历ptype，会顺序调用arp_rcv/arp_process来完成neigbor的更新等操作，也会调用packet_rcv来将数据传递到socket上。创建socket的函数packet_create，会注册一个 packet_rcv相关的回调函数。这个函数负责将packet，skb的对象，放到socket queue里。

最近遇到一个问题，说一个主机发的包，没有到对端，一开始怀疑设定的bond设备的问题，检查了bond的设置状态，发现没有问题，就感觉非常的奇怪。所以问题的根本是，现在两台主机不是直连的状态。STP消息（BPDU，Bridge Protocol Data Units）主要由网络中的交换机设备发送和处理。这些虚拟交换机也支持STP协议，并会发送和处理STP消息，以防止虚拟网络中的环路。主要发送和处理STP消息的设备包括交换机、网桥、集成了交换功能的路由器、高级无线接入点、网络管理设备以及虚拟交换机。

在某些情况下（如某台设备不断请求不存在的 IP 或受到攻击），ARP 请求会成指数级增长，形成 ARP 风暴，导致整个网络拥塞。如果你在实际环境中遇到了 ARP 性能问题，可以分析设备的 CPU 占用率、ARP 表大小和广播流量，找到具体的瓶颈点。ARP 请求是 广播 数据包，在二层交换机网络中，所有端口都会接收到广播，导致不必要的流量增加，影响正常的数据转发。ARP 表占用内存;设备的内存是有限的，ARP 表过大可能会导致老旧的条目被过早清除，从而增加了ARP 查询的频率。

如果所有的条件都符合，加的IP地址是相同subnet网段的情况下，ip4的选取第一个添加成功的。而ip6选择最后一个添加成功。根据测试结果，Linux内核关于source IPip6和ip4的选择策略不一样。RFC3484定义了ip6地址的选择。

最近遇到一个IGMP消息收不到的问题，现象非常奇怪，说一个VM上收不到其他VM发过来的IGMP消息，从交互上看已经假如了组，但是就是收不到。奇怪的是，在另一个相同host的另一个VM上做tcpdump，之后，就好了。有兴趣的可以看一下。

如果是shutdown/reboot，主leaf-switch，业务受影响的时间比较短，也就是一两秒的时间。第二个情况，需要leaf-switch检查，然后上报给spine switch，再完成切换，步骤要多一些。前两天系统测试的同事做了两个测试，是在Computer node相连的leaf-switch上做的操作。第一个是spine switch检查到问题，直接切换到standby leaf-switch。和Computer node相连的leaf-switch是两个互为备份。

看一个现场抓的一个pcap文件，发现有一个message被duplicate了好多遍。而且这个消息还是一个广播包。而且这个虚拟机上的网卡，还有很多个，再者是抓的pcap是使用-i any，任意网卡上抓的。因为-i any时，是使用linux cooked 层来替代了ethernet层抓取，从而导致问题分析不下去，分析不出来为什么这么多遍？是自己发的，还是外围有环路，又route回来了。

意思就是从acc1上收到了一个NA，从“fa:16:3e:aa:ee:cc”这个Mac地址来的，带着target IP是：44:33:11:3::4。但是acc1上也配置了这个IP：44:33:11:3::4。而且这个日志里含有关于调查问题的信息，对问题分析很有帮助。所以是怀疑有duplicate IP在网络上。最近碰到一个内核日志。

因此，“rx_crc_errors_phy” 表示在物理层接收到的数据包中，检测到的CRC错误数量。这通常意味着在数据传输过程中出现了问题，可能是由于信号干扰、硬件故障或其他传输错误导致的。“rx_crc_errors_phy” 描述在物理层（PHY）接收到的数据包中检测到的循环冗余校验（CRC）错误。PHY: 物理层（Physical Layer），是OSI模型中的第一层，负责物理介质上的数据传输。这两个都是物理层的错误，和网线，接口的关系比较密切。检查硬件：确保接收设备的硬件正常工作，没有故障。

在里面，竟然含有pps这种限制：ethtool -S；其实是比较苛刻的安全相关的策略？这个是调查网络问题的一个网页；

但是根据ip addr show的命令看，本机没有这个IP6地址。ping6 和traceroute，在后台一直运行。需要关注这两个命令的影响。这两个命令发包的时候，可以本地没有这个IP6地址。不知道是谁给他运行的。同事在一个VM上抓包，发现有一个IP6地址发出的ping包。

可以通过tshark/arp -n来分析问题，arp表可能会比较快的更新某个duplicate IP地址。或者通过抓包看硬件的mac地址，然后根据mac地址这一唯一标识来找硬件，找服务器。

最近在看一个路由的问题，顺便看内核代码，发现在添加IP的时候，内核会自动添加一个local route。在下面这个函数会使用fib_prefsrc；根据路由信息，如果是RTN_LOCAL的情况下。

今天碰到一个网络的问题，是第一次碰到，记录在这里，是关于一个两台服务器之间有两条直连线，这两条直连线组成了一个bond接口。但是经过几次的服务器power off/on之后，这两个机器之间的直连线/bond接口就不通了。最后调查是网络配置在机器重新启动的时候需要加载对应的配置。但是两个服务器上的bond设置已经不一致了。是因为primary配置错了，配置成了一个不存在的名字。导致机器重启选择了第一个起来的interface，而不是指定的interface。primary。

说Mellanox的网卡驱动在2018年做了一个对进入packet的大小检查的代码，如果超过MTU的设置就drop包。这个设置非常的不好，尤其是对于需要做驱动升级的例子。详情：https://mzhan017.blog.youkuaiyun.com/article/details/132823608。

在看峰值的时候，需要注意，时间间隔单位，一秒的间隔和100毫秒的间隔看到的信息可能不一样，比如上图，按照100毫秒展示差距很大，平均不到200，峰值到了700。某个时间点，上层突然就来了很多的包，导致尖峰。CPU的瞬时增高，可能导致其他的一些问题。如果是整体的包的量出现了尖峰，下一步就是要看是哪些业务导致了这个尖峰。需要使用wireshark提供的过滤功能，来对每一类业务做IO图展示，找出尖峰出现的原因。尖峰的出现还需要socket的receive-buff要设置的足够大来缓存消息。比如下面的UDP错误。

假如有两个VM（A和B）是互为备份，上面的IP地址是浮动的，假如其中一个VM A出现CPU的使用率太高，导致网络包堆积在网卡/驱动层。此时高可靠性导致浮动IP切换到另一端VM B，同时VM-A CPU使用率下降。这个时候，VM-A上的网卡/驱动会再次恢复运行，如果此时堆积包里的TCP-SYN包太多，就会导致这个错误的打印。这个情况也是和上面的情况一样。

http://www.snmp.com/The Simple Network Management Protocol (SNMP) is the standard operations and maintenance protocol for the Internet. SNMP-based management not only produces management solutions for systems, applications, complex devices, and environmen

最近遇到一个问题，说一个虚拟机上配置了IPv6的地址，UDP包经过ESP层，要发送到远端，结果对方出现checksum的错误。这种问题没有别的好办法，只能通过，两边抓tcpdump/tshark的包，来确定，这个checksum的值在哪一侧，哪一跳出现了问题。然后看了内核的版本是3.10的一个小版本，这个就比较老了，是2017年出的一个版本。但是如果是操作系统的升级阻力够大，也只能从内核代码/ftrace/systemtap的功能，来debug这个问题。内核IP/UDP/IPv6的协议栈出现了问题？

这个意思就是通过名称找网络接口没找到，添加ip6-gre的时候需要找的虚拟接口是：ip6gre0。所以找不到的原因是内核模块没有加载进来：modprobe ip6_gre。比如，在container的环境下，host级别需要先load内核模块。那如果问，什么原因导致没有load进来，就需要具体问题具体分析了。今天遇到一个添加gre失败的case，错误码是ENODEV。调用ioctl的时候必须设置的一个参数。

是指上一级的接口的状态。

erspan0是一个虚拟的端口，通常被称为“镜像端口”或“SPAN端口”。它用于网络监控和故障排除。缩写是：erspan - Encapsulated Remote SPAN over GRE and IPv4;相关文档：网络监控： erspan0 允许您将网络流量镜像到其他设备，例如网络分析仪或入侵检测系统，以便进行实时监控和分析。故障排除： 当网络出现问题时，您可以将流量镜像到 erspan0，以便查看网络流量并找出问题所在。

这里总结一下几个checksum的问题，仅供参考。需要看所使用的系统是否已经有了相应的fix。也可能是一个新问题，如果是新问题，恭喜发现了新的宝藏。

今天遇到一个问题，发现wireshark画的IO图，前几秒没有数据，但是根据Raw的pcap看，是有包的，这就迷惑了。经同事提醒，这个IO在设置了多个画图filter的时候，可能导致开始前几秒没有输出。这是第一次看到Wireshark的这种情况。问题解决的方法就是让IO图重新画。需要重新让wireshark画一下图，reset或者重选filter。

​所以，即使系统里依然有可用的内存，但是如果TCP层使用的内存超过了限制，仍然会进入到一个申请不到内存的情况。所以这个free命令显示的可用内存可能误导问题分析。除非对这个tcp_mem的机制已经有所了解！所以我们面对的一个问题是：当下一次发生类似问题的时候，怎么提醒后人？解决方法之一是系统学习Linux系统，分享这一篇文章给后人。另外一种解决方法是，根据Linux系统提供的计数功能，发警告。从个人的角度看是需要发出这种警告的。

这个可能的原因就是，进来的包被queue在了二层之前：或者是当前VM的网卡或者驱动，或者是网络上的某个设备。警告后续的分析，在主机上 的vnet抓包看，发现包已经转发到了VM层，也就是收进来的包被缓存在了虚拟机的virio-net设备或者驱动的ioring里。其中在debug的过程中，看到下面这个IO图，这个图比较经典，是一个典型的网络延迟图，可用作为分析问题的一个参考。如下图：黑色的线是当前VM发出的包；红色的线是当前VM收到的包的数量，以到达二层/tcpdump抓包的点为准。