Right, got the point -than the trafic would have to pass the expensive upstream links and that would not be desirable
Filtering just the more specifics on AS10's peering and upstream links sounds good + offer community so that AS5 can mark the routes they advertise to AS10 as backup (prefix would get low local-pref within AS10 and would get as10 prepended when sent to AS10's transit) -in case AS5 would like to use AS10 as the backup provider But what if AS5 is a content provider and all the AS10 customers would now have to use the peering links ruining the tx/rx ratio :) adam -----Original Message----- From: Gert Doering [mailto:[email protected]] Sent: Wednesday, June 01, 2011 9:14 AM To: Vitkovsky, Adam Cc: vince anton; cisco-nsp Subject: Re: [c-nsp] BGP peer/customer routes Hi, On Tue, May 31, 2011 at 03:17:11PM +0200, Vitkovsky, Adam wrote: > I believe the new customer questionnaire should query customers as to who > they use as transit > -and if one of the customer upstream ISPs happens to be your peer > than you should not advertise prefixes of the particular customer to that > peer > -and also update your peer inbound filter with your customer prefixes/ASNs Bad advice. What happens if one of the customer uplink fails? Then you *need* the interconnection to ensure they still have reachability to that AS. Now, filtering out more-specifics coming in from your peer but not announced by the customer to you (thus redirecting incoming transit traffic out the peering link) might make sense. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [email protected] fax: +49-89-35655025 [email protected] _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
