Re: Whom do I complain about from this traceroute
cc-ed back to the list. please don't reply privately when the discussion belongs on the list. On Sat, Aug 04, 2012 at 08:14:26PM +1000, Mark Trickett wrote:
On Sat, 2012-08-04 at 08:59 +1000, Craig Sanders wrote:
On Fri, Aug 03, 2012 at 09:45:57PM +1000, Allan Duncan wrote:
It won't help you with your download problem, but it helps explain strange numbers when MPLS gets invovled.
well spotted.
But since I am not an Internode customer, I cannot get to that page. I
I meant well-spotted RE the fact of MPLS, not the particular web page. MPLS is something that is easily googled, whether you have access to one ISP's customer-only web pages or not. someone there will likely know wvdial and modem pppd configuration a lot better than I remember it (i haven't used a modem connection for over 10 years).
I think Mark has mentioned problems downloading the Linux Journal before. Makes me wonder what the MTU and MRU on his PPP interface is and whether he (or Telstra) is blocking ICMP packets (in particular ICMP Fragmentation Required msgs).
Tell me where to look, and how to set, and I will try.
you need to mru and mtu values in the pppd config file for your connection. e.g. /etc/ppp/peers/provider. the exact filename depends on your distro and what method you used to configure pppd in the first place (e.g. gui config, dialog text mode config, or just a text editor) see the man page for pppd and the network configuration documentation for your distro for details. you'll want to add lines like: mtu 600 mru 600
I am currently using wvdial, and want to know what options are passed to pppd.
no idea. i've never used wvdial.
I am also looking to migrate to a desktop running Debian 6, and would very appreciate some pointers to making use of "pon" and "poff", particularly just what is the minimal necessary to configure.
IIRC debian has a curses/dialog pppconfig tool for managing ppp configuration. dunno if they have a gui or not. the abominable gnome Network Manager may do ghastly things in the name of configuring pppd. dunno. vi has always been my configuration tool of choice.
I would also appreciate pointers to more advanced configuration. I need the modem link to be the default route, rather than any Ethernet interface.
1. don't have a gateway line in your ethernet configuration - that tells ifup that you want a default route pointing at the gateway mentioned. 2. add "defaultroute" to your ppp configuration. same place as you add the mtu and mru.
As commented, a little advice would be appreciated. I would also appreciate comments about how wvdial invokes pppd, and why when I use wget, I need to use the --no-proxy option to get anywhere at all.
no idea about wvdial but if you need to specify --no-proxy, that means you have a proxy set in either your environment (type: 'set | grep -i proxy' to check. use 'unset foo_proxy' to remove for the current running shell, edit your bashrc/bash_profile/etc files to remove permanently), or in your wget config. check ~/.wgetrc and maybe /etc/wgetrc. craig -- craig sanders <cas@taz.net.au>
Hello Craig, On Sun, 2012-08-05 at 23:28 +1000, Craig Sanders wrote:
cc-ed back to the list. please don't reply privately when the discussion belongs on the list.
I try to keep things on the list, but also try to not unduly clutter. I am still sorting out the balance point.
On Sat, Aug 04, 2012 at 08:14:26PM +1000, Mark Trickett wrote:
On Sat, 2012-08-04 at 08:59 +1000, Craig Sanders wrote:
On Fri, Aug 03, 2012 at 09:45:57PM +1000, Allan Duncan wrote:
It won't help you with your download problem, but it helps explain strange numbers when MPLS gets invovled.
well spotted.
But since I am not an Internode customer, I cannot get to that page. I
I meant well-spotted RE the fact of MPLS, not the particular web page.
There was a reference to a Cisco site. I visited, and have printed so I can try to get my head around. I will need to reread several times, along with chasing more introductory material.
MPLS is something that is easily googled, whether you have access to one ISP's customer-only web pages or not. someone there will likely know wvdial and modem pppd configuration a lot better than I remember it (i haven't used a modem connection for over 10 years).
There might be a few little items that "itch" if someone like myself asks questions. As to the pppd, I am looking at the configuration file, but finding that I can understand parts. Some of the rest is somewhat network technical in ways that I had not yet encountered.
I think Mark has mentioned problems downloading the Linux Journal before. Makes me wonder what the MTU and MRU on his PPP interface is and whether he (or Telstra) is blocking ICMP packets (in particular ICMP Fragmentation Required msgs).
Tell me where to look, and how to set, and I will try.
you need to mru and mtu values in the pppd config file for your connection. e.g. /etc/ppp/peers/provider. the exact filename depends on your distro and what method you used to configure pppd in the first place (e.g. gui config, dialog text mode config, or just a text editor) see the man page for pppd and the network configuration documentation for your distro for details.
you'll want to add lines like:
mtu 600 mru 600
Found, and uncommented where appropriate, and added 600 as the value. There are other things that I could not find, or misunderstand, such as enabling logging, and setting the default route. There is an entry that mentions proxy, but not quite certain of relevance. Quoting with leading comment follows. # Add an entry to this system's ARP [Address Resolution Protocol] # table with the IP address of the peer and the Ethernet address of this # system. proxyarp
I am currently using wvdial, and want to know what options are passed to pppd.
no idea. i've never used wvdial.
Looks like the contents of /etc/ppp/options is relevant, but does not include everything mentioned in the man pages. Still scratching my head, and getting splinters.
I am also looking to migrate to a desktop running Debian 6, and would very appreciate some pointers to making use of "pon" and "poff", particularly just what is the minimal necessary to configure.
IIRC debian has a curses/dialog pppconfig tool for managing ppp configuration. dunno if they have a gui or not. the abominable gnome Network Manager may do ghastly things in the name of configuring pppd. dunno. vi has always been my configuration tool of choice.
I am looking to at least not start Gnome Network Manager, probably also uninstall, but need to sort out exactly which packages to uninstall. As to vi, I do have the "vi cheat sheet" mug, but currently tending to use gedit. Meat space is where I am at, I want to get better practiced, but trying to keep an income stream from what I can do that is wanted locally. I am valued more for my physical activities at this stage, although I am feeling being over 50, and wanting to be less dependent on physical exertion.
I would also appreciate pointers to more advanced configuration. I need the modem link to be the default route, rather than any Ethernet interface.
1. don't have a gateway line in your ethernet configuration - that tells ifup that you want a default route pointing at the gateway mentioned.
2. add "defaultroute" to your ppp configuration. same place as you add the mtu and mru.
Thanks, noted, will be trying to sort out the desktop soon.
As commented, a little advice would be appreciated. I would also appreciate comments about how wvdial invokes pppd, and why when I use wget, I need to use the --no-proxy option to get anywhere at all.
no idea about wvdial but if you need to specify --no-proxy, that means you have a proxy set in either your environment (type: 'set | grep -i proxy' to check. use 'unset foo_proxy' to remove for the current running shell, edit your bashrc/bash_profile/etc files to remove permanently), or in your wget config. check ~/.wgetrc and maybe /etc/wgetrc.
Will go looking soon. One promising thing, the wget invocation is running well at the moment, I have been running the traceroute command periodically. The first four tries died early, before I issued the traceroute command. I am trying this because that was the difference when I managed to get 36% on a previous session, but with only one invocation. It appears to do something to the traffic that I do not understand.
craig
Regards, Mark Trickett
On 6 August 2012 21:31, Mark Trickett <marktrickett@bigpond.com> wrote:
Hello Craig,
On Sun, 2012-08-05 at 23:28 +1000, Craig Sanders wrote:
cc-ed back to the list. please don't reply privately when the discussion belongs on the list.
I try to keep things on the list, but also try to not unduly clutter. I am still sorting out the balance point.
On Sat, Aug 04, 2012 at 08:14:26PM +1000, Mark Trickett wrote:
On Sat, 2012-08-04 at 08:59 +1000, Craig Sanders wrote:
On Fri, Aug 03, 2012 at 09:45:57PM +1000, Allan Duncan wrote:
It won't help you with your download problem, but it helps explain strange numbers when MPLS gets invovled.
well spotted.
But since I am not an Internode customer, I cannot get to that page. I
I meant well-spotted RE the fact of MPLS, not the particular web page.
For those watching from the side lines, here's my summary of what the doco on the Internode site says: They firstly explain in a brief paragraph about how packet Time To Live (TTL) values work. Each time a packet is passed by a router the TTL value is decreased until it reaches zero. At that point the router making it zero discard the packet and send a message back to the originator saying it never reached its destination. It then explains how traceroute takes advantage of TTL by making use of deliberately low values that force intermediary routing devices to drop packets and send a response back to traceroute. This return response is used to calculate the response time. A simple example of 'normal' traceroute is given of tracerouting from Perth to Sydney via Adelaide. A packet with TTL of 1 is sent, gets to Adelaide and is dropped. Response sent from Adelaide back to Perth and round trip calculated at 30ms out + 30ms back = 60ms. A second packet is sent with TTL 2, passes Adelaide and gets to Sydney. Dropped at Sydney, response sent back, round trip time 100ms (30 + 20 + 20 + 30). Under MPLS that pathway is pre-calculated *before* a packet is ever sent. Once calculated a packet is more or less committed to following that path. Further, intermediate routers don't bother trying to calculate paths for packets that don't involve them "trying to stay as stupid as possible, avoiding any particular knowledge about how the various network endpoints are talking to each other." When one of these MPLS routers generates the TTL zero message that message is sent along the very same pathway as the originating packet. So in the Perth-Adelaide-Sydney example, when Adelaide gets the TTL=1 packet, the response message is sent via Sydney before returning to Perth. Hence the increased response times. HTH (or perhaps muddies the water further :^o ) -- Colin Fee tfeccles@gmail.com
Hello Craig, and others, On Mon, 2012-08-06 at 21:31 +1000, Mark Trickett wrote:
Hello Craig,
On Sun, 2012-08-05 at 23:28 +1000, Craig Sanders wrote: There was a reference to a Cisco site. I visited, and have printed so I can try to get my head around. I will need to reread several times, along with chasing more introductory material.
And still digesting.
I think Mark has mentioned problems downloading the Linux Journal before. Makes me wonder what the MTU and MRU on his PPP interface is and whether he (or Telstra) is blocking ICMP packets (in particular ICMP Fragmentation Required msgs).
Any comments about ICMP fragmentation setting would be appreciated, ie what to grep for and the like.
you need to mru and mtu values in the pppd config file for your connection. e.g. /etc/ppp/peers/provider. the exact filename depends on your distro and what method you used to configure pppd in the first place (e.g. gui config, dialog text mode config, or just a text editor) see the man page for pppd and the network configuration documentation for your distro for details.
you'll want to add lines like:
mtu 600 mru 600
Noticing changes with the MTU & MRU both set to 600, seems to be better, but that is subjective. I would appreciate comments about what metrics to look at, and how to collect.
I would also appreciate pointers to more advanced configuration. I need the modem link to be the default route, rather than any Ethernet interface.
1. don't have a gateway line in your ethernet configuration - that tells ifup that you want a default route pointing at the gateway mentioned.
2. add "defaultroute" to your ppp configuration. same place as you add the mtu and mru.
Thanks, noted, will be trying to sort out the desktop soon.
Now I need a bit more time at the keyboard, at the moment, work and trying to do things like get enough firewood to keep warm are more critical.
Will go looking soon. One promising thing, the wget invocation is running well at the moment, I have been running the traceroute command periodically. The first four tries died early, before I issued the traceroute command. I am trying this because that was the difference when I managed to get 36% on a previous session, but with only one invocation. It appears to do something to the traffic that I do not understand.
That wget invocation did work, after a fashion. I do have the entire current digital copy of Linux Journal, but the filename was mangled. I need to print the wget man page, and read carefully, several times. Why do I not need to tell wget to continue for some downloads, but do for others. There are also some strange things going on with the headers that the proffered invocation from a firefox plugin sets up. I shall have to look over and scratch my head yet again.
craig
Regards, Mark Trickett
On 08/10/2012 09:17 PM, Mark Trickett wrote:
Any comments about ICMP fragmentation setting would be appreciated, ie what to grep for and the like.
Well a good start is to try the tracepath program which will use PMTUD (Path MTU Discovery) to work out what is the largest packet that can can get to the destination. So here's an example going to my VM in the US, which gets throttled from an initial MTU of 1500 to 1492 at my ADSL router (hop 2): [chris@chris-laptop ~]$ tracepath csamuel.org 1: 192.168.1.112 0.449ms pmtu 1500 1: home.gateway.lan 16.306ms 1: home.gateway.lan 3.631ms 2: home.gateway.lan 3.560ms pmtu 1492 2: lns20.mel4.internode.on.net 47.293ms 3: te2-2.cor3.mel4.internode.on.net 46.315ms 4: gi7-1-0.bdr1.mel4.internode.on.net 220.653ms asymm 9 5: te5-0-0.bdr1.syd6.internode.on.net 220.674ms asymm 8 6: pos1-0-0.bdr1.lax1.internode.on.net 232.048ms 7: peering.la.us.iptransit.com 224.346ms 8: te2-2.r1.dal.us.iptransit.com 355.129ms 9: 204.26.63.166 284.330ms 10: ge-1-2.dal.rimuhosting.com 268.086ms 11: csamuel.org 257.300ms reached Resume: pmtu 1492 hops 11 back 54 If someone along the way is doing the wrong thing and blocking ICMP then I think you'll start to see 'no reply' after the bad hop. Best of luck! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
Chris Samuel wrote:
Well a good start is to try the tracepath program which will use PMTUD
Hmm, alpha is using PPPoA (to an onboard solos card). I thought PPPoA had a higher MTU than PPPoE... was that just my imagination? $ tracepath 8.8.8.8 1: twb.cyber.com.au 0.169ms pmtu 1500 1: alpha.cyber.com.au 0.822ms 1: alpha.cyber.com.au 0.845ms 2: alpha.cyber.com.au 0.733ms pmtu 1492 2: lns20.mel4.internode.on.net 57.287ms 3: te2-2.cor3.mel4.internode.on.net 69.936ms asymm 10 4: gi7-1-0.bdr1.mel4.internode.on.net 68.938ms asymm 11 5: te6-0-0.bdr1.mel6.internode.on.net 69.190ms asymm 10 6: te2-0-0.bdr1.cbr1.internode.on.net 68.989ms asymm 8 7: te6-0-0.bdr1.syd4.internode.on.net 69.242ms 8: no reply 9: no reply 10: no reply 11: no reply 12: no reply 13: no reply ^C
On 11/08/2012 12:48 AM, Trent W. Buck wrote:
Hmm, alpha is using PPPoA (to an onboard solos card). I thought PPPoA had a higher MTU than PPPoE... was that just my imagination?
Correct, PPPoA supports an MTU of 1500, but PPPoE has 8 more bytes of overhead, reducing this to 1492. There are lots of placebo anecdotes to argue the merits of either one.
On 11/08/2012 12:48 AM, Trent W. Buck wrote:
Hmm, alpha is using PPPoA (to an onboard solos card). I thought PPPoA had a higher MTU than PPPoE... was that just my imagination?
Correct, PPPoA supports an MTU of 1500, but PPPoE has 8 more bytes of overhead, reducing this to 1492.
There are lots of placebo anecdotes to argue the merits of either one.
And some ISP's blindly use an MTU of 1492 (or lower) anyway. If the OP is having trouble reaching an external website then a traceroute from the OP to the website isn't going to be that useful. What is required is a traceroute from somewhere with a 1500 byte MTU back to the OP to see if ICMP fragmentation required packets are being generated or if there is a PMTU blackhole. James
James Harper <james.harper@bendigoit.com.au> wrote:
On 11/08/2012 12:48 AM, Trent W. Buck wrote: Correct, PPPoA supports an MTU of 1500, but PPPoE has 8 more bytes of overhead, reducing this to 1492.
There are lots of placebo anecdotes to argue the merits of either one.
And some ISP's blindly use an MTU of 1492 (or lower) anyway.
I'm with Internode and using a Traverse Technologies Solos card with PPPoA. I had to reduce my MTU to 1496 bytes. Packets above 1496 never reached the destination - if I remember rightly, they didn't reach the gateway either. I don't know why, however.
On 11/08/12 16:37, Jason White wrote:
James Harper <james.harper@bendigoit.com.au> wrote:
On 11/08/2012 12:48 AM, Trent W. Buck wrote: Correct, PPPoA supports an MTU of 1500, but PPPoE has 8 more bytes of overhead, reducing this to 1492.
There are lots of placebo anecdotes to argue the merits of either one.
And some ISP's blindly use an MTU of 1492 (or lower) anyway.
I'm with Internode and using a Traverse Technologies Solos card with PPPoA.
AOL
I had to reduce my MTU to 1496 bytes. Packets above 1496 never reached the destination - if I remember rightly, they didn't reach the gateway either. I don't know why, however.
Blame their access network[1]. They really should not allow a PPP session to negotiate 1500 bytes but apparently some CPE fails if you limit MTU, they work around this in v4, but as I've pointed out to a few of their network people before they don't in v6 which makes things like YouTube suck for v6 enabled customers. Forcing link MTU is actually the right thing to do here. 1: For background see my LCA2012 sysadmin talk: http://www.youtube.com/watch?v=TYxPLEmbCuk
Jeremy Visser wrote:
On 11/08/2012 12:48 AM, Trent W. Buck wrote:
Hmm, alpha is using PPPoA (to an onboard solos card). I thought PPPoA had a higher MTU than PPPoE... was that just my imagination?
Correct, PPPoA supports an MTU of 1500, but PPPoE has 8 more bytes of overhead, reducing this to 1492.
There are lots of placebo anecdotes to argue the merits of either one.
So why does my transcript (upthread) indicate that alpha is PMTUDing it down to 1492?
On 10/08/12 21:17, Mark Trickett wrote: [...]
That wget invocation did work, after a fashion. I do have the entire current digital copy of Linux Journal, but the filename was mangled. I need to print the wget man page, and read carefully, several times. Why do I not need to tell wget to continue for some downloads, but do for others. There are also some strange things going on with the headers that the proffered invocation from a firefox plugin sets up. I shall have to look over and scratch my head yet again.
I find lftp a robust solution. You can use it as an interactive ftp client, but invoked with the "-f <script file>" argument is often more convenient as you can do all the setup stuff like cd-ing, and once written it can simply be tweaked and re-used over and over. Great for fetching the latest distro isos and checksums. It does preserve the filename and time stamp, and "get -c" will normally continue a broken download.
participants (10)
-
Allan Duncan -
Chris Samuel -
Colin Fee -
Craig Sanders -
James Harper -
Jason White -
Jeremy Visser -
Julien Goodwin -
Mark Trickett -
Trent W. Buck