Internet anarchy: I’ll advertise whatever I like

We all know that the global BGP table is exploding (see the Active BGP entries graph) and that it will eventually reach a point where the router manufacturers will not be able to cope with it via constant memory/ASIC upgrades (Note: a layer-3 switch is just a fancy marketing name for a router). The engineering community is struggling with new protocol ideas (for example, LISP) that would reduce the burden on the core Internet routers, but did you know that we could reduce the overall BGP/FIB memory consumption by over 35% (rolling back the clock by two and a half years) if only the Internet Service Providers would get their act together.

Take a look at the weekly CIDR report (archived by WebCite on June 22nd), more specifically into its Aggregation summary section. The BGP table size could be reduced by over 35% if the ISPs would stop announcing superfluous more specific prefixes (as the report heading says, the algorithm checks for an exact match in AS path, so people using deaggregation for traffic engineering purposes are not even included in this table). You can also take a look at the worst offenders and form your own opinions. These organizations increase the cost of doing business for everyone on the Internet.

Why is this behavior tolerated? It’s very simple: advertising a prefix with BGP (and affecting everyone else on the globe) costs you nothing. There is no direct business benefit gained by reducing the number of your BGP entries (and who cares about other people’s costs anyway) and you don’t need an Internet driver’s license (there’s also no BGP police, although it would be badly needed).

Fortunately, there are some people who got their act together. The leader in the week of June 15th was JamboNet (AS report archived by Webcite on June 22nd) that went from 42 prefixes to 7 prefixes.

What can you do to help? Advertise the prefixes assigned to you by Internet Registry, not more specific ones. Check your BGP table and clean it. Don’t use more specific prefixes solely for primary/backup uplink selection.


  1. While a good amount of this is likely inefficient policy, there is at least one solid excuse for advertising deaggregated routes: it mitigates address space hijacking (in my opinion, a vastly underestimated threat). Until upstream BGP filtering is made more consistent across providers worldwide, this will continue to be a motivator.
  2. @Stretch: I have to disagree. There are free or commercial services that can alert you when you address space is being hijacked.

    Unfortunately the only short-term response you have available to combat the hijack is the advertisement of deaggregated /24s, but that does not warrant announcing deaggregated routes by default.
  3. Badly managed internet connections advertising more specifics "unnecessarily" have no motivation to NOT do so.

    Moreover, it is human nature in such an enviroment as the Internet that some people will have zero Internet Etiquette.

    So rather than solve the unsolvable (changing human nature) why not come up with a solution that accounts for this "anti-social" behaviour.

    i.e. don't try and change the world try and get solutions that fit the world.

    Bad Designer (de-aggregating since 1924)
  4. @Bad Designer: nice to hear from you after a long time :) Any ideas about the solutions?
  5. The solution is in transit networks, as usual. Either due to absence of clue, will or lazyness, most of them implement no consistent filtering policies. If all carriers would by default filter at RIR-allocation boundaries for each of their customers, we would have much happier world.

    Alas, many of these transit carriers fit into what Bad Designer talked about.
  6. Unfortunatly alot of cases come down to money - the root of most problems. Lets say you can afford 2 GE connections to the Internet. You need to load share since you have more than 1G of traffic so you deaggregate your blocks. If you could afford 2 10GE, you could do active/passive with no deaggregation. Now imaging this problem spread across several POPs with several Internet connections. You know the problem exists. You want to fix it but you can't get money to buy larger pipes... What do you do?
  7. @Marko: look at the worst offenders in the Aggregation summary. They are definitely not customers.
  8. @Anonymous: If you're talking about a multihomed customer: they are excluded from the report (and gains estimate) because AS path of deaggregated prefixes would not be the same ... unless Geoff Huston's claims about his reporting software are incorrect ;)
  9. @Ivan: Detection is great, but it does absolutely nothing to mitigate an attack. Responding by injecting more granular routes as you mention is a purely *reactionary* measure; damage has already been done by this point. Many organizations, where inaccessibility is measured in millions of dollars per minute, simply aren't willing to risk the hours of downtime that a potential attack (accidental or otherwise) could cost.

    As I said, the only presently available solution for this is to raise confidence in the filtering undertaken by major autonomous systems across the globe; obviously not an easy thing to do.
  10. I am on the SP side, and while advertising aggregated routes is the normal procedure,there are always overriding imperatives . More specific routes is the easiest and fastest way of load manipulation. E.g. if some major
    client is having problems with latency going through upstream provider A , easiest way to
    get him satisfied is to advertise more specific
    prefix through SP B as a temporary solution.
    BTW SPs abroad do the same thing in advertisings to us , so ...
  11. If registrars would hold a field for "upstreams" a customer could register what ASes they (may) advertise to. Using this information any AS path could be evaluated for consistency or hijacks.

    Much like providers today who don't bother to use prefix-list to filter what a customer can advertise to them, it would rely on the providers to be upstanding netizens, but it would at least make the information available to providers who wished to take such steps to prevent hijacking.
  12. More on this is that upstream uses local preference to utilize their directly connected clients links,,,
    means if you are advertising a /19 prefix to Level3 and same prefix to France telecom and as-path prepend to France telecom for /19 will not work as local preference will be first attribute to be in consideration @ france telecom and traffic will continue on that link for france telecom directly clients,,,

    unless you play with more complex BGP community attributes :'(
  13. There are ways to get around this problem (although complex). However, as I wrote in the post, the traffic engineered prefixes are not included in the report (because, if you do it right, they would have different AS paths).
Add comment