On Feb 2, 2014 8:35 AM, "Jonathan Towne" <jtowne@slic.com> wrote:
The provider has kindly acknowledged that there is an issue, and are working on a resolution. Heads up, it may be more than just my region.
And not just your provider, everyone is dealing with UDP amp attacks. These UDP based amp attacks are off the charts. Wholesale blocking of traffic at the protocol level to mitigate 10s to 100s of gigs of ddos traffic is not "knee jerk", it is the right thing to do in a world where bcp 38 is far from universal and open dns servers, ntp, chargen, and whatever udp 172 is run wild. People who run networks know what it takes to restore service. And increasingly, that will be clamping ipv4 UDP in the plumbing, both reactively and proactively. And, i agree bcp38 would help but that was published 14 years ago. CB
-- Jonathan Towne
On Sat, Feb 01, 2014 at 11:03:19PM -0500, Jonathan Towne scribbled: # This evening all of my servers lost NTP sync, stating that our on-site NTP # servers hadn't synced in too long. # # Reference time noted by the local NTP servers: # Fri, Jan 31 2014 19:11:29.725 # # Apparently since then, NTP has been unable to traverse the circuit. Our # other provider is shuffling NTP packets just fine, and after finding an # NTP peer that return routed in that direction, I was able to get NTP back # in shape. # # Spot checking various NTP peers configured on my end with various looking # glasses close to the far-end confirm that anytime the return route is # through AS11351, we never get the responses. Outbound routes almost always # take the shorter route through our other provider. # # Is anyone else seeing this, or am I lucky enough to have it localized to # my region (Northern NY)? # # I've created a ticket with the provider, although with it being the weekend, # I have doubts it'll be a quick resolution. I'm sure its a strange knee-jerk # response to the monlist garbage. Still, stopping time without warning is # Uncool, Man. # # -- Jonathan Towne #