mzhan017的博客

如果一个大的TCP数据被分成几个segment，而每个segment如果走的路由途径不同的化，会导致下面这个解析上错误。从下面这个图里看，第一片和第二片的顺序的，但是第三片跑到了第二片的前面，wirehark就解析不出来了，会标记为：TCP previous segment not captured和TCP Fast Retransmission，两个错误。这个时候如果使用reassemble out-of-order segments。

经过调查发现是内核将ESP解开之后，如果是tunnel模式，内核又重新将skb丢给了interface去做处理。这样tshark/tcpdump就可以抓住了。抓到包之后，可以方便的分析问题，省去在wireshark里解码的问题。根据这个描述，看着是正常的，

因为内核里相关的结构体里有一个标记为：inet_bind_bucket.fastreuse，如果这个端口上的所有的socket都是reuse，这个标记为就一直生效，这样就一直不走conflict函数，也就不会产生什么特别的影响。这个时候就有可能出现问题，而且使用的这个端口，还是一个临时的端口，在net.ipv4.ip_local_port_range之内的一个临时端口。第一个是，如果有一个socket的设置SO_REUSEADDR函数调用失败，setsockopt，而且继续后面的bind操作；

再一次说明，使用sipp做性能测试时，需要注意的一个问题：一定要将相关的xml脚本文件，需要放到git repo里，需要使用版本控制的机制来管理，不能每次碰到问题，都是有脚本上的些许区别。每次都需要花费很多精力，时间去调查问题，到底是在哪里？然后就看为什么socket个数使用的多了，最后发现是sipp使用的脚本和之前不一样，其中的一个超时时间设置比之前的短了，导致超时重新发起业务时，老的socket需要一定的time-wait时间来终止，导致最终的新的socket，做bind-conflict。

一个小工具可以用来统计interrupt dump出来的数据。然后再导入到excel里倒是可以看出 中断的趋势。

最近遇到一个主机主动回icmp，destination unreachable的错误包，而且里面的code是 administratively prohibited。使用netstat命令看，这个主机是有监听1026端口。说明是有管理员配置的iptables的rule给拒绝了这个包。

这个参数就是为了在CPU于延迟直接做trade-off的一个参数，在Redhat的性能文档里有提，如果相应的计数有增加，就需要调整这个参数。下面这个修改是，将原来的固定值改成了可修改的一个值。后来又改了一次，防止HZ小于1000时出现问题。这个里面有关于这个参数的调整。

这个里面有一个丢包的例子是说，如果tx-queue的大小不够大，而切在云平台下，虚拟机的运行受到主机CPU使用的影响，导致tx-queue处理不及时，导致queue满，而出现丢包的情况。

总体来说还是IPv6层的MTU的限制，导致ESP层的代码逻辑更高。所以根据这个最小值的设置，我们就需要给出一个说明，在使用xfrm/esp的时候，最小的IPv6 MTU的设置不能是1280，而是1280+espHeader。产生这个错误的原因和一个commit相关，下面这个commit说了一个情况，就是对端的MTU设置为最小1280，会导致ip6_setup_cork函数返回EINVAL。将ipv6的MTU设置为1300，然后从在IPv6层之上再添加一个ipsec/esp层。

最近遇到一个问题，虽然应用层使用的系统调用send已经返回成功，而且没有错误日志产生，也没有errno的设置。那是不是代表一定是没有问题？从抓包的结果看，虽然上层应用已经显示发出去，但是实际抓包的时候，还是没有在接口上抓到相应的包！esp_output_done，这个函数调用xfrm_output_resume，而这个函数的返回值却没有进行处理，造成丢失错误的情况。通过调查看代码发现，内核对于ipsec的处理过程中，send系统调用，所调用的内核代码的函数链里，有可能将这个err丢失。

这里存在的一个问题，如果是必须的，就需要在接口里写上必须。如果没写是不是代表不是必须，但是如果不是必须为什么还会出现hang的情况。主要也是无心之举，一般使用者当然也不期望有什么invalid的包走到网卡。那什么时候使用呢，就是在放到网卡之前调用的一个函数。这个是不对的，至少对intel的 x710来说是需要。原因是下面这个hang的问题。这个函数调用的是每种网卡自己实现的一个接口，比如x710的i40e这个驱动，就有：i40e_prep_pkts，引入的时间是2016年9月，由下面这个commit加入。

不过后来，同事有提到，这个服务器启动的sipp所用的脚本文件，以及日志打印文件所属的目录，是mount的一个网络磁盘；这个信息就非常的关键；​今天谈一下，最近和同事一块看到的一个例子，说sipp运行时的某一时刻之后，总是会有408/487/retrans，通过netstat看，还总是会出现接收队列满载的情况。如果是正向的测试，其实应该是按照之前的一个总结来做，这样会避免倒着追查问题的可能：[测试]性能测试之前的工作。具体的问题解决的思路：一开始想到的可能是系统的CPU使用率是不是太高，导致的问题。

如果虚拟机上的业务，需要敏感的网络延迟，就需要设置这个参数来做调整。需要对自己产品已经vmware的设置相当的熟悉，才能知道要不要设置这个参数。如果不熟悉，可能要等到产品上线之后，才知道要改。

但是从ip link 来看没有no-carrier的状态，但是这个link的状态却一直是down的状态。今天从同事那里学到一个例子，说网卡的ethtool状态是好的，link 的状态也是up的状态。这就非常的合理了，如果网卡的firmware是好的，硬件状态可以为正常。网卡对应的网卡驱动选择的版本不对应导致的down。而驱动版本不合适，就会导致上层的down的状态。

如果抛开，“INET peer storage”这个标题，这个参数的解释第一句还以为是和内存相关的参数。虽然和内存是有关联！这里的storage只是INET peer可以存储多少个peer的storage。如果超过这个量，就会主动删除掉比较旧的记录。这个一般人应该用的非常少，因为个人电脑，很难说会达到这么多的peer量。inet_peer_threshold，默认值就是64K。

最近使用bcc-tools的时候注意到，bcc-tools（eBPF相关软件）的使用版本和内核的版本紧密程度非常高。修改为了tcp_drop_reason；在drop的同时带有drop的原因，方便debug问题。tcpdrop脚本的例子；tcp_drop函数被。

如果有很多的client使用一个NAT服务IP，可能出现链接的问题。因为每个client的时间不统一，这样导致TCP带有的timestamp在远端看起来有些滞后，滞后之后就会被认为是不安全的链接。表象是有些链接连接超时，断断续续的。解决方法就是在NAT的环境里，去掉timestamp的选项。

根据最后这个RFC-3263里的解释，是会根据RFC-2782的说明选取下一个服务器，继续尝试相同的请求。假如只配置了一个服务器，那只能重新尝试了。SIP：假如UE在TCP上发出的Register请求被对方回了TCP RST，UE会做什么？

在这个特定的情境中，ip_no_pmtu_disc 参数的值为0表示启用路径 MTU 发现，而不是禁用。这种设定可能会引起一些混淆，因为通常我们期望一个布尔类型的参数，值为1表示启用，值为0表示禁用。在这里，0 表示启用路径 MTU 发现，可能与一些人的直觉相悖。这个参数的迷惑性在于双重否定，字面意思是关闭PMTU发现的功能。这种设定可能会使人感到困惑，特别是对于不熟悉该参数含义的人。通常，为了避免混淆，文档和配置界面应该提供清晰的说明，以确保用户能够正确理解参数的含义和所代表的状态。

就这个对比问题的发生情况，我们有几个怀疑点，一个是就是人与人的不同，另一个是抓的地方不一样，经过缜密的分析，环境的问题不大，倒是人的差别不小。因为大家对于tcpdump的使用习惯非常的不同，现场由于对现场产品的操作的高要求，可能会考虑所抓包的大小问题，当然是期望在抓取文件比较小的时候，同时可以定位问题；而研发的这种潜意识要小一些，不是将磁盘空间的大小排在第一位，而是将调查问题的原因考虑在第一位。最近又遇到一个类似的问题，也是在tcpdump抓到的包里没有找到应该看到的包，搞得很迷惑。

看着非常有价值来做分析，比如查看当前socket的一些时间，计数上的统计，可以帮助分析问题。当然这个是瞬时的一个数据，但是也可以作为分析的基础。从TCP的使用手册上看，这个选项的作用是返回一个结构体数据。2.4 就引入了，其实大家可以用起来这个选项。ss -i 参数也是使用这个选项。

这里是说，当RTO重传一直收不到回应，这个参数会影响一个TCP的超时时间。这个参数是一个次数，当然重传的次数多了就是超时时间长，如果重传次数少了，超时时间就短。理论上讲，如果是默认值15次，可能是925.6秒（15分钟）之后才会超时，超时才会导致TCP断链。而RFC1122里，建议是至少100秒超时，对应8次。最近遇到的一个问题，网络配置问题，可能导致RTT非常的大，即使再大，可能也超不过这个15分钟，所以也不会导致断链重连。

但是对IP的变化处理依然是没有变化，不知道是出于什么样的考虑。可能遵照的原则是，不要改变其他不必要的行为，以免引起不适应的情况。在arp的代码里有这么一条路，意思是说，当net-device有变动的时候，要通知我，我会做一些处理，其中就包含IP地址发生变化是的处理。说产品的实现里，会存放一个dummy的neighbor（arp记录）在系统里，然后根据这个dummy的记录做一些特殊的处理。然后当时做的是非常普通的操作，只是将一个网卡上的最后的IP地址给删掉，然后就导致这个dummy的记录也被删掉了。

【代码】Linux: sysctl: rp_filter;包到了内核，没有到socket，火星包martia。

有一种情况是：当IP6的地址处于tentative的时候，就会返回这个错误。下面的是bind的调用的时候会check地址的flag。如果是tentative就返回：err = -EADDRNOTAVAIL;

这里的意思是说，bind实现的内容和connect实现的操作不一样。因为在bind的时，有些信息还不知道，比如对方的地址和port，这样对本地源port的选择就是一个问题，还需要判断是否可以reuse。所以建议将这个选项打开，以使用这个新功能。就是bind_conflict。这样对这个函数的调用会减少。

这个参数定义了，从哪一个port开始是非特权可以使用的port。而特权的port，需要root用户使用，或者需要权限：CAP_NET_BIND_SERVICE。如果设置为0，就是没有特权port。

https://github.com/fedora-sysv/initscripts[root@10 ~]# rpm -qi initscripts-10.00.17-1.el8.x86_64Name : initscriptsVersion : 10.00.17Release : 1.el8Architecture: x86_64Install Date: Fri 15 Jul 2022 11:05:35 AM EDTGroup : Unspecifi

假如在网卡的配置文件中设置了dhcp获取IP信息，可能导致这个网卡的MTU设置会跟着dhcp中的走，而不是网卡的配置信息。这个脚本就是先设置MTU，然后再做dhcp的请求，这样就会把mtu的值覆盖掉。MTU=1500 、、、 这个值可能会被 覆盖。需注意这个DHCP配置选项。

客户的技术经理也是一个狠人，放下狠话：再不解决，就要替换另一个厂商的产品，所有的网元都换！这是赤裸裸的恐吓:)。最后大家一致认为是switch出了问题，是因为switch的性能或者其他问题导致网络包数量上来之后，它处理不过来，最终导致网络延迟。但是看问题的最终的解决方法是替换了交换机上的一个SFP，问题就解决了。不禁感叹：看似简单的一个SFP替换，背后所要花费的人力物力，面临的风险真是非常的巨大。但是当用户将业务切过来之后，在高业务量的时候，各个网元就会出现网络延迟的现象，导致业务无法继续。

增加计数的原因是这个cqe_bcnt 超过了hw_mtu，导致丢包。从代码逻辑这个hw_mtu的值就是ip link里显示出来的mtu值。这个计数的理解是：收到了超过限定大小的包，软件丢弃包；最近遇到一例，收到的包比较大的时候丢包的问题。

之前遇到一个问题，说在两个主机之间的通信，从A到B的TCP包有丢，但是不知道丢在哪里。希望网络设备相关人员帮我们分析调查，为什么会有TCP的丢包。最后这个人也没找到具体原因在哪里，说是将中间的网路上的一些switch重启之后，就好了。这不是分析问题的正常思路，也不是解决问题的正常思路。

最近遇到一例从Mellanox-5网卡收上来的TCP包，不停的打下面这个backtrace。校验checksum有问题。后来根据systemtap的dump，看从网卡过来的skb->csum和计算的psum不能完全匹配。导致问题。目前还在做调试分析。

这个是专门给 ip route get 命令做的一个使用标记。

当interface down掉之后，对应的qdisc enqueue函数是，noop_enqueue，这个函数会直接丢掉skb-buffer，如果叠加另一个问题：https://mzhan017.blog.csdn.net/article/details/132270922：就会出现标题里的描述。当进入到qdisc的queue过程中之后，因为是异步的，不能实时的判断是否发送成功。只会告诉上层，已经成功放到queue。所以，即使qdisc，queue给drop，上层也不可能知道drop掉了。

default的意思是：所有新建的interface，都是以这个值来做配置，影响specific网卡的配置。specific 某一个具体的网卡，如果在没有all配置的情况下，这个才会生效。一般下边这种类型的配置都有三个选项：all，default，specific。all的意思是说，所有的interface都是以当前这个配置。从代码里看，还有需要与的情况，需要注意看文档。

但是具体看解释的话，就不是这个意思。解释是说， 如果还有其他非 --header 条件的，时候，至少要满足 --header的条件， 而不是说header 里有几个header，其中的一个 header 满足。其实但从字面理解，不看具体的解释的时候，容易让人理解为：–header里的选项，是软匹配，不是匹配里面的所有header。所以不能直接按字面意思理解。还是需要看具体的解释。然后根据使用说明来做工作。

如果不加-e参数，抓取不到 vlan信息，会导致wireshark解析出现问题。因为，抓到的二层认为上层是vlan协议，但是协议数据没抓到，导致解析出现错误，如果这样的话只能强制将0x8100解码为IPv4协议。

这个back-off的使用还是相当的广泛：《Adaptive Backoff Synchronization Technique》https://dl.acm.org/doi/pdf/10.1145/74926.74970。当一个包需要重传的时候，会使用 exponential back-off来计算下一次重传的时间。这个文章的出处是夏威夷的一个项目，也代表着对长距离通信研究的优势。第一次使用是在：Aloha [l],

如果下次看到这个特别的串，应该不会被疑惑到。