Indeed, in a perfect world, a route server would be the solution. But what always beats me in these situations is that the upstreams of ASes where these problems occur don't seem to be prefix filtering. Given the complexity of interdomain routing configs, misconfigurations by less experienced operators are to be expected, and to a certain extent can be forgiven. But it is hard to tolerate the behaviour of (supposedly) clueful upstreams who don't protect themselves and the rest of the Internet by having prefix filters on their downstream customers. It seems that the current state of the IRR and the supporting tools are in general simply too complex for a lot of people to get to grips with ... which includes me - we build ours manually :-( Perhaps the DNS based origin authentication proposal would have more success. We can only hope. Phil At 13:53 08/04/98 -0400, Abha Ahuja wrote:
Or maybe, use a route server!
-abha ;)
On Wed, 8 Apr 1998, philip bridge wrote:
Seems like...
http://www.academ.com/nanog/feb1998/origin.html
...is long overdue.
Phil
At 02:53 PM 4/7/98 -0400, Mr. Dana Hudes wrote:
It is such accidents that reinforce the notion of per-prefix filtering. Of course if one changes one's IRR/RIPE DB/RADB entries to deliberately announce the world there could still be a problem with auto-generated accept policy. The solution to *that* is quality assurance of the database, an ongoing issue in RIPE DB WG at least.
Even then how does one prevent someone coding 'ANY' for their announce policy when they should not? In the old NFSNET days human inspection of IRR entries assured quality but that's not practical anymore at a central registry.
sure, one has accept policy but other than excluding RFC1918 and your own address space and default you have no practical choice but to reference the other guy's aut-num object and the associated routes.
Dana Hudes Graphnet
Bernhard Kroenung wrote:
At the Moment AS4000 / AS8584 is announcing the whole internet :-(
For programming the cuise-missiles or SS20's - here is the data :
aut-num: AS8584 descr: Barak AS as-in: from AS4000 10 accept ANY as-in: from AS5585 100 accept ANY as-out: to AS4000 announce AS8584 as-out: to AS5585 announce AS8584 default: AS4000 10 admin-c: AS261-RIPE tech-c: AS261-RIPE mnt-by: AS8584-MNT changed: ashor@barakitc.co.il 971126 source: RIPE
person: Amir Shor address: Barak I.T.C. address: 15 Ha-Melacaha St. address: Rosh Ha-Ayin 48091, Israel phone: +972 3 9001082 fax-no: +972 3 9001090 e-mail: ashor@barakitc.co.il nic-hdl: AS261-RIPE changed: ashor@barakitc.co.il 971112 source: RIPE
Ciao Bernhard -- Bernhard Kroenung, Bahnhofstr 8, 36157 Ebersburg/Rhoen, Germany +49 6656
910101
@work : bernhard@kroenung.de Work: +49 661 9011777 @home : horke@Rhoen.De @school : Bernhard.Kroenung@Informatik.FH-Fulda.De
______________________________________________________________ Philip Bridge ++41 31 688 8262 bridge@ip-plus.net www.ip-plus.ch PGP: DE78 06B7 ACDB CB56 CE88 6165 A73F B703
__________________________________________________________________________ -------------------------------------------------------------------------- abha ahuja ahuja@merit.edu Merit Network, Inc. 734.764.0294
============================================================== Philip Bridge Swisscom Data/Multimedia Voice: +41 31 688 8262 Private: +41 31 911 1694 Fax: +41 31 688 8151 mail: bridge@ip-plus.net PGP:www-swiss.ai.mit.edu/~bal/pks-commands-beta.html(447485ED) ==============================================================