BGP Filtering

Ben Butler ben.butler at c2internet.net
Tue Jan 15 23:02:13 UTC 2008


Hi,

It is late and am just checking email.  But...

The /24 is more specific than the /19 therefore the /24 take priority.

In my opinion AS path length became somewhat redundant with the rise of
confederations and BGP doesn't understand bandwidth, latency and
congestion.  But I didn't write it, I am not that clever and it works
and is what we have today.

But.... I don't care about the remote de-aggregating AS's local traffic
engineering, I care about the reach ability of the IP my customer has
requested, and the /19 is a valid route in the route table the origin AS
put it there and it is in my local transit feed.  Why should I pay in my
router for the degaregated AS's traffic engineering which doesnt benefit
me, I care about my transit and peers as long as the /19 is reachable.
Personally it is the deagregating ASs problem if they have poor transit
and peering not mine, maybe if they took ownership of their problem
rather than trying to make it everyone else's problem we would not find
ourselves in the mess we are currently in with no sign of the problem
diminishing or fixing itself.

This is not about my router or processor - it is fine thank you with
plenty of capacity transits and peers - but that doesn't excuse the
generation of dross in the table - I refuse to believe there are
justifiable reasons for anywhere near the majority of those 100K+
suspect routes.  As a  wide general rough rule of thumb, more specifics
(if any) for peering should only be getting announced to peers +
customers not back up into transit providers.  RIPE RIR rules don't
deagreagte - period - these ASs should not expect others to carry their
extra x prefixes just because they want to stretch the size of their
table in a router waiving contest.

I know I can dump them, for identical origination ASes, and things will
continue to work for me - the trick and my question is how to
dynamically classify them so that it is possible to think about dropping
them.  The question was how?  The answer is - seems it cant be done.
The main/best I have heard work around seems to be RIR minimum
allocation PA space filtering plus defaults to capture the very small
number of unique prefixes of PA less than minimum allocation size that
would get filtered - as I understand it, it is top of my reading list on
my desk tommorow.

The idea as much as possible is to go with what is in the routing table
not to pin default routes all over the place and to simply try and
"easily with minimum maintenance" drop a slice of the dross without
impacting customer experience.

Thank you to all who suggested solutions.

Ben

-----Original Message-----
From: Deepak Jain [mailto:deepak at ai.net] 
Sent: 15 January 2008 22:09
To: Ben Butler
Cc: nanog at merit.edu
Subject: Re: BGP Filtering

> But if I can see the /19 in the table, do I care about a load of /24s 
> because the whole of the /19 should be reachable as the origin AS is 
> announcing it somewhere in their network and it is being received my a

> transit so should be reachable.

The "presumption" in cases like this is that the /24 may take a
different path than the /19 in some or all cases. If you have only a
single provider you can safely dump more specifics -- but then, you
could just point default. If you *are* multihomed and the /19 and /24
both have the same primacy (first choice in a routing decision and same
path) you can safely drop the more specific.

The "presumption" is that in some cases the /24 would take a different
path than the /19 in a routing fight.

How much cost you want to incur for these is your choice. If enough
people drop the more specifics, they will go away as well -- if they
provided no benefit, fewer would exist.

Some of this originates from the peering-contests where folks have "x
number of prefixes" which makes them bigger than "y number of prefixes".

I'd be interested to see any metrics on rate of growth of allocations
longer than RIR limits since Verio instituted then dropped mandatory
prefix filters. (vs the rate of growth of prefixes overall). I would
guess that they accelerated.

Deepak



More information about the NANOG mailing list