tcpreplay重放UDP pcap包时tcpdump可捕获但Filebeat无法接收的问题排查咨询

Hey there, let's break down why this might be happening. The key clue here is that tcpdump sees the packets but Filebeat doesn't—this usually points to a difference in how the OS handles packets before they reach user-space applications like Filebeat. Here are the most likely fixes to try:

1. 检查并修复数据包校验和（最常见原因） #

Tcpdump captures packets straight from the network interface, even if their IP/UDP checksums are invalid. But your server's kernel will drop packets with bad checksums before passing them to application sockets like Filebeat's UDP listener.

When you use tcprewrite to modify the destination IP/MAC, the original checksums in the packet headers are no longer valid (since they're calculated based on the old IP addresses). By default, tcprewrite doesn't automatically recalculate these checksums unless you explicitly tell it to.

How to fix: #

Add the --fixcsum flag to your tcprewrite command to recalculate IP and UDP checksums after modifying the headers. For example:

tcprewrite --dstip=192.168.1.100 --dstmac=aa:bb:cc:dd:ee:ff --fixcsum --infile=original.pcap --outfile=rewritten.pcap

Replay the rewritten pcap with tcpreplay and check if Filebeat starts receiving packets.

To confirm if checksums are the issue, run this tcpdump command on the receiving server:

tcpdump -i eth0 -nn -v udp port <your-port>

Look for lines mentioning "bad udp cksum" or "bad ip cksum"—if you see those, invalid checksums are definitely the problem.

2. 验证Filebeat的绑定配置 #

Double-check that Filebeat is listening on the correct IP/port and interface. If Filebeat is bound to a specific interface (not 0.0.0.0), make sure it's the one receiving the replayed packets.

Your Filebeat UDP input config should look something like this (replace with your actual IP/port):

filebeat.inputs:
- type: udp
  host: "192.168.1.100:514"  # Or "0.0.0.0:514" to listen on all interfaces

Restart Filebeat after making any config changes.

3. 检查OS级别的数据包过滤规则 #

Even though Filebeat works with other senders, it's worth confirming there aren't any iptables/nftables rules that are dropping packets from your tcpreplay server's IP.

Run these commands to check for blocking rules:

# For iptables
iptables -L -n | grep -i udp

# For nftables
nft list ruleset | grep -i udp

If you see any rules that target the source IP of your tcpreplay server or the UDP port you're using, adjust them to allow traffic.

4. 确认 jumbo 帧的配置一致性 #

You mentioned setting MTU to 9000 on both servers and using --mtu=6000 with tcprewrite. Just to be safe, verify that the replayed packets aren't exceeding the MTU (tcpdump will show packet sizes). If packets are being fragmented incorrectly, the kernel might discard them before reassembly. But since tcpdump captures them whole, this is less likely than the checksum issue.

Give these steps a try—start with the checksum fix, as that's the most probable culprit in cases like this.

备注：内容来源于stack exchange，提问作者Rayne