Re: "You can't block Akamai, or you block legitimate and well behaved services"
It is a shared tenants' connection, so we can't simply block Akamai.
4 publicly visible posts • joined 8 Jun 2016
Pretty much any patch management server will. However, not everyone has this and in my instance I have a router in the basement of a multi-tenant building sharing a fibre connection. The tenants are all connecting to my router via PPPoE and they all receive a public IP. The router does fair queueing and prioritises VOIP. For two years it has worked like a dream and usage graphs show that the link is often saturated for a good part of a working day, yet phone calls are crystal clear and no complaints about speed.
I haven't seen any other traffic causing an issue. It is specifically the update process and it is the inbound traffic that runs amok. I thought it might be a flood of syn acks as I had seen a huge surge in connections (several thousand in several seconds) that then died down. However, the packet trace I took whilst the problem was occurring seem to indicate that the connections are fully open and the sending server (Akamai) is just hammering the external interface even though the router is dropping packets to try to throttle the connections back.
I posted the original article on Whirlpool. What makes it particularly nasty is that it is all done on port 80. Presumably Microsoft want their updates to work even when users are behind diligent sysadmins' firewalls. This is doubly nasty. You can't block port 80 or you block browsing. You can't block Akamai, or you block legitimate and well behaved services. I am hoping I can find a header identifier in the traffic that I can use to block the Windows 10 / Office 2016 updates at layer 7 for now.
I just hope people who can fix this at the source are taking notice and do something about it. They are breaking the Internet....literally.