|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: AS 701 local-pref answer.
As a clarification, MEDs would not help you out here in case of customer prepending - unless you were ignoring AS-Path length. I'm not endorsing that, as I've not heard of anyone trying it on a large scale. - Daniel Golding > > > > Heh. Of course for AS's lacking usptreams, a more sensible sort of Local > Preference hierarchy might be... > > Customer Prefered > Customer > Customer Backup > Private Peers > Congested Private Peers (perish the thought!) > Good Public Peers (usually gigE exchange points) > Bad Public Peers (Used to be FDDI, now ATM, i guess :) > > This is the usual ranking system used, with each category having both a > local pref (and occasionally a range of LPs), and a destinctive community > value. > > Although 701 has mechanisms for handling this (which work), the best > approach for most folks who have both peers and customers, is to pref your > customers, to ensure that their routes are always chosen in case of > prepending. There are several reasons for this... > > 1 - Customers generally WANT traffic from directly connected > networks. They > also want to be able to prepend in order to balance traffic. > 2 - Selecting a route through a peer, instead of a customer could > adversely > effect both your peering traffic balance, and your burstable billing model > :) > > One way of accomplishing this sort of thing, if one were > completely adverse > to Local Preference, would be to use additive MEDs, and adding a large MED > cost for peers, and a smaller one for customer routes, at point > of ingress. > > - Daniel Golding > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]]On Behalf Of > > David Barak > > Sent: Monday, December 17, 2001 10:55 AM > > To: Mike Leber > > Cc: [email protected]; [email protected]; [email protected]; > > [email protected] > > Subject: Re: AS 701 local-pref answer. > > > > > > > > Hi, > > > > I don't think AS 701 (or any of its peers) are > > particularly worried about different best-paths in > > different regions. This is the old > > hot-potato/cold-potato discussion, which I don't see a > > need to re-hash. > > > > Let's pretend that Bob's bait & tackle shop (AS > > 30,000) is multihomed to AS 701 and AS 1. Bob would > > probably want AS701 origin traffic to prefer his AS701 > > link, and his AS1 Origin traffic to prefer his Genuity > > link. No problem there - they both see a route 1 > > AS-hop away. The question only comes when Bob wants > > to have all other traffic prefer one link or the > > other. > > > > If he chose to prepend his AS to AS701, then he would > > run the risk of Genuity being the preferred path from > > AS701, and AS701 would not advertise a path. This > > would be a useful situation if, for instance, the > > Genuity link was a DS3, and the 701 link was a T1. If > > they were equal bandwidth links, and Bob was trying to > > do traffic-sharing, then that would not be a good > > solution. > > > > AS 701 does have mechanisa for customers to do this, > > and their support people are more than happy to assist > > customers with their routing needs. > > > > By the way, the gentleman who referred to "customers, > > peers, and upstreams" as useful loc-pref settings > > should remember that AS701 doesn't have upstreams. :) > > > > David Barak > > I speak for myself only. > > "Quis custodes ipsos custodiet?" - Juvenal > > > > --- Mike Leber <[email protected]> wrote: > > > > > > Not to be like Columbo... However, there's just one > > > last question > > > bothering me. Well ok, more than one :) > > > > > > If it's like [email protected] said and 701 > > > doesn't deterministicly > > > prefer customer routes (customers and peer routes at > > > the same local pref) > > > wouldn't this mean that they wouldn't have > > > consistent route announcments > > > in various parts of their network? > > > > > > If a customer doesn't set the community to boost the > > > local pref, and 701 > > > truly by default sets customers and peers to 100, > > > then 701 would be > > > announcing varying numbers of routes to the same > > > peer at different > > > locations. > > > > > > Do they expect consistent route annoucements from > > > their peers? > > > > > > Many networks out there insist upon this as a > > > requirement when peering. > > > > > > Mike. > > > > > > On Sun, 16 Dec 2001, Mike Leber wrote: > > > > > > > > > > > Thank you for pointing that out. I was being > > > dense and reading way too > > > > much into the statements: > > > > > > > > [email protected] wrote: > > > > > All the responses I have gotten indicate that > > > UUnet does indeed set > > > > > local-pref on both customers and peers to 100 > > > (or leave default in this > > > > > case). Thanks for all the responses... > > > > > > > > Especially when the 701 communities were already > > > provided by German > > > > Martinez. *DOH* > > > > > > > > In other words, 701 transit customers that > > > actually want to ensure their > > > > downstream customer routes are announced by 701 > > > had better set the > > > > appropriate community so that local pref gets set > > > above 100. By default > > > > this is not done. > > > > > > > > Pardon me while I get some much needed rest. > > > > > > > > Mike. > > > > > > > > On Sun, 16 Dec 2001, David Barak wrote: > > > > > > > > > Mike Leber wrote: > > > > > > > > > > >If they set local pref for both peers and > > > customers > > > > > >to 100 how do they > > > > > >ensure that the customer transit routes are > > > > > >announced to peers? > > > > > > > > > > >The reason I ask this is because if a customer > > > > > >announces a customer of > > > > > >theirs to you that a peer also has as a > > > customer >you > > > > > will have equal > > > > > >length routes for the same destination AS. > > > While > > > > > >there are many ways to > > > > > >deterministicly prefer customer routes, local > > > pref > > > > > >is the most common. > > > > > > > > > > AS 701 always announces the best route, as their > > > > > routers know it. Their average AS-path length > > > is > > > > > under 2, so it doesn't seem to be a problem. If > > > a > > > > > customer of AS 701 wants to insure that his/her > > > route > > > > > is advertised in all cases, s/he could send a > > > > > community which AS701 edge devices could use to > > > > > manipulate local-preference upward. [this was > > > covered > > > > > in a previous posting on this topic] I leave it > > > to > > > > > your imagination whether peers would be > > > permitted to > > > > > do this. > > > > > > > > > > -David Barak > > > > > I only speak for myself. > > > > > "Quis custodes ipsos custodiet?" - Juvenal > > > > > > > > > > > > > __________________________________________________ > > > > > Do You Yahoo!? > > > > > Check out Yahoo! Shopping and Yahoo! Auctions > > > for all of > > > > > your unique holiday gifts! Buy at > > > http://shopping.yahoo.com > > > > > or bid at http://auctions.yahoo.com > > > > > > > > > > > > > +------------------- H U R R I C A N E - E L E C T > > > R I C -------------------+ > > > > | Mike Leber Direct Internet > > > Connections Voice 510 580 4100 | > > > > | Hurricane Electric Web Hosting Colocation > > > Fax 510 580 4151 | > > > > | [email protected] > > > http://www.he.net | > > > > > > > > > +----------------------------------------------------------------- > > ----------+ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > +------------------- H U R R I C A N E - E L E C T R > > > I C -------------------+ > > > | Mike Leber Direct Internet Connections > > > Voice 510 580 4100 | > > > | Hurricane Electric Web Hosting Colocation > > > Fax 510 580 4151 | > > > | [email protected] > > > http://www.he.net | > > > > > +----------------------------------------------------------------- > > ----------+ > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Check out Yahoo! Shopping and Yahoo! Auctions for all of > > your unique holiday gifts! Buy at http://shopping.yahoo.com > > or bid at http://auctions.yahoo.com > > >
|