BT Business Broadband suddenly dropping packets >1496 bytes

My company runs an OMA PoC service which uses UDP to send Presence ("user logged in") information to user terminals. We recently had complaints from some customers that it has stopped working, though other aspects of the system (voice, messaging, contact lists etc) continued to work. Presence stopped working in our office too when the terminal was connected over our BT Business Broadband connection, but continued to work with other carriers (Virgin, Vodafone 4G hotspot etc). I ran a ping test from our server to our office IP address (RedHat Linux so "ping -s <icmp-payload-size> <host IP>") and discovered that 1496-byte packets got through (payload=1468 + icmp header=8 + IP header=20) but 1500 byte packets (payload=1472) didn't. I changed the MTU on my server NICs from 1500 to 1492 to give a bit of headroom, and now I can "ping" with any payload size up to 35320 and, more importantly, the UDP Presence service is working again. This must be because my server network layer is fragmenting ICMP and UDP into IP frames up to 1492 bytes, and these are now getting all the way across The Internet from my server data centre to BT and through their infrastructure to my office. However, 1500 bytes packets can't make that journey via BT, though they still can through other carriers, so the outbound leg from my datacentre cannot be at fault.

My question is, what has changed to cause the to happen all of a sudden? It was fine at the start of last week then broke around Wednesday/Thursday. Has someone at BT installed a misconfigured router between my office and my datacentre so that in-flight IP packet fragmentation and reassembly no longer works? Or is there a hop with a 1496-byte MTU that didn't used to be there?

Another question: my BT Business Hub allows me to set the MTU, but only to a maximum 1492 bytes. Why is this? Are they hedging their bets? (Yes, I understand that this affects outbound packets, not inbound ones, so this won't be causing my fragmentation issue).

I can't answer your question but if you are going to cross post then please post one item and then link to it from the other forum rather than posting the same thing twice otherwise it gets very confusing as we will be potentially cross posting. For others this is also posted in Technical Issues

Thanks for the advice. Sorry. I did look for a crosspost capability but there didn't appear to be one.

No there isn't. The FAQs for the forum do advise against it but if you are going to do it then doing what I said is the only tolerated way

Anyway, welcome to the forum and hopefully someone will have thoughts on your question.

In reply to a post by kbro:

Another question: my BT Business Hub allows me to set the MTU, but only to a maximum 1492 bytes. Why is this? Are they hedging their bets? (Yes, I understand that this affects outbound packets, not inbound ones, so this won't be causing my fragmentation issue).

Normally the maximum MTU using PPPoE is 1492, which is the 1500 maximum MTU of Ethernet less the 8 byte length of the PPPoE header.

RFC 4638 allows MTU 1500 over PPPoE in certain circumstances. Openreach FTTC and FTTP supports RFC 4638, as do the Openreach FTTC modems and FTTP ONTs. Most, if not all, ISPs support RFC 4638. However, support in CPE (customer premises equipment, such as the Business Hub) is patchy. I don't know if the Business Hub is supposed to support RFC 4638 or not.


You cannot assume that the Internet at large is MTU 1500 clean. Fragmentation is an inelegant and sometimes unreliable solution. It's better to use Path MTU Discovery and, if that fails (as it sometimes does, especially because of over-aggressive blocking of ICMP), to assume a very conservative MTU for UDP based protocols of something like 1200.

Very clear. Thanks. So it looks like I was lucky that BT happened to support a 1500 MTU between the Backbone and my office, then unlucky that it dropped to 1496. Is it reasonable to expect that BT is "MTU 1492 clean" all the way to the Backbone, or is even that an assumption too far? I guess a noisy line on the final leg from the Exchange to my office might cause my modem (and theirs) to reconfigure themselves, but should their internal infrastructure stick to 1492?