生产4区网络节点日志异常分析

生产4区网络节点日志异常分析

问题情况

1、网络节点ovs日志都存在cpu usage超过50%的告警

2、message日志存在br-int: dropped over-mtu packet: 1500 > 1450 的信息

影响范围

没有影响业务，只是日志异常

处理过程

1. 根据日志关键字revalidator说明

OVS revalidator线程有3个作用：

• 确认内核态datapath中规则和用户态配置的OpenFlow规则是否匹配，如果openflow流表被删除，datapath流表也必须删除
• OpenFlow规则更新后，OpenFlow规则也需要更新
• 清理过期的datapath flows

2、OVS内核态流表数据

依据现场发回的ovs内核态流表数据统计（2022-11-10 13:00-14:00）

节点	平均估值	每10分钟统计值
node-1	9972	10171 9615 10196 9813 10069
node-2	9190	9285 9068 9165 9341 9114
node-3	10384	9978 10443 11038 10360 10104
node-4	9920	9130 10218 10000 10090 10163
node-5	10815	10906 10740 11059 10655 10715
node-6	9153	8957 9159 9405 8979 9265

大部分节点ovs内核态流表数量在1w左右，依据之前内部的测试结果，当内核态流表数量超过8000左右时，revalidator线程会出现CPU负载升高的情况，日志中出现

poll_loop(revalidator239)|INFO|wakeup due to [POLLIN] on fd 87 (FIFO pipe:[61161]) at lib/ovs-thread.c:341 (54% CPU usage) 这样的INFO信息。

3、分析流表数据

以NET01、NET02、NET04、NET05为例，分析某个时间点日志，发现网络节点bond1上有从其他网卡过来的ARP广播包，以VLAN 2005和VLAN2075居多：

节点	VLAN ID	数量
net01	2005	1319
net01	2075	760
net02	2005	1336
net02	2075	761
net04	2005	1344
net04	2075	1561
net05	2005	1315
net05	2075	1520

根据现场确认vlan2005为bond2上面的子接口，vlan2075是arm架构环境的隧道网络；跟现场确认是否做了vlan隔离，回复没有做。

以node-3为例分析内核态流表情况：

内核态流表条目1：

recirc_id(0),in_port(96),eth(src=0c:42:a1:6c:f0:2d,dst=ff:ff:ff:ff:ff:ff),eth_type(0x8100),vlan(vid=2075),encap(eth_type(0x0806),arp(sip=172.50.43.150,tip=172.50.43.180,op=1/0xff)), packets:28357, bytes:1814848, used:0.884s, actions:94

字段	说明
in_port 96	网卡bond1
源MAC	0c:42:a1:6c:f0:2d
目的MAC	ff:ff:ff:ff:ff:ff（ARP广播包）
源IP	172.50.43.150
目的IP	172.50.43.180
VLAN ID	2075

内核态流表条目2：

recirc_id(0),in_port(96),eth(src=d0:c6:5b:a1:ca:bd,dst=ff:ff:ff:ff:ff:ff),eth_type(0x8100),vlan(vid=2005),encap(eth_type(0x0806),arp(sip=172.20.44.18,tip=172.20.45.49,op=1/0xff)), packets:29099, bytes:1862336, used:0.337s, actions:94

字段	说明
in_port 96	网卡bond1
源MAC	d0:c6:5b:a1:ca:bd
目的MAC	ff:ff:ff:ff:ff:ff
源IP	172.20.44.18
目的IP	172.20.45.49
VLAN ID	2005

这就是流表数量多的原因，这些从外部过来的ARP广播包会产生用户态的OpenFLow规则，同时也会在datapath中生成内核态流表。

1. 主路由器分布不均衡问题

节点	主	备
net01	15	16
net02	16	19
net03	47	60
net04	31	70
net05	73	34
net06	53	49

网络节点路由器分布情况：

从当前的主备路由分布情况，存在主路由分布不均衡的情况。

主路由器多的节点，承载的网络流量会相对要大，这个也需要调整和均衡。

5、br-int: dropped over-mtu packet: 1500 > 1450

原因：当不同的网络类型，如VxLAN网络（MTU 1450）和VLAN网络（MTU 1500）的端口同时接入到br-int上，会产生如上告警

在红帽官网查询到相关问题，确认是可以忽略的信息，没有影响

https://access.redhat.com/solutions/5613841

解决建议

1. 从交换机层面做vlan隔离，只放通需要使用的vlanid进入对应网卡
2. 虚拟路由的主路由分布不均衡，需要调整和均衡

后续项目提出问题

1、lost packet的丢包是否对平台有影响

2、ovs层面没丢包是以lost数量没变化来证明没丢包，那现在lost数量上升了，就要有一个合理的解释

问题答疑

从代码来看lost packet日志是在netlink socket buffer溢出时才会出现

OVS 在处理数据包时，内核态 datapath 匹配到缓存的 flow 时将直接进行处理。如果内核态 datapath 没有匹配到 flow 将触发 upcall 操作，即将数据包通过 netlink socket 发到 ovs-vswitchd 用户态进程进行处理。

数据包在 upcall 操作时首先保存在 netlink socket 的 receive buffer 中，ovs-vswitchd 启动了一定数目的 handler 线程来专门读取这些数据包，以进行下一步的处理。

ovs-vswitchd 的 handler 线程处理速度变慢时，netlink socket receive buffer 存在被内核写满的可能，此时会导致数据包被丢弃。handler 线程下一次读取 netlink socket 就会出错，并输出 lost packet on port channel 的日志。

ovs日志打印出lost packet告警日志原因，即内核中socket buffer满了，进行数据包丢弃，就会发出告警日志

此告警日志产生时，不会影响业务。从代码看，这里出错之后，ovs 会一直重试从内核读取数据，后续没有报错或者持续报错的话，就没有 packet lost告警。即这条日志只是一个瞬时的状态，而不是一个持续性的状态，所以判断为不影响业务。

这里的packet不是直接对应到真实的数据包，是内核发送给ovs的通知消息，不影响到上层应用的

但是以上只是理论上的解释，要实际证明丢包是否对平台是否产生影响是非常难的

后续只能通过sar分析流量来确认是否丢包，以及丢包的影响

1. 通过采集lost值，发现lost并没有持续增加，而是在一个时间点猛然上升后就停止

1. 通过分析sar文件，根据lost上升时间，确认流量drop的端口

IFACE 网络设备名

rxerr/s 每秒接收的坏包数量

txerr/s 传输包时每秒发生错误的数量

coll/s 传输包时每秒发生冲突的数量

rxdrop/s 接收包时，每秒丢弃的包的数量(缺乏缓存导致)

txdrop/s 传输包时，每秒丢弃的包的数量(缺乏缓存导致)

txcarr/s 传输包时，每秒发生的传输错误的数量

rxfram/s 接收包时，每秒发生帧校验错误的数量

rxfifo/s 接收包时，每秒钟缓冲区溢出错误的数量

txfifo/s 传输包时，每秒钟缓冲区溢出错误的数量

发现丢包的端口是tapd0455a95-d0、tap5e3b0bd9-6d、tap45901830-d6、tap822d919b-6b、tap32ee111e-4d这几个，每秒1个左右的丢包，而且这种丢包现象是长期一直在丢包的。而不是lost增加才丢包

通过端口名，再去确认端口流量情况，发现这几个端口并没有流量

# IFACE 具体的网卡名称

# rxpck/s 每秒接收的数据包的数量

# txpck/s 每秒发送的数据包的数量

# rxkB/s 每秒接收的字节数大小

# txkB/s 每秒发送的字节数大小

# rxcmp/s 每秒接收的压缩数据包的数量

# txcmp/s 每秒发送的压缩数据包的数量

# rxmcst/s 每秒接收的多播数据包的数量

1. 通过现场确认端口为dhcp端口，而且查询对应端口无流量，则判断对平台无影响