4 ms·
"or the rule itself was in error" I thought that the rule was in error: I couldn't read the rule clearly on the screen, but it seemed, or I guessed, that the
by graycat 14y ago
"or the rule itself was in error"
I thought that the rule was in error: I couldn't read the rule clearly on the screen, but it seemed, or I guessed, that the problem with the rule was that the "humans" omitted the decimal points and, thus, asked for blocking packets with lengths 1000 larger than intended. The Juniper software got sick, i.e., allocated too much memory, only because it was trying to swallow working with such absurdly large packet sizes. But, then, I couldn't clearly read the screen capture with the rule.
- scoot 14y agoThe rule matched the output of the profiler, so in that sense was correct. It wasn't clear from the article whether the profiler output was correct, a result of intentionally malformed packets, or otherwise. Regardless, the Juniper should either have rejected the rule, or accommodated it.
- imbriaco 14y agoIt's pretty clear that it was a failure of CloudFlare's profiler in generating an obviously impossible rule, the engineer who attempted to apply that rule, and Juniper for allowing it. There's no one place to lay blame, nor is it relevant. I would imagine that while we have seen a public reason for outage statement that there is a lot more work going on inside CloudFlare as far as the post-mortem is concerned. There are a lot of angles to cover here to really understand how the _system_ failed.
- eastdakota 14y agoYup.