Description of problem:
traceroute ncorrectly reports MPLS information in ICMP unreachable as icmp
checksum wrong - this is a degression against the traceroute which was in 4.4.
This bug has been reported at the CentOS bugtracker:
Version-Release number of selected component (if applicable):
Run traceroute against google.com.
Steps to Reproduce:
[root@rootsserver ~]# traceroute google.com
traceroute: Warning: google.com has multiple addresses; using 220.127.116.11
traceroute to google.com (18.104.22.168), 30 hops max, 38 byte packets
4 xr-gar1-ge9-2.x-win.dfn.de (22.214.171.124) 3.491 ms 3.435 ms 3.987 ms
5 * * zr-fra1-te0-7-0-1.x-win.dfn.de (126.96.36.199) 11.641 ms
6 188.8.131.52 (184.108.40.206) 25.066 ms 25.133 ms 25.132 ms
7 220.127.116.11 (18.104.22.168) 21.357 ms 21.355 ms 21.694 ms
Icmp checksum is wrong
8 22.214.171.124 (126.96.36.199) 30.126 msIcmp checksum is wrong
29.449 msIcmp checksum is wrong
Icmp checksum is wrong
9 188.8.131.52 (184.108.40.206) 32.564 msIcmp checksum is wrong
220.127.116.11 (18.104.22.168) 111.575 msIcmp checksum is wrong
22.214.171.124 (126.96.36.199) 31.783 ms
Icmp checksum is wrong
[root@shutdown ~]# traceroute google.com
traceroute to google.com (188.8.131.52), 30 hops max, 40 byte packets
4 xr-gar1-ge9-2.x-win.dfn.de (184.108.40.206) 4.569 ms 3.777 ms 3.086 ms
5 * * *
6 220.127.116.11 (18.104.22.168) 26.119 ms 26.216 ms 26.202 ms
7 22.214.171.124 (126.96.36.199) 22.100 ms 22.115 ms 22.094 ms
8 188.8.131.52 (184.108.40.206) 30.037 ms 45.982 ms 45.978 ms
9 220.127.116.11 (18.104.22.168) 32.051 ms 22.214.171.124 (126.96.36.199)
33.915 ms 33.908 ms
10 188.8.131.52 (184.108.40.206) 112.327 ms 111.932 ms 111.944 ms
11 220.127.116.11 (18.104.22.168) 116.357 ms 116.672 ms 116.658 ms
12 22.214.171.124 (126.96.36.199) 129.488 ms 129.557 ms 128.343 ms
13 188.8.131.52 (184.108.40.206) 129.955 ms 130.039 ms 130.951 ms
14 220.127.116.11 (18.104.22.168) 142.687 ms 130.815 ms 130.053 ms
15 jc-in-f99.google.com (22.214.171.124) 130.016 ms 130.691 ms 129.482 ms
(traceroute from RHEL 5)
At my site I found that specifying a packet size of 72 or larger (99 is
convenient) seems to avoid the bug. This may serve as a temporary work-around
pending install of another version.
I can reproduce this.
It related to the previous epoch of the traceroute (1.4a).
All mine are >= 2.0.x :)
Try is it reproducable under RHEL5 or Fedora.
(In reply to comment #3)
> It related to the previous epoch of the traceroute (1.4a).
> All mine are >= 2.0.x :)
> Try is it reproducable under RHEL5 or Fedora.
That doesn't help for RHEL4 at all. And it worked before ...
true, and I can reproduce it as well... very annoying :(
I have now downgraded to the package on original RHEL4 and working fine again so
it must be a bug on traceroute.
Created attachment 308811 [details]
This bugzilla has Keywords: Regression.
Since no regressions are allowed between releases,
it is also being proposed as a blocker for this release.
Please resolve ASAP.
backing out patch #18 makes mpls info work
Created attachment 314534 [details]
The patch ensures the MPLS data are not included to the chk_sum function.
The MPLS data are added to the packets for routing purpose on the entry point of label switched network. This label should be taken away when the packet leaves this kind of network. Unfortunately the ICMP packets contain this label.
The patch detects real length of ICMP packet and didn't include MPLS to check sum calculation. This fixes the bug.
The MPLS stuff is supposed to be attached to the packet, please refer to RFC 4950
You are right. Thank you for your notice. There is an implementation of this RFC in the sources but it works after packet size definition on the command line:
traceroute google.com 140 (140 is necessary minimum for rel. 24)
This means that current traceroute-1.4a12-24.EL4.1.i386 works fine with this extra parameter:
- no "Icmp checksum is wrong" message
- MPLS packets are indicated in accordance to RFC 4950
This bug (#249001) will be fixed in next release increasing minimum packet size. This bug fix will fix also RFC 4950 compliance as a "side effect".
How about fixing the buffer patch which broke this in the first place?
That would be bug #164466 which is restricted to us mere mortals ;-)
my fix is an extension of mentioned buffer patch. I increased the minimal buffer size to allow receiving MPLS information.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.