[c-nsp] Filtering /24s

[Håkan Lindholm]

Short version: Presentation found at http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt

Sorry for not saying "Yes" XOR "No" below.


Kim Onnel wrote:
> Hello,
> 
> I really would like to understand your post if you have time
> to answer, i always get confused, i dont think i can
> understand reading about routing policies rather than doing
> it, please help.

No problem.  I was very brief, and my english may not be the best :)


> I'll try to make it easier by asking yes/no questions and
> please add your /* commens if needed.
> 
> He is receiving the Full table from his upstream, which of
> course is heavy because of memory and CPU (BGP scan)
> constrains, so he is thinking of filtering all /24 from the
> full table.

No, not exactly filter ALL /24.

Yes, he want a lighter BGP table. But he want all prefixes from the upstreams to choose from. The filtering is done at the border.  It will need some CPU there, but memory will be saved in ALL of his BGP routers.



> Now if he did this, how will he reach all those /24s, through
> the aggregates ? lets assume that the network 1.1.1.0/24 is
> assigned to an ISP in Egypt (i'm from Egypt) by UUNet and
> they own the 1.1.0.0/16, our friend here is in Asia (for
> e.g.) and now that he filtered the route to Egyptian ISP /24,
> packets sourced from his customers will look-up the table and
> find the /8 and send it to UUnet who will happoly deliver it,
> am i getting this right or not ? ( could there be loops or delays ?)

No, he will not send it to UUNet, unless UUNet is his upstream.  And even if UUNet is among his upstreams (let's hope he got at least two upstreams), he might send it to some other upstream, based on some policy (AT&T might be cheaper).

Yes, any of his upstreams will deliver it if the destination is in the BGP table. Each ASN makes its own decision (each router actually). Upstreams get paid for delivering data. There will be no loops unless you have something else than a usual upstream setup.


> 	> As long as you have default routes it should work.
> 
> 
> You are suggesting not receiving the full table and only
> default route?

That was not my comment.  Some people think default routes are nice to have.  I don't, because that route will cover a lot of unused IP addresses.



> 	> You'll not have as fine grain of control as well but
> 	> for that type of config it shouldn't make a big difference.
> 
> 	For a leaf ASN, you only need some routes from each
> 	upstream, and you probably care more about local/regional
> 	prefixes than global ones (no	pun intended).
> 
> 
> Is leaf ASN, a customer with no registered ASN and multihomed ?

A leaf ASN is an ASN with no downstreams, only upstreams.

No, it has an ASN.
Yes, it is multihomed.



> Why would he care more about local ?

Because most traffic is local these days.  YMMV.



> 	But I wouldn't dare dropping all /24 just by looking at
> 	their size.  As 240k or 256k FIB limitations are common
> 
> 
> What does the above mean, are you saying that most of the
> table is /24 ?

In 2004, at least 71k out of 115k prefixes where /24.
http://www.potaroo.net/presentations/2004-05-01-allocation-vs-announcement.ppt#19

Today ("Prefix Length Distributions" at http://bgp.potaroo.net/as4637/) almost 100k out of 180k are /24.




> 	and the global BGP table will be
> 	there in a few years (no need for further discussions
> 	on that topic here),
> 
> 
> Please point me to this topic ?

Looks like most of what I've seen on this topic has been on the Nanog list.

It has been a hot issue at least since 2001:
http://www.cctec.com/maillists/nanog/historical/0104/msg00034.html

Some quite recent thread at http://www.merit.edu/mail.archives/nanog/msg16336.html





> 	I've also been looking into that topic.
> 
> 	Some west central (maybe Austria or Switzerland)
> 	european ISP made a presentation somewhere, IIRC,
> 	about their method.  Off the top of my head, I
> 	remember only a few details like:
> 
> 
> PLEASE get me this presentation or anything i can google

Finally found it at http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt
(http://www.google.com/search?q=swisscom+upstream+bgp+filter)



What someone else already posted to the list is http://www.ip-plus.net/technical/route_filtering_policy.en.html  But with that, he still recommends a default route.

Number of prefixes left in my table would be <80k out of ~180k.
Number of kept /24's is 24k out of 98k. This is even better than the 60k/125k achieved by Swisscom in 2003.



> 	* Keep all prefixes received from national peering.
> 	* Keep most european prefixes.
> 	* Point non-regional /8 agg's at your upstream(s).

Swisscom did have both EU and US upstreams. They have semi-default (/7 and /8) routes, for RIPE space pointing at their EU upstream(s), for other RIR's space pointing at the US upstream(s).



> So the above are methods you remember, like filtering the
> routing table to only networks from the region (why) and no
> only receive /8 networks ?
> 
> Please explain this part.

Because you have (at least I think most of us have) most of your traffic to destinations (ISPs) in your own country, or at least within your own region (Egypt might be a special case - on the border between regions).

For "my" own ASN, I use netflow to keep track of which ASN's are most common destinations. Some french language services have users in Morocco and Canada, all the rest are inside EU.  You might have that kind of "french traffic" to/from Egypt as well I guess :)



> 	For the /8 stuff, there might be several ways to do it. /8's, or
> 	maybe longer, just not /24's, will be a lot better than
> 	default route(s) when you get traffic to/from unallocated space.
> 	For Europe, non-regional would be APNIC, AfrNIC, ARIN, LACNIC
> 	(etc?). Special attention for ERX prefixes..
> 
> 
> What do you mean by ERX ?

ERX - Early Registration Xfer. Transfer of early IP allocation records from ARIN to RIR's. http://www.arin.net/registration/erx/



> 	They ended up at 40k to 70k prefixes. Far better than
> 	the full table of 100k to 150k, at that time.

By 2003, they ended up at 60-65k, when the full table was 125k.



> 	If someone remebers some URL for this pres., please
> 	submit to the list. The original presentation is far
> 	better than my memory.

Google is better than my memory :)   I really tried Google yesterday as well, but not successfully until today.



Please note that the rest of this mail is about a different way to solve a similar, maybe it's the same, problem.


> 	Another popular approach is to have your upstream send
> 	only their customer prefixes, and use one of them as
> 	"default-network".  Or filter by community. But I just
> 	don't like the 0/0 default.
> 
> 
> You are saying that his upstream should send him their
> customers routes only and then he should match them as set
> default route manually to these customers ?

If you get some prefix from both upstreams, you can use the "ip default-network" command to use its destination as default gateway. http://www.cisco.com/warp/public/105/default.html for more details.

I think you can use "ip route 222.0.0.0 254.0.0.0 <any upstream common customer ip>" to make semi-defaults dependant on BGP.



> what will he benefit from that ?
> Please explain this last one too if possible, i want to know
> how things are done outhere ?

If you have two upstreams, the path to a customer will be shorter if you send it directly to the upstream you have in common.  It is also a very common set of prefixes to announce - upstreams knows exactly how to do it. In a lot of cases, these prefixes will be local and/or regional.

/H