Project

General

Profile

Actions

Bug #8163

closed

dpinger default payload fails 70%

Added by Marcello Silva Coutinho over 6 years ago. Updated over 6 years ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
Gateway Monitoring
Target version:
-
Start date:
12/04/2017
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.2
Affected Architecture:
amd64

Description

using 2.4.2 on a intel network card with vlan tagged and a monitor ip from first hop after gateway

with default length 8, 70% of packages are lost

00:44:25.217993 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 30005, seq 43, length 8
00:44:26.259000 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 30005, seq 44, length 8
00:44:27.300967 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 30005, seq 45, length 8
00:44:28.302747 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 30005, seq 46, length 8
00:44:29.304746 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 30005, seq 47, length 8
00:44:29.306452 IP 189.87.a.b > 200.252.x.y: ICMP echo reply, id 30005, seq 47, length 8
00:44:30.306744 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 30005, seq 48, length 8
00:44:31.308747 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 30005, seq 49, length 8
00:44:32.327994 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 30005, seq 50, length 8
00:44:33.332993 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 30005, seq 51, length 8
00:44:34.396497 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 30005, seq 52, length 8

increasing payload by 56 under gateway config, it stops failing

00:57:13.924926 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 24838, seq 236, length 64
00:57:13.927467 IP 189.87.a.b > 200.252.x.y: ICMP echo reply, id 24838, seq 236, length 64
00:57:14.988198 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 24838, seq 237, length 64
00:57:14.990719 IP 189.87.a.b > 200.252.x.y: ICMP echo reply, id 24838, seq 237, length 64
00:57:16.019945 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 24838, seq 238, length 64
00:57:16.022706 IP 189.87.a.b > 200.252.x.y: ICMP echo reply, id 24838, seq 238, length 64
00:57:17.066216 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 24838, seq 239, length 64
00:57:17.068729 IP 189.87.a.b > 200.252.x.y: ICMP echo reply, id 24838, seq 239, length 64
00:57:18.129695 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 24838, seq 240, length 64
00:57:18.131769 IP 189.87.a.b > 200.252.x.y: ICMP echo reply, id 24838, seq 240, length 64
00:57:19.131696 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 24838, seq 241, length 64
00:57:19.134235 IP 189.87.a.b > 200.252.x.y: ICMP echo reply, id 24838, seq 241, length 64
00:57:20.133691 IP 200.252.x.y > 189.87.a.b: ICMP echo request, id 24838, seq 242, length 64

Actions #1

Updated by Marcello Silva Coutinho over 6 years ago

It's happening with two different links on different vlans on the same realtek(re) interface.

Actions #2

Updated by Luiz Souza over 6 years ago

Can you post the ICMP packets transmitted by this HW ? (I need see the packets as they go on wire, packet captures on the same HW will not work, but you can capture the transmitted packets on gateway).

I need the output of something like 'tcpdump -vvvxxxnei your_NIC_name icmp'.

Actions #3

Updated by Jim Pingle over 6 years ago

  • Status changed from New to Not a Bug
  • Target version deleted (2.4.3)

Most likely the device on the other end doesn't like the small payload, in which case you can set the larger size and be done since it's specific to your own environment/gateway/upstream. I don't think there is an actual bug here. It works fine here on various (real and emulated) Intel NICs and Realtek NICs with and without VLANs for many thousands of other people.

Actions

Also available in: Atom PDF