Andre Chapuis wrote: > > Hi, > We are thinking about filtering on Upstream/Peers based on smallest > LIR allocations, like some ISP are already doing (SWITCH, Verio for > example) > This would reduce our Internet-table to 71602 !!!
You come almost to the same numbers as Philip Smith in his RIPE41 presentation on the routing table analysis: http://www.ripe.net/ripe/meetings/archive/ripe-41/presentations/ routing-rt-analysis/index.html However, the question is how much information do you want to lose? With this kind of limitation it's like CD vs. MP3. Unfiltered versus lossy compression. There are different ways of reducing the set of prefixes in the routing table, these different methods differ primarily by their amount of losing geniue prefixes: 1) Aggregate all more-specific prefixes if the origin-AS is the same 2) Aggregate all more-specifics and also aggregate the neighboring prefixes themselfes if the origin-AS is the *same* 3) Filter all more-specific prefixes if an aggregate exists even if the origin-as is not the same 4) Filter all prefixes which are longer than the RIR's minimum allocation sizes for a netblock Note that I use the terms aggregating and filtering to highlight what is actually happening in these cases. With *aggregating* you are *not* actually losing any prefix NLRI information. Whereas with *filtering* you *are* losing prefix NLRI information. Which means you might render certain networks unreachable via you. So cases 1 and 2 are just compacting the routing table without any loss of path and prefix informatin besides split-block traffic engineering. Cases 3 and 4 would remove prefixes from the routing table based on the policy. This leads to real loss of information and blackholes certain networks not fitting the RIR allocation and filter rules. The problem with these case comparsions is, where case 1 and 2 would be more correct to do, cases 3 and 4 are much easier to code in a ip prefix-list. Otherwise you have to do mucho route-map magic to let the router auto-aggregate. But we also have to take a look on the different types of ISPs and what this kind of filtering means to them. An ISP *not* providing transit to other AS or multi-homed customers (ie. SWITCH) is, besides the loss of some prefixes, not affected by this kind of aggregation. For them it doesn't really matter as long as there is any path to the destination. For an ISP providing *transit* to other AS and multihomed customers any of these cases has fatal effects on their ability to provide transit services. This is because more-specific wins! So lets take the case of a multihomed customer. You are doing this filtering and by that eliminating approx 35'000 prefixes from the routing table announced to the customer. The other ISP serving that customer is providing all prefixes unfiltered. What happens is that your path will loose far too often and much of the traffic will be carried by the other ISP. So multihoming is becoming pointless to a certain extent. In the end one question ramains; what is the purpose of this? Do your routers have problems carrying these many prefixes? Are your links or router CPU's overloaded because of so many announcements and withdrawls? Do want to set a net-political statement? After having said that I'd recommend to wait with any decision on this until after RIPE has finished their Multihoming Policy document which will describe and recommend multiple ways of multihoming. Among them is most likely a recommendation to use splits and announce them via multiple upstreams. Your proposed filter will break this though... > You can find the filter at the end of the mail, kindly formatted/ > provided by SWITCH (Thank you Simon) > What is the general feeling about a kind of 'common' politic for > Swiss ISPs ? > Who would be interested as well ? I'm all for a set of common policies of Swiss ISP's developed here on the SWINOG list (if common means that a majority will actually adopt it). This kind of commoness would make sense also for route flap dampening, or other issues like DDoS or SPAM/OpenRelay handling. For some issues it would be beneficial to follow the suggested values of RIPE and their working groups. Also it would make sense to forward the conclusions we've come to to the respective RIPE working group for consideration. > We would let the filters open for CH-peerings, in order for our > common multihomed customers using our PA assignments to have > redundancy of course. The problem is this multihoming won't work anymore if many ISP's also start doing this heavy filtering as you do... > I am currently asking our customers (and sub-customers) to respect > this (as far as possible...) > Currently in AS-SWCMGLOBAL we have 55 prefixes transgressing this > policy, but it should be easily reduced to a minimal set of > 'exceptions'; it is hard to incitate our peers to do it, and not > doing it ourselves... Yes ;-) -- Andre (AO6-RIPE) > Feedback is welcome !! > > Have a nice evening, > Andr� > > !!! Prefix list "martians" > !!! Match prefixes that people should *not* announce to us. > !!! To be used in a "deny" stance of an ingress route-map > !!! > !!! Date Created: 21-Nov-2001 > !!! RCS $Header: /common/cisco/tftp/pfl/RCS/pf-martians,v 1.5 2002/01/07 14:06:38 >leinen Exp $ > !!! > no ip prefix-list martians > !! Special-use address blocks - http://www.isi.edu/~bmanning/dsua.html > ip prefix-list martians permit 0.0.0.0/8 > ip prefix-list martians permit 10.0.0.0/8 le 32 > ip prefix-list martians permit 127.0.0.0/8 > ip prefix-list martians permit 169.254.0.0/16 le 32 > ip prefix-list martians permit 172.16.0.0/12 le 32 > ip prefix-list martians permit 192.0.2.0/24 le 32 > ip prefix-list martians permit 192.168.0.0/16 le 32 > !! RIPE - http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html > ip prefix-list martians deny 62.0.0.0/8 ge 9 le 19 > ip prefix-list martians deny 80.0.0.0/7 ge 9 le 20 > ip prefix-list martians deny 193.0.0.0/8 ge 9 le 24 > ip prefix-list martians deny 194.0.0.0/8 ge 9 le 24 > ip prefix-list martians deny 195.0.0.0/8 ge 9 le 20 > ip prefix-list martians deny 212.0.0.0/7 ge 9 le 19 > ip prefix-list martians deny 217.0.0.0/8 ge 9 le 20 > !! APNIC - http://www.apnic.net/db/min-alloc.html > ip prefix-list martians deny 61.0.0.0/8 ge 9 le 20 > ip prefix-list martians deny 202.0.0.0/7 le 24 > ip prefix-list martians deny 210.0.0.0/8 ge 9 le 20 > ip prefix-list martians deny 211.0.0.0/8 ge 9 le 20 > ip prefix-list martians deny 218.0.0.0/7 ge 9 le 20 > ip prefix-list martians deny 220.0.0.0/8 ge 9 le 20 > !! ARIN - http://www.arin.net/regserv/IPStats.html#cidr > ip prefix-list martians deny 24.0.0.0/8 le 20 > ip prefix-list martians deny 63.0.0.0/8 ge 9 le 19 > ip prefix-list martians deny 64.0.0.0/6 ge 9 le 20 > ip prefix-list martians deny 68.0.0.0/8 ge 9 le 20 > ip prefix-list martians deny 196.0.0.0/8 ge 9 le 24 > ip prefix-list martians deny 198.0.0.0/7 ge 9 le 24 > ip prefix-list martians deny 200.0.0.0/8 ge 9 le 24 > ip prefix-list martians deny 204.0.0.0/6 ge 9 le 24 > ip prefix-list martians deny 208.0.0.0/7 ge 9 le 20 > ip prefix-list martians deny 216.0.0.0/8 ge 9 le 20 > ! "Swamp" > ip prefix-list martians deny 192.0.0.0/8 ge 10 le 24 > ! Fall-through for undocumented ranges of historical Class A/B/C space > ip prefix-list martians deny 0.0.0.0/1 ge 8 le 19 > ip prefix-list martians deny 128.0.0.0/2 ge 8 le 19 > ip prefix-list martians deny 192.0.0.0/3 ge 10 le 19 > ip prefix-list martians permit 0.0.0.0/0 le 32 > end > > --------------------- > Andr� Chapuis > IP+ Engineering > Swisscom Ltd > Genfergasse 14 > 3050 Bern > +41 31 893 89 61 > [EMAIL PROTECTED] > CCIE #6023 > --------------------- > > ---------------------------------------------- > [EMAIL PROTECTED] Maillist-Archive: > http://www.mail-archive.com/swinog%40swinog.ch/ ---------------------------------------------- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
