Andre Chapuis wrote: > > I totally agree with you that a decision has to be thought about > carefully before being implemented. > > 1. and 2. would be great if every ISP would aggregate properly, > but quite difficult to achieve !
You could do that inbound instead of filtering. Problem is this is quite hard to do because of too much route-map magic. > Regarding 3. and 4.: What about asking Tier-1 provider/region to > originate big aggregates ?: This was once tried with IPv6 allocations. Didn't work out. Who qualifies as Tier-1? For example Telia is calling itself Tier-1, but IMHO isn't even close. > RIPE-delegated blocks like 62.0.0.0/8 could be announced by AS286, > AS702, AS5511, etc.. > ARIN-ones like 64.0.0.0/6 announced by 701,3561,1,1239, etc.. > APNIC-ones like 210/7 by AS 4637, etc > > Then 0/1, 128/2 and 192/3 could be annouced by every Tier-1, > and filtered out as wanted by every Tier-2 etc... I don't see what this gains. These large ISPs are not the default route for these ranges. This would fix todays ISPs size situation because one way or another you would be forced to have a feed with one of these "Tier-1" ISPs. Also you transport a lot more traffic because eventual unreachable packets wont be dropped at your default-free routers but at one of those Tier-1 ISPs. This opens whole new possiblilities for DDoS and SPAMers if they inject bogus routes. > Maybe it could be interesting interesting to achieve that for us > in CH, so that every ISP annouce the same within CH (of course > letting the CH-peerings quite open) This assumes that all Swiss ISPs are very good interconnected among each other. Which is not the case and your employer is one of the largest offenders in this regard. I haven't looked at all the allocations RIPE has made to Swiss ISPs, so I don't know how much you could aggregate among us. > I agree that for now we can live with 106'000 prefixes, but if > a solution is already planned and agreed, it can be implemented > rather quickly in case of a rapid increase of the Internet-table/ > DoS attack/huge flapping,... ? If everyone would implement "max-prefixes" and "route flap dampening" this wont be a problem at all. > We could define kind of a 'Swiss-table' with that, containing > only useful routing-info, according to the well-known > 'Swiss-quality', and propose that for multi-homed customers.. Again, this requires full cooperation among *all* Swiss ISPs which probably isn't going to happen. Take Teleglobe for example, they announced 80/8 for over three month, which is clearly wrong. Either they forgot a "ip classless" somewhere or some other problem. Anyway, not even calling them helped let alone emailing them... Sorry to say that but I guess a free market will not be able to make your vision happen. -- Andre (AO6-RIPE) > Have a nice day, > Andr� > > At 00:16 07.02.2002 +0100, Andre Oppermann wrote: > >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/ > > --------------------- > 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/
