One thing I noticed recently was that my firewall, running Linux, was getting a MTU of 576 bytes, instead of the normal 1500 bytes. This was being set by the Rogers DHCP server (option 26). 576 was common back in the days of non-error correcting modems, but hasn't been needed since then. If you're running dhcpcd, you can edit /etc/sysconfig/network/dhcp and change the line 'DHCPCD_USER_OPTIONS=""' to 'DHCPCD_USER_OPTIONS="-M"'. This will disable the DHCP MTU setting and use the configured MTU. Using a 1500 MTU will improve network efficiency, as 576 bytes will cause 3 packets to be sent, instead of 1, each with an IP header and also causes a lot more work for all the routers along the path. You can verify the MTU with a ping -s 1500 <destination>. If that works, then you have a 1500 byte MTU along the entire path to the destination. I found this because I was curious as to why the Ethernet port connected to the cable modem was not getting an IPv6 link local address. IPv6 requires a minimum MTU of 1280 bytes so, with 576, IPv6 wasn't allowed. I have advised Rogers of this and the person I was speaking to agreed it should be 1500. Let's see if they fix it.
On 4 January 2015 at 12:55, James Knott <james.knott@rogers.com> wrote:
If you're running dhcpcd, you can edit /etc/sysconfig/network/dhcp and change the line 'DHCPCD_USER_OPTIONS=""' to 'DHCPCD_USER_OPTIONS="-M"'. This will disable the DHCP MTU setting and use the configured MTU.
What does this pertain to? The router WAN side, router LAN side, or client machine(s)? My Internet connection, provided by Teksavvy, is on the Rogers cable network. Running ifconfig on my desktop machine I get: eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:xxx.xxx.xxx.xxx Bcast:xxx.xxx.xxx.255 Mask:255.255.255.0 inet6 addr: fe80::bexx:xxff:fexx:xxxx/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:260045 errors:0 dropped:0 overruns:0 frame:0 TX packets:221024 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:250671109 (250.6 MB) TX bytes:33714522 (33.7 MB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:20203 errors:0 dropped:0 overruns:0 frame:0 TX packets:20203 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2392082 (2.3 MB) TX bytes:2392082 (2.3 MB) -- Scott
On 01/04/2015 01:43 PM, Scott Allen wrote:
On 4 January 2015 at 12:55, James Knott <james.knott@rogers.com> wrote:
If you're running dhcpcd, you can edit /etc/sysconfig/network/dhcp and change the line 'DHCPCD_USER_OPTIONS=""' to 'DHCPCD_USER_OPTIONS="-M"'. This will disable the DHCP MTU setting and use the configured MTU. What does this pertain to? The router WAN side, router LAN side, or client machine(s)? Well, since I said Rogers DHCP, it's the MTU they assign to your firewall, for your connection to them.
My Internet connection, provided by Teksavvy, is on the Rogers cable network. Running ifconfig on my desktop machine I get:
eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:xxx.xxx.xxx.xxx Bcast:xxx.xxx.xxx.255 Mask:255.255.255.0 inet6 addr: fe80::bexx:xxff:fexx:xxxx/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:260045 errors:0 dropped:0 overruns:0 frame:0 TX packets:221024 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:250671109 (250.6 MB) TX bytes:33714522 (33.7 MB)
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:20203 errors:0 dropped:0 overruns:0 frame:0 TX packets:20203 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2392082 (2.3 MB) TX bytes:2392082 (2.3 MB)
In there, I was getting only a 576 byte MTU for eth0, even though the interface was configured for 1500. I also wasn't getting the IPv6 link local address. I guess Teksavvy is providing different config for their DHCP settings. You can verify this with Wireshark. You can force DHCP negotiation with "dhcpcd eth0 -n" so you don't have to wait for it to happen. You'll notice the 65536 MTU on lo. That's the maximum for IP, since there's no MTU limit on the loopback interface. Back when I was at IBM, where they used token ring, I set my MTU to about 4K, as I was often moving large files to/from local servers.
On 4 January 2015 at 12:55, James Knott <james.knott@rogers.com> wrote:
You can verify the MTU with a ping -s 1500 <destination>. If that works, then you have a 1500 byte MTU along the entire path to the destination.
My router says that the address of the gateway that it's connected to is 24.246.95.97. If I ping this address I get: $ ping -s 1500 24.246.95.97 PING 24.246.95.97 (24.246.95.97) 1500(1528) bytes of data. 1508 bytes from 24.246.95.97: icmp_seq=1 ttl=254 time=12.2 ms 1508 bytes from 24.246.95.97: icmp_seq=2 ttl=254 time=13.5 ms 1508 bytes from 24.246.95.97: icmp_seq=3 ttl=254 time=15.7 ms 1508 bytes from 24.246.95.97: icmp_seq=4 ttl=254 time=12.1 ms ^C --- 24.246.95.97 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 12.151/13.429/15.765/1.449 ms -- Scott
On 01/04/2015 01:54 PM, Scott Allen wrote:
On 4 January 2015 at 13:51, Scott Allen <mlxxxp@gmail.com> wrote:
My router says that the address of the gateway that it's connected to is 24.246.95.97. If I ping this address I get: I should have mentioned, the ping was from my desktop machine, not the router.
Shouldn't matter. If you are behind the firewall and it has only 576 to the Internet, then path MTU discovery will force the firewall to reject the packet and tell the computer to resize. You can also use Wireshark to verify the do not fragment flag is set. As an experiment, you might also try setting the MTU to 576 and trying that command again. https://en.wikipedia.org/wiki/Path_MTU_Discovery
On 01/04/2015 01:51 PM, Scott Allen wrote:
On 4 January 2015 at 12:55, James Knott <james.knott@rogers.com> wrote:
You can verify the MTU with a ping -s 1500 <destination>. If that works, then you have a 1500 byte MTU along the entire path to the destination. My router says that the address of the gateway that it's connected to is 24.246.95.97. If I ping this address I get:
$ ping -s 1500 24.246.95.97 PING 24.246.95.97 (24.246.95.97) 1500(1528) bytes of data. 1508 bytes from 24.246.95.97: icmp_seq=1 ttl=254 time=12.2 ms 1508 bytes from 24.246.95.97: icmp_seq=2 ttl=254 time=13.5 ms 1508 bytes from 24.246.95.97: icmp_seq=3 ttl=254 time=15.7 ms 1508 bytes from 24.246.95.97: icmp_seq=4 ttl=254 time=12.1 ms ^C --- 24.246.95.97 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 12.151/13.429/15.765/1.449 ms
That shows you have a 1500 byte MTU, so Teksavvy is doing things properly. Either they're saying to use 1500 or not using option 26 at all. Fire up Wireshark to see.
On 15-01-04 12:55 PM, James Knott wrote:
One thing I noticed recently was that my firewall, running Linux, was getting a MTU of 576 bytes, instead of the normal 1500 bytes. This was being set by the Rogers DHCP server (option 26). [snip] I have advised Rogers of this and the person I was speaking to agreed it should be 1500. Let's see if they fix it.
I am on Rogers and just checked my MTU setting after reading James' email. The ifconfig output reports an MTU of 1500. I didn't change any settings for DHCP. Rogers may have already fixed the problem. -- Cheers! Kevin. http://www.ve3syb.ca/ |"Nerds make the shiny things that distract Owner of Elecraft K2 #2172 | the mouth-breathers, and that's why we're | powerful!" #include <disclaimer/favourite> | --Chris Hardwick
On 01/04/2015 01:59 PM, Kevin Cozens wrote:
On 15-01-04 12:55 PM, James Knott wrote:
One thing I noticed recently was that my firewall, running Linux, was getting a MTU of 576 bytes, instead of the normal 1500 bytes. This was being set by the Rogers DHCP server (option 26). [snip] I have advised Rogers of this and the person I was speaking to agreed it should be 1500. Let's see if they fix it.
I am on Rogers and just checked my MTU setting after reading James' email. The ifconfig output reports an MTU of 1500. I didn't change any settings for DHCP. Rogers may have already fixed the problem.
Curious. I checked before I posted my original message and it was still 576. It may be a local issue. I'm on the Wolfedale domain, in Mississauga.
On 01/04/2015 01:59 PM, Kevin Cozens wrote:
On 15-01-04 12:55 PM, James Knott wrote:
One thing I noticed recently was that my firewall, running Linux, was getting a MTU of 576 bytes, instead of the normal 1500 bytes. This was being set by the Rogers DHCP server (option 26). [snip] I have advised Rogers of this and the person I was speaking to agreed it should be 1500. Let's see if they fix it.
I am on Rogers and just checked my MTU setting after reading James' email. The ifconfig output reports an MTU of 1500. I didn't change any settings for DHCP. Rogers may have already fixed the problem.
I just tried some more testing with my notebook computer. It uses the KDE network manager and appears to ignore the DHCP MTU value. However, I can only ping with up to 1472 bytes when connected to the cable modem. I get the same when I tether to my smart phone (Rogers), but get the full 1500 to a local computer on my network. I do not use DHCP option 26 on my DHCP server. It also doesn't appear to be used when tethered to my smart phone.
On 01/04/2015 03:30 PM, James Knott wrote:
On 01/04/2015 01:59 PM, Kevin Cozens wrote:
On 15-01-04 12:55 PM, James Knott wrote:
One thing I noticed recently was that my firewall, running Linux, was getting a MTU of 576 bytes, instead of the normal 1500 bytes. This was being set by the Rogers DHCP server (option 26). [snip] I have advised Rogers of this and the person I was speaking to agreed it should be 1500. Let's see if they fix it. I am on Rogers and just checked my MTU setting after reading James' email. The ifconfig output reports an MTU of 1500. I didn't change any settings for DHCP. Rogers may have already fixed the problem.
I just tried some more testing with my notebook computer. It uses the KDE network manager and appears to ignore the DHCP MTU value. However, I can only ping with up to 1472 bytes when connected to the cable modem. I get the same when I tether to my smart phone (Rogers), but get the full 1500 to a local computer on my network. I do not use DHCP option 26 on my DHCP server. It also doesn't appear to be used when tethered to my smart phone.
--- GTALUG Talk Mailing List - talk@gtalug.org http://gtalug.org/mailman/listinfo/talk $ ping -s 1500 acm.org PING acm.org (64.238.147.76) 1500(1528) bytes of data. 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=1 ttl=49 time=42.5 ms 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=2 ttl=49 time=44.1 ms 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=3 ttl=49 time=44.5 ms 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=4 ttl=49 time=44.2 ms 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=5 ttl=49 time=52.9 ms 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=6 ttl=49 time=44.1 ms ^C --- acm.org ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 5007ms rtt min/avg/max/mdev = 42.576/45.430/52.995/3.445 ms
From a different rogers subnet, I get a default of 56, successes with 1500-byte pings to the router and to the outside world, but failures internally talking to rogers DNS servers First, the dns server: $ cat /etc/resolv.conf # Generated by NetworkManager nameserver 64.71.255.204 nameserver 64.71.255.198 $ ping -s 1500 64.71.255.204 PING 64.71.255.204 (64.71.255.204) 1500(1528) bytes of data. ^C --- 64.71.255.204 ping statistics --- 19 packets transmitted, 0 received, 100% packet loss, time 17999ms $ ping 64.71.255.204 PING 64.71.255.204 (64.71.255.204) 56(84) bytes of data. 64 bytes from 64.71.255.204: icmp_seq=1 ttl=58 time=7.63 ms 64 bytes from 64.71.255.204: icmp_seq=2 ttl=58 time=7.35 ms ^C --- 64.71.255.204 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 7.350/7.492/7.635/0.166 ms Second, ACM.org $ ping -s 1500 acm.org PING acm.org (64.238.147.76) 1500(1528) bytes of data. 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=1 ttl=49 time=42.5 ms 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=2 ttl=49 time=44.1 ms 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=3 ttl=49 time=44.5 ms 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=4 ttl=49 time=44.2 ms 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=5 ttl=49 time=52.9 ms 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=6 ttl=49 time=44.1 ms ^C --- acm.org ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 5007ms rtt min/avg/max/mdev = 42.576/45.430/52.995/3.445 ms --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain
On 01/04/2015 07:21 PM, David Collier-Brown wrote:
From a different rogers subnet, I get a default of 56, successes with 1500-byte pings to the router and to the outside world, but failures internally talking to rogers DNS servers
I assume you meant 576, not 56. Do you see an IPv6 link local address on that interface? It starts with fe80.
First, the dns server: $ cat /etc/resolv.conf # Generated by NetworkManager nameserver 64.71.255.204 nameserver 64.71.255.198
$ ping -s 1500 64.71.255.204 PING 64.71.255.204 (64.71.255.204) 1500(1528) bytes of data. ^C --- 64.71.255.204 ping statistics --- 19 packets transmitted, 0 received, 100% packet loss, time 17999ms
$ ping 64.71.255.204 PING 64.71.255.204 (64.71.255.204) 56(84) bytes of data. 64 bytes from 64.71.255.204: icmp_seq=1 ttl=58 time=7.63 ms 64 bytes from 64.71.255.204: icmp_seq=2 ttl=58 time=7.35 ms ^C --- 64.71.255.204 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 7.350/7.492/7.635/0.166 ms
Second, ACM.org $ ping -s 1500 acm.org PING acm.org (64.238.147.76) 1500(1528) bytes of data. 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=1 ttl=49 time=42.5 ms 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=2 ttl=49 time=44.1 ms 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=3 ttl=49 time=44.5 ms 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=4 ttl=49 time=44.2 ms 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=5 ttl=49 time=52.9 ms 1508 bytes from ACMWEB16.acm.org (64.238.147.76): icmp_seq=6 ttl=49 time=44.1 ms ^C --- acm.org ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 5007ms rtt min/avg/max/mdev = 42.576/45.430/52.995/3.445 ms
This is similar to what I'm seeing. When I ping your DNS, I can do so with 1472, but not 1473 byte packets. I also see that 1472 limit from my notebook, but not my desktop, when going out to the Internet. I do not see it when pinging from my notebook to a computer on my local LAN. When pinging www.yahoo.com from my desktop system, I can ping with 1500 bytes. I'm not sure why 2 computers on my network get different results to Yahoo. Or where that 1472 limit is coming from.
On 01/04/2015 07:21 PM, David Collier-Brown wrote:
From a different rogers subnet, I get a default of 56, successes with 1500-byte pings to the router and to the outside world, but failures internally talking to rogers DNS servers
One other thing, are you seeing option 26 when examining the DHCP acks with Wireshark? If so, what MTU size? The capture filter I use is "port 67 or port 68" to capture both sides of the request & ack.
On 01/04/2015 01:59 PM, Kevin Cozens wrote:
On 15-01-04 12:55 PM, James Knott wrote:
One thing I noticed recently was that my firewall, running Linux, was getting a MTU of 576 bytes, instead of the normal 1500 bytes. This was being set by the Rogers DHCP server (option 26). [snip] I have advised Rogers of this and the person I was speaking to agreed it should be 1500. Let's see if they fix it.
I am on Rogers and just checked my MTU setting after reading James' email. The ifconfig output reports an MTU of 1500. I didn't change any settings for DHCP. Rogers may have already fixed the problem.
What area are you in and did you try ping -s 1500?
On 15-01-04 05:18 PM, James Knott wrote:
On 01/04/2015 01:59 PM, Kevin Cozens wrote:
I am on Rogers and just checked my MTU setting after reading James' email. The ifconfig output reports an MTU of 1500. I didn't change any settings for DHCP. Rogers may have already fixed the problem.
What area are you in and did you try ping -s 1500?
I'm in Markham. The ping command outputs lines that start with 1508. -- Cheers! Kevin. http://www.ve3syb.ca/ |"Nerds make the shiny things that distract Owner of Elecraft K2 #2172 | the mouth-breathers, and that's why we're | powerful!" #include <disclaimer/favourite> | --Chris Hardwick
| From: James Knott <james.knott@rogers.com> | One thing I noticed recently was that my firewall, running Linux, was | getting a MTU of 576 bytes, instead of the normal 1500 bytes. 576 is the smallest legal MTU for IPv4. I could imagine some system defaulting to this in the absence of other knowledge. In other messages you show that this is an explicit setting from Rogers' DHCP server. That certainly sounds like a bad configuration at their end. My Rogers connection has an MTU of 1500. The normal (non-jumbo) MTU size for ethernet is 1500. ADSL uses PPPoE encapsulation which eats 8 bytes off the MTU. | You can | verify the MTU with a ping -s 1500 <destination>. If that works, then | you have a 1500 byte MTU along the entire path to the destination. Not quite. "ping -s 1500" on IPv4 generates a 1508-byte ICMP packet. Plus any encapsulation that might be used (probably none with Rogers). Elsewhere you mention PMTU discovery. The folk wisdom (as of a few years ago) was that this is useless since so many routers and firewalls drop the necessary ICMP messages. Sad. | I have advised Rogers of this and the person I was speaking to agreed it | should be 1500. Let's see if they fix it. Wow. Years ago I tried to report DHCP RFC violations to Rogers customer support folks and got nowhere. There seemed to be no connection between the customer support department and the relevant engineering department.
On 01/04/2015 11:42 PM, D. Hugh Redelmeier wrote:
| From: James Knott <james.knott@rogers.com>
| One thing I noticed recently was that my firewall, running Linux, was | getting a MTU of 576 bytes, instead of the normal 1500 bytes.
576 is the smallest legal MTU for IPv4. I could imagine some system defaulting to this in the absence of other knowledge.
In other messages you show that this is an explicit setting from Rogers' DHCP server. That certainly sounds like a bad configuration at their end.
Yes, I verified option 26 was set to 576 in the DHCP acks.
My Rogers connection has an MTU of 1500.
The normal (non-jumbo) MTU size for ethernet is 1500.
ADSL uses PPPoE encapsulation which eats 8 bytes off the MTU.
| You can | verify the MTU with a ping -s 1500 <destination>. If that works, then | you have a 1500 byte MTU along the entire path to the destination.
Not quite. "ping -s 1500" on IPv4 generates a 1508-byte ICMP packet. Plus any encapsulation that might be used (probably none with Rogers).
I've been wondering about that too. From my desktop computer, I can ping Yahoo with 1500, but from my ThinkPad, only 1472. But from that same ThinkPad, I can ping a local computer with 1500. I'll have to investigate that more.
Elsewhere you mention PMTU discovery. The folk wisdom (as of a few years ago) was that this is useless since so many routers and firewalls drop the necessary ICMP messages. Sad.
Take a look at your outgoing packets and you'll likely see the do not fragment flag is set. This means that if you hit a lower bandwidth link your packets will be dropped. So, I don't know how many are blocking those ICMP messages. Certainly no responsible carrier would. Blindly blocking them shows more ignorance than anything. Also, since IPv6 doesn't allow fragmentation, PMTUD is mandatory with it.
| I have advised Rogers of this and the person I was speaking to agreed it | should be 1500. Let's see if they fix it.
Wow.
Years ago I tried to report DHCP RFC violations to Rogers customer support folks and got nowhere. There seemed to be no connection between the customer support department and the relevant engineering department.
I also got the brush off from the support tech, who didn't even know what MTU was. However, I shortly after received a survey email. I replied, expressing my dissatisfaction. I then heard back from someone who agreed that the MTU shouldn't be set to 576. In fact, they shouldn't be setting it at all.
| I have advised Rogers of this and the person I was speaking to agreed it | should be 1500. Let's see if they fix it.
Wow.
Years ago I tried to report DHCP RFC violations to Rogers customer support folks and got nowhere. There seemed to be no connection between the customer support department and the relevant engineering department. Customer support is there to make you happy with what you bought. Accepting that anything is wrong flies in the face of that mission,
On 01/04/2015 11:42 PM, D. Hugh Redelmeier wrote: therefor support people are usually forbidden to accept bug reports. At Honeywell, if you weren't in the right department, you had to be a director to file bugs. Only QA and the sales force could report bugs, and the latter would only do so when it sounded like it would cost money. To this day, it's always best to report bugs to your salesperson. --dave My current employer has a customer outreach department, instead: they regularly report bugs. -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain
participants (5)
-
D. Hugh Redelmeier -
David Collier-Brown -
James Knott -
Kevin Cozens -
Scott Allen