FTTC - wierd MTU issues

Im have a strange problem with my FTTC connection. The Openreach modem seems to drop down to almost zero through put when it has been connected for a couple of days. Web browsing no longer becomes possible however from command promt you can ping any domain name as usual. It not an issue with my router as it also does it using the modem connected directly to a PC.

When the problem occurs ive found the the maximum packet size seems to drop lower and lower, and effectively it seems like port 80 is blocked also.Power cycling the Openreach modem fixes the problem for a couple of days.

As a start point I wondered if someone with FTTC could tell me the maximum packet size they can ping to bbc.co.uk?

My connection is working well at the minute after a modem reboot and the maximum packet size is 1464. Yesterday I had throughput problems and it dropped to a max of 1422 that could be pinged.

Any thoughts?


C:\Users\Paul Brown>ping -l 1464 bbc.co.uk

Pinging bbc.co.uk [212.58.241.131] with 1464 bytes of data:
Reply from 212.58.241.131: bytes=1464 time=30ms TTL=245
Reply from 212.58.241.131: bytes=1464 time=30ms TTL=245
Reply from 212.58.241.131: bytes=1464 time=32ms TTL=245
Reply from 212.58.241.131: bytes=1464 time=30ms TTL=245

Ping statistics for 212.58.241.131:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 30ms, Maximum = 32ms, Average = 30ms

C:\Users\Paul Brown>ping -l 1465 bbc.co.uk

Pinging bbc.co.uk [212.58.241.131] with 1465 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 212.58.241.131:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

You have MTU = 1492.

Ensure MTU settings in router & PC (if you ever changed it) are 1500.

Do the ping with 'ping -f -l nnnn bbc.co.uk'. Find largest nnnn for which it doesn't need fragmentation.

Then add 28 to get MTU.

Thanks for the reply xray. Makes sense, on my Draytek router the max MTU setting is 1498 which ties in with what im currently getting then.

So moving on why would this drop so I can only send smaller packets when the problem is occuring? throughput reduces to almost zero

Edited by Ripley (Sun 15-Jul-12 23:37:12)

Don't forget that PPPoE uses 8 bytes more than PPPoA (added by the router), so the MTU on the PC should be set to 8 less than on the router.

A bit more here.

1500 on the router and 1492 on the PC should work fine...

Thanks I will do that.

Still interested to know why the maximum packet size would reduce when this problem occurs for me, then a reboot of the Openreach FTTC modem fixes the problem...

The BT routers actually have it set to 1492 ...

Quite possibly.

That may be because most BT users aren't likely to be particularly tech-savvy, but may have heard that the MTU on the PC should not be greater than on the router. So, for the user who has a little (possibly dangerous) knowledge, if it fibs a little bit everything gets set properly

In reply to a post by MHC:

The BT routers actually have it set to 1492 ...

As does my Netgear WNR1000 v 3 router as suplied by Plusnet to go with the OR Hg612 modem for my FTTC connection.

I am Running Windows 7 that apparently auto-adjusts accordingly to suit the connection.

Hmmm ?

My Buffalo is set to its default of 1500. I'm not aware of a problem, but perhaps I have one I'm not aware of?

What downside could this be causing please?

I manage to get;

mailgate:~$ ping -D -s 1468 bbc.co.uk
PING bbc.co.uk (212.58.241.131): 1468 data bytes
1476 bytes from 212.58.241.131: icmp_seq=0 ttl=246 time=21.889 ms

and then;

mailgate:~$ ping -D -s 1469 bbc.co.uk
PING bbc.co.uk (212.58.241.131): 1469 data bytes
Request timeout for icmp_seq 0
36 bytes from ae1.er01.thdow.bbc.co.uk (132.185.254.18): frag needed and DF set (MTU 1514)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 d905 64cf 0 0000 37 01 42da 192.168.16.20 212.58.241.131

So the largest packet from the LAN I get a reply to from bbc.co.uk is 1468 bytes

I get responses to bigger pings still on other sites;

mailgate:~$ ping -D -s 1470 www.ox.ac.uk
PING www.ox.ac.uk (163.1.60.42): 1470 data bytes
1478 bytes from 163.1.60.42: icmp_seq=0 ttl=51 time=28.839 ms

1470 bytes is reproducibly the largest packet I can send out from the LAN and get a response although some sites won't respond at this size.

The MTU of the client (Mac Mini) I'm using is 1500, the firewall is 1500 and the router has no MTU set at all.

From the router directly I get;

caffn8me-gw#ping
Protocol [ip]:
Target IP address: www.ox.ac.uk
Repeat count [5]:
Datagram size [100]: 1498
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 1498-byte ICMP Echos to 163.1.60.42, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/26/28 ms

This is the maximum from the router to www.ox.ac.uk but there may be sites with an even higher limit.

I believe the Openreach modem has a maximum MTU of 1600 bytes on ethernet (see here) and as far as I know the specification for BT's FTTC network doesn't set a limit for MTU. If I can find the specification I read previously I'll post a link.

The BT Business routers actually look at the connection ADSL/VDSL and decide what to set it at.

Dont you mean PC should be 8 higher than router to cater for the 8 bytes added by router?

So 1492 at router and 1500 at PC.

Many routers, not just BT, max at 1492; many OSs default to 1500.

Router makers would not impose this limit if the maths were your way round.

In reply to a post by RobertoS:

Hmmm ?

My Buffalo is set to its default of 1500. I'm not aware of a problem, but perhaps I have one I'm not aware of?

What downside could this be causing please?

If your PC's MTU is higher than the MTU of the router, then you send large packets to the router that the router has to fragment before sending on to the DSL line. This gives the router CPU more work to do than if the packets originate at the correct size.

Windows Vista, and 7 have automatic Path-MTU adjustment, so *should* be recognising this automatically and adjusting.

1500 is the max MTU size for ethernet (without jumbo frames) which is why operating systems come set with this value at the start.

Corporates who use VPNs often lower the MTU on the network cards (wired & wireless can be separate) to allow for the encapsulation of the packet.

So on Win 7 the downstream should be fine, but messy on upstream? My standby XP machine needs checking?

Edited by RobertoS (Mon 16-Jul-12 08:38:40)

In reply to a post by XRaySpeX:

Dont you mean PC should be 8 higher than router to cater for the 8 bytes added by router?

No. I think you're misunderstanding MTU- it's the maximum size of a frame that the device can handle or create.

So if the PC sends a frame which is larger than the setting of MTU on the router, the router will need to fragment it before sending it on. This will slow things down, partly because more frames (hence higher overhead/payload ratio) will need to be sent and partly because the router has to do more work.

To avoid this, the basic rule that the PC MTU should not be larger than the router MTU is valid, but an extension of that is to allow for any extra that the router may need to add. Not a problem for PPPoA because it doesn't.

All that goes out the window if the router (and the ISP) can handle jumbo frames, but not all of them can so it's safest to assume that they don't.

In reply to a post by Ripley:

Still interested to know why the maximum packet size would reduce when this problem occurs for me, then a reboot of the Openreach FTTC modem fixes the problem...

No idea about the first, but rebooting the modem will drop the connection so a new session has to be authenticated, negotiated and set up from scratch. Whether that is a clue I couldn't say, but next time it happens try manually disconnecting and reconnecting via the router interface to see if it has the same effect.

If it does then it would appear to be something related to the duration of the session, though I've no idea how, why or at which end the problem lies

Oops, forgot this bit (more coffee needed...)

In reply to a post by XRaySpeX:

Many routers, not just BT, max at 1492

Maybe so, but it doesn't change the rules- in order to avoid fragmentation the PC MTU should not be higher than the router MTU.

You'll have to ask the router manufacturer/supplier if you want to know why they do it.

many OSs default to 1500

That's the maximum allowed by Ethernet, so fair enough.

Edited by billford (Mon 16-Jul-12 09:14:25)

In reply to a post by RobertoS:

So on Win 7 the downstream should be fine, but messy on upstream? My standby XP machine needs checking?

Shouldn't be - there is only a single MTU per adapter.

MTU on my router is set to 1454 - I've never changed it to my knowledge. Maximum size from the ping before fragmentation is 1426, which makes sense. On my PC network adapter it's set to 1500. Should I be setting the router to 1492 (maximum allowed) and the PC to 1464? Does it really matter? I'm not experiencing any problems AFAIK.

Edited by kasg (Mon 16-Jul-12 09:56:07)

In reply to a post by kasg:

Should I be setting the router to 1492 (maximum allowed) and the PC to 1464?

Playing with the values might be worth a try, but I'd leave the router at 1454 (because of the max before fragmentation of 1426 that you've found) and drop the PC to 1446 (1454 minus 8). And see if anything improves.

If it doesn't then put everything back the way it was, following the even more basic rule that if it ain't broke, don't fix it

Your low maximum value on the router may be due to something else in the routing that doesn't like "full size" frames.

In reply to a post by billford:

Playing with the values might be worth a try, but I'd leave the router at 1454 (because of the max before fragmentation of 1426 that you've found)

Thanks - but I thought the maximum size before fragmentation of 1426 was because the router MTU was set to 1454, borne out by the fact that now I've changed it to 1492 as an experiment, the max size before frag is 1464.

In reply to a post by kasg:

Thanks - but I thought the maximum size before fragmentation of 1426 was because the router MTU was set to 1454, borne out by the fact that now I've changed it to 1492 as an experiment, the max size before frag is 1464.

Ah, right, I didn't realise that.

It might be worth worth trying 1500 on the router, 1492 on the PC to see if that works, but any improvement in performance is going to be so slight that it'll likely be swamped by normal internet variability and I'd be inclined to leave it where it is

As a (slightly) side issue- in general it's better to have the highest value of MTU that will work, but some sites don't like "big" ones- I think Microsoft may have had this oddity at one time. So it can be worth sacrificing a (tiny) bit of performance in case you happen to come across another one.

I found this out big time when I was using an Airport Extreme's built in 6to4 tunnel for IPv6- that adds a lot of overhead, and quite a few sites wouldn't respond to a tunneled connection if the frames were fragmented... eventually I got fed up and just set the computer's MTU to the minimum allowed (~1328 iirc)

Yes, I know all that.

I was trying to understand your statement "PPPoE uses 8 bytes more than PPPoA (added by the router)" and relating this to the relative sizes of MTU (the 'M' does stand for "Max") on router and PC.

It's as if you are saying that a packet comes over the ADSL cable (PPPoA) from exchange and the router adds 8 bytes in order to pass it over the Ethernet cable (PPPoE) to PC. Thus the packet is bigger at the PC than on the ADSL. Therefore the MTU at the PC needs to be bigger than the MTU at the WAN i/f of router.

Then your statement "the MTU on the PC should be set to 8 less than on the router" doesn't follow and is a contradiction.

"there is only a single MTU per adapter. "

Sort of.

The user specified per-adapter one is the maximum maximum, nothing on that adapter can or will exceed this.

But in the bigger picture there is Path MTU discovery, where traffic to a given destination (via a given route) may have another smaller MTU, which may supercede (for that path) the per-adapter value.

Good game, innit.

In reply to a post by XRaySpeX:

Yes, I know all that.

I was trying to understand your statement "PPPoE uses 8 bytes more than PPPoA (added by the router)" and relating this to the relative sizes of MTU (the 'M' does stand for "Max") on router and PC.

Yes, and the 'T' stands for 'Transmission'... so you were ignoring the direction of the traffic.

The PC assembles the frame and then sends it to the router, which adds 8 bytes before sending it off to the modem for conversion to whatever the ATM requires. (Whether it adds these bytes if it's LAN traffic I don't know).

It's the job of the PC and router to ensure that the frames it creates meet Ethernet requirements, for incoming traffic the size of the frame is what it is and the router and PC just have to make the best of it. If it's greater than that allowed by the Ethernet specs then I assume it will get dropped.

In reply to a post by billford:

sends it to the router, which adds 8 bytes before sending it off to the modem for conversion to whatever the ATM requires.

Where the 8 bytes are removed cuz "PPPoA uses 8 bytes less than PPPoE"?

Otherwise PPPoA is using 8 more bytes than came from PC over Ethernet (PPPoE)?

Perhaps please clarify where the extents of these Point-to-Point Protocols apply?

In reply to a post by XRaySpeX:

Perhaps please clarify where the extents of these Point-to-Point Protocols apply?

As far as I'm aware- from router to modem to modem to router, ie whilst it's going over the internet. Once the data is within an Ethernet network they don't apply.

(edit- I think, not sure, that they would also apply between two LANs, each of which required its own authentication, IP assignment, traffic monitoring etc etc. ie it's used over an inter-net connection, not only "the internet")

But all the modem does is to convert signals between one form and another (Ethernet and ATM), it doesn't do any processing on the data carried by those signals so it has to be correctly assembled first. By the end which is sending (transmitting) them.

Edited by billford (Mon 16-Jul-12 14:12:08)

I said earlier that for incoming traffic the router has to make the best of what it gets- there's also an MRU (Maximum Receive Unit) set in a router, but not normally available to the user (afaik).

It should be 1500 to handle any legal Ethernet frame, but it can be set to a lower value. If a a frame arrives that is larger than the MRU then the routers won't be able to communicate, I've had this happen in the past on occasional sites.

In reply to a post by Anonymous:

"there is only a single MTU per adapter. "

Sort of.

The user specified per-adapter one is the maximum maximum, nothing on that adapter can or will exceed this.

But in the bigger picture there is Path MTU discovery, where traffic to a given destination (via a given route) may have another smaller MTU, which may supercede (for that path) the per-adapter value.

Good game, innit.

Yep agreed - not all OSes support Path MTU discovery (PMTU) correctly - and whats worse many *security* products break it as well (they tend to block the ICMP status returns or block the outbound ICMP requests).

As others have said some routers always assume PPPoE is in use and have a limited MTU to 1492 which in the UK with PPPoA on normal ADSL at 1500 shouldn't be needed - but for FTTC on WBC networks using PPPoE then I guess the 1492 makes sense.

Sky FTTC doesn't use PPPoE as they use IPoA (similar to BE) with their proprietory authentication and TalkTalk no idea.

Getting back to your Q ....

When you observe your maximum packet size reducing does the lower size +1 need fragmentation when you do 'ping -f -l nnnn bbc.co.uk'?

You did ping w/out '-f' earlier and that just timed out. I can't see that as a lowering of MTU cuz it should still be able to fragment.

In reply to a post by billford:

Yes, and the 'T' stands for 'Transmission'... so you were ignoring the direction of the traffic.

Yes, I had always taken it to mean being in transit; a bidirectional operation.

Now that you made it clear that the MTUs at our end relate only to our uploads, I wonder why when some people have trouble or delay with loading pages or other downloads, that a change of MTU can often fix it.

In reply to a post by XRaySpeX:

In reply to a post by billford:

Yes, and the 'T' stands for 'Transmission'... so you were ignoring the direction of the traffic.

Yes, I had always taken it to mean being in transit; a bidirectional operation.

Ah, getting the TLA wrong... I've done that myself a few times!

Now that you made it clear that the MTUs at our end relate only to our uploads, I wonder why when some people have trouble or delay with loading pages or other downloads, that a change of MTU can often fix it.

It can explain why pages on a specific site won't ever load- the MRU at the far end is (incorrectly) set too low, so your MTU won't fit in it (hence your requests never arrive), but why it sometimes fixes an occasional problem I don't know... my suspicion is that it's not the MTU at fault but something else that clears the problem when the router restarts with the new value.

Can't prove it though

In reply to a post by billford:

It can explain why pages on a specific site won't ever load- the MRU at the far end is (incorrectly) set too low, so your MTU won't fit in it (hence your requests never arrive), but why it sometimes fixes an occasional problem I don't know... my suspicion is that it's not the MTU at fault but something else that clears the problem when the router restarts with the new value.

Or they've screwed up a firewall and blocked fragmented packets (as they think its a security feature). Making your packets smaller so they don't get fragmented can get around this (sometimes).

In reply to a post by jchamier:

Sky FTTC doesn't use PPPoE as they use IPoA (similar to BE) with their proprietory authentication and TalkTalk no idea.

...or slightly more correctly Sky use "1483 MER with DHCP Option 61"

Not the TLA itself, but the meaning of what it abbreviates

I guess it's worth mentioning that BT don't use ATM on VDSL2 so PPPoA doesn't apply. BT use PTM instead.

In reply to a post by simon194:

In reply to a post by jchamier:

Sky FTTC doesn't use PPPoE as they use IPoA (similar to BE) with their proprietory authentication and TalkTalk no idea.

...or slightly more correctly Sky use "1483 MER with DHCP Option 61"

I think 1483 is IPoA - at least in the routers I've used the two are used interchangeably and "MER" is the Sky name for the DHCP Option 61 oddity that I called "proprietory authentication"

In reply to a post by BatBoy:

I guess it's worth mentioning that BT don't use ATM on VDSL2 so PPPoA doesn't apply. BT use PTM instead.

PTM ? I thought BT used PPPoE on WBC FTTC lines?

My Buffalo:-

Method of Acquiring IP Address
Auto Detect Mode - PPPoE

In reply to a post by RobertoS:

My Buffalo is set to its default of 1500.

Where did I get that from? It's rot. (Looks like it's ignored when the easy setup option is used. Which it was).

MTU Size 1454

Oh and re the PMT. That's littered all over the modem GUI.

In reply to a post by jchamier:

In reply to a post by BatBoy:

I guess it's worth mentioning that BT don't use ATM on VDSL2 so PPPoA doesn't apply. BT use PTM instead.

PTM ? I thought BT used PPPoE on WBC FTTC lines?

This is directly from the modem's stats on my VDSL2/FTTC connection:-

"G.992.3_Annex_K_PTM"

The modem's GUI also reports:-

Mode: VDSL2
Traffic Type: PTM

Edited by deleted (Tue 17-Jul-12 09:30:30)

In reply to a post by RobertoS:

MTU Size 1454

So what's the significance of 1454? That's what my ZyXel was set to until I changed it yesterday.

Edited by kasg (Tue 17-Jul-12 09:44:17)

Dunno, but that seems to be what it's own line analysis chose. I may have a look at the Plusnet Netgear some time and see what that is set at.

In reply to a post by Bald_Eagle1:

In reply to a post by jchamier:

In reply to a post by BatBoy:

I guess it's worth mentioning that BT don't use ATM on VDSL2 so PPPoA doesn't apply. BT use PTM instead.

PTM ? I thought BT used PPPoE on WBC FTTC lines?

This is directly from the modem's stats on my VDSL2/FTTC connection:-

"G.992.3_Annex_K_PTM"

The modem's GUI also reports:-

Mode: VDSL2
Traffic Type: PTM

PTM is just the transfer mode the modem is using to communicate over the DSL link.

The HH connects to the modem and authenticates using PPPoE.

In reply to a post by RobertoS:

Dunno, but that seems to be what it's own line analysis chose. I may have a look at the Plusnet Netgear some time and see what that is set at.

If it's the same as my Netgear WNR 1000v3 as supplied by Plusnet for my FTTC connection, it will be 1492.

Edited by deleted (Tue 17-Jul-12 12:01:26)