On Feb 29, 2008, at 7:46 AM, David Ulevitch wrote:
The report states:
Sunday, 24 February 2008, 20:07 (UTC): AS36561 (YouTube) starts
announcing 208.65.153.0/24. With two identical prefixes in the
routing system, BGP policy rules, such as preferring the shortest
AS path, determine which route is chosen. This means that AS17557
(Pakistan Telecom) continues to attract some of YouTube's traffic.
It's worth noting that from where I sit, it appears as though none
of Youtube's transit providers accepted this announcement. Only
their peers.
A simple artifact of shortest AS path route selection. In addition,
many
providers employ policies that apply preference for prefixes learned
from
customers over those learned from peers, assuming they're of the same
length.
Had those same providers explicitly not accepted the /24 announcement
from AS 17557 via their peers you wouldn't have been affected at all.
The point is -- Restrictive customer filtering can also bite you in
the butt. Trying to require your providers to do a "ge 19 le
25" (or whatever your largest supernet is), rather than filters for
specific prefix sizes seems a worthwhile endeavor so you can de-
aggregate on the fly, as necessary.
Deaggregation in order to mitigate less specific route hijacking is a
hack
that in most cases only half fixes the problem, if that. If providers
didn't
have those policies in place it'd be /32s that were being hijacked and
route table growth and churn would be far worse than it already is.
You prevent this by ubiquitous deployment of explicit customer and
inter-
provider prefix filters, you don't open things up more so that when
problems
occur, folks can try to hack around them.
-danny
