bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-inetutils] Bug Report


From: Noel Lamothe
Subject: [bug-inetutils] Bug Report
Date: Fri, 16 Dec 2016 10:23:37 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1

I'm not sure if you're aware, but I've noticed an interesting flaw in traceroute. See, I have 2 different DSL modems strung together with MLPPP in order to render me the kind of speed that I need in order to stream 1080p HD from the internet. When my server is using only one of the two DSL modems to connect to the internet, traceroute works just fine. The moment that my server connects through the second modem as well to bridge them together with MLPPP into a single line with twice the speed, traceroute doesn't work in the normal manner, and I have to use the "-I" switch to make it work. I will show you what I mean...


Regular Traceroute

address@hidden:~$ traceroute teksavvy.com
traceroute to teksavvy.com (173.246.155.216), 64 hops max
  1   192.168.0.1  1.522ms  2.102ms  1.682ms
  2   *  *  *
  3   *  *  *
^C
address@hidden:~$


ICMP Traceoute

address@hidden:~$ traceroute -I teksavvy.com
traceroute to teksavvy.com (173.246.155.216), 64 hops max
  1   192.168.0.1  1.448ms  1.343ms  1.328ms
  2   206.248.154.121  20.653ms  20.873ms  19.120ms
  3   69.196.136.172  19.718ms  18.726ms  20.327ms
  4   206.248.155.14  18.669ms  20.504ms  18.592ms
  5   173.246.155.216  20.498ms  18.635ms  18.996ms
address@hidden:~$


Now here's where it gets interesting... if I SSH into my server to try the same traceroute directly from the server (which is what uses MLPPP to bridge the two lines together), I get the following


Regular Traceroute

address@hidden:~$ traceroute teksavvy.com
traceroute to teksavvy.com (173.246.155.216), 30 hops max, 60 byte packets
 1  206.248.154.121 (206.248.154.121)  20.550 ms  20.499 ms  20.975 ms
 2  ae0-2150-bdr01-tor.teksavvy.com (69.196.136.172)  21.454 ms  21.434 ms  22.160 ms
 3  ae8-0-bdr01-tor2.teksavvy.com (206.248.155.9)  25.120 ms ae1-0-agg01-tor2.teksavvy.com (206.248.155.14)  25.100 ms  25.964 ms
 4  cdn.teksavvy.com (173.246.155.216)  25.945 ms ae0-2170-agg01-tor2.teksavvy.com (192.171.59.98)  27.422 ms cdn.teksavvy.com (173.246.155.216)  29.902 ms
address@hidden:~$


ICMP Traceroute

address@hidden:~$ sudo traceroute -I teksavvy.com
[sudo] password for noel:
traceroute to teksavvy.com (173.246.155.216), 30 hops max, 60 byte packets
 1  206.248.154.121 (206.248.154.121)  17.870 ms  20.200 ms  20.193 ms
 2  ae0-2150-bdr01-tor.teksavvy.com (69.196.136.172)  21.304 ms  21.497 ms  24.044 ms
 3  ae1-0-agg01-tor2.teksavvy.com (206.248.155.14)  24.037 ms  25.528 ms  25.899 ms
 4  cdn.teksavvy.com (173.246.155.216)  28.763 ms  28.747 ms  30.120 ms
address@hidden:~$

Do you have an explanation for this, and is there a way to fix this, or is it a flaw to using MLPPP? I'd really like to know so that I can adjust whatever I need to adjust to make it work normally, without being forced to use the ICMP method. I'm very puzzled as to why this is, and I would really appreciate it if it could be fixed, or if this cannot be fixed (due to something with MLPPP), if I at least had an explanation for what happens. I'm just so confused as to how MLPPP can create this much issue with a traceroute, considering that both modems should be connecting to the same gateway.


--



-----------------------
Noel Lamothe

address@hidden
www.tech911solutions.com
Home: 519-489-0448 (Kitchener, ON)
Home (alt): 519-512-0459 (Brantford, ON)
Home (alt): 716-566-9547 (Buffalo, NY)
Fax: 519-489-4739 (Kitchener, ON)
Fax (alt): 519-512-0936 (Brantford, ON)
Cell: 519-998-8944
BBM PIN: D3AFF4AA



reply via email to

[Prev in Thread] Current Thread [Next in Thread]