Home page logo
/

nanog logo nanog mailing list archives

Re: using IRR tools for BGP route filtering
From: Jeff Haas <jeffhaas () merit edu>
Date: Fri, 23 Jun 2000 10:37:40 -0400


On Thu, Jun 22, 2000 at 02:39:27PM -0600, Danny McPherson wrote:
If a provider performed prefix filtering on their peers, the policies would
need to be auto-generated from some database, a la IRR or the like.  This 
used to be a problem not long ago, when things such as sequenced prefix lists
(with incremental update support), and BGP route refresh didn't exist.  Today,
however, they do.  The problem is that the data in the IRRs is stale -- at 
best,

Perhaps this should serve as a small head's up.

One side effect of the RADB maintainer object fee is that stale objects
from unowned maintainers will be purged from the RADB.  This will probably
happen Real Soon Now.

One planned use of the planned Route Server extensions (RSng++) is
to allow real-time correlation of routing data against the totality
of the IRR.  This will likely result in a publicly accessible
database of what the Route Servers have seen in the global routing
mesh.  For completeness, such a database may also include views from
other routers.  One possible use for such a database is an report similar
to the CIDR report showing non-registered routes.

A development schedule for the new features has not been set yet.

the associated infrastructure isn't necessarily production quality, the routers
can't store the policies, much less perform matches in a reasonable manner,

If the routers aren't able to handle this then people should start
putting pressures on their router vendors.  I would be curious if the
various router vendors have benchmarked their route filtering mechanisms
and published it anywhere.

As a data point, most of the existing route servers at the RSng maintained
exchange points are Sun Ultra-1 hosts (some are Alphas) with up to
512M of memory (the MAE's) and as little as 256M in other locations.
The amount of memory required is (roughly) proportional to the number of
routes received and the number of views the route servers has.

A "normal" router wouldn't require nearly this amount of memory since
normal routers do not maintain the idea of a "view" - just a pool of
routes and policy filters for incoming and outgoing policy.  Additionally,
current RS prefix filters waste space since RSd requires duplicate
ACLs in a given policy filter, even if they are identical in several
places within the file.  (Scheduled to be fixed.)

The mae-east route server has 60 views, and receives an average of
70K routes from about the same number of peers.  Mae-West has 56 views
and about 57K routes.  At these loads the RS's still has memory to
spare.

With the current inefficiencies in RSd it is still able to converge
over 60 views in less than 2 minutes.  Much of the time it takes
for things to converge is due to the fact that when a peer is dropped
it takes a while for it decide to come back.  (The route server
reconfig process is another thing that needs work - both in re-processing
the prefix filters, and also BGP soft reconfigs.)

My point is that although the route servers can be considered to be
underloaded by the number of routes available from the number of
peers we have (i.e. we're not receiving a full Internet view from
each peer), convergence time is still good on an Ultra 1.  And I'm
pretty sure that I'm running more prefix filters than almost anyone
else on this list.  (45M for Mae-East.)

Most people's prefix filters are targeted towards "Here is the routes
I expect you to send me and here are the routes I want to send you."
This protects one's network and one's downstream customers.  However,
such filters can be HUGE and contain many duplicate prefixes.

In a perfect world where the IRR was sufficiently populated, one should
need one prefix filter to protect against blackholing:
"Are these people allowed to originate this block?  Are these people
allowed to originate this aggregate?"  The IRR (as viewed from the
RADB host) currently contains 153K route objects - including all
stale data.  Simply filtering on origin AS and prefix (or aggregator
AS and aggregate prefix) provides a large chunk of the safety-net
filtering that people are looking for.  It doesn't prevent sub-optimal
routing, but it helps prevent people from injecting stupid things
into the mesh.

Unfortunately, most policy filtering mechanisms aren't optimized to
this simplified case.  Perhaps it needs to be worked on.

-danny

-- 
Jeffrey Haas - Merit RSng project - jeffhaas () merit edu



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault