Pascal, in this case it was an error of configuration on our side on the peering with PSInet (PSI is not our customer). I corrected it and now PSI should not receive these type of prefixes anymore. About the fact to generate these prefixes and send them to the customers (only): I don't see any problem if everyone do that (and filter BGP table following minimal allocation size). The only consequence would be a more stable BGP :-) (and less use of memory for prefixes that anyway follow the upstream providers path).
Regards Mic Michele Marazza IP-Plus, Engineering Swisscom EC-ES-PSO-IP1 Genfergasse 14 3000 Bern 50 www.ip-plus.net ------------------------------------------------ ----- Original Message ----- From: "Pascal Gloor" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 29, 2002 1:25 AM Subject: [swinog] AS702 and AS3303 now he have it ;-P AS702 and AS3303 are both announcing 0.0.0.0/1 and 128.0.0.0/2 to their customers... and look.. Orange is customer of PSI and UUnet... and PSI is customer of Swisscom.. grrr... http://zebra.swinog.ch/wwwbin/searchipmask?ip=0.0.0.0 http://zebra.swinog.ch/wwwbin/searchipmask?ip=128.0.0.0 have a look... I dont think we have anyone from UUnet in this list, but ppl from Swisscom, think about the fact that not all of your customers have enough bgp knowledge to handle those "internal" routes.. good, now you have a table of 75'000 routes and you announce 0.0.0.0/1 and 128.0.0.0/2 internaly.. that's fine... what if we would all start to do this? my 0.02 cents... P. ---------------------------------------------- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/ --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.373 / Virus Database: 208 - Release Date: 01.07.2002 ---------------------------------------------- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
