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
Date: Sun, 16 Dec 2001 17:28:30 -0800 (PST) From: David Barak <thegameiam@yahoo.com>
AS 701 always announces the best route, as their routers know it. Their average AS-path length is
This is silly. Local-pref is one of the methods by which a router learns the "best route". The question was: If not by local-pref, then by what?
under 2, so it doesn't seem to be a problem. If a
And if someone pads their adverts to 701 at their egress? Suddenly the "best route" to the downstream is via the peer. Sorry, it doesn't matter if "average as-path length is under 2" or not... the point is that (unless BGP weight comes into play), after reachability, as-path length is the first route selection mechanism after reachability.
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
IOW, the bottom line answer is: reliance on as-path length, but local-pref is tunable via communities. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
Thank you for pointing that out. I was being dense and reading way too much into the statements: smentzer@mentzer.org 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 | | mleber@he.net http://www.he.net | +---------------------------------------------------------------------------+
Not to be like Columbo... However, there's just one last question bothering me. Well ok, more than one :) If it's like mentzer@mentzer.org 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:
smentzer@mentzer.org 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 | | mleber@he.net 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 | | mleber@he.net http://www.he.net | +---------------------------------------------------------------------------+
Do they expect consistent route annoucements from their peers?
Many networks out there insist upon this as a requirement when peering.
While many networks insist on this as a requirement when peering, few folks audit it, and fewer still take action as a result of noticing inconsistent announcements. "it's only illegal if you get caught". I think vaf@bbn/genu used to actively audit and unicastedly communicate this stuff and catch errors folks made. There was always discrepancy between what the views should look like, but it was usually noise. I think the filter was something like 1% or such, scaled to the number of routes announced. This was a good first pass filter to see if someone was actively screwing you. I recall that a network at which I worked ran a similar consistency checking script, and we'd find and watch what folks were doing. Normally it was 'in the noise' but if it was significant we'd ask them to fix it. If they didn't fix it, well the implied threat was that we'd 'depeer' but it never got to that. The real reason for this 'consistent announcement' thing was (at least to me, being one who wrangled the lawyers that wrote the peering policy before jsb took that stick) to prevent folks from forcing us to carry more of a peer's traffic, and to prevent a customer from doing closest exit on us, w/out letting us do closest exit to them. jmalcolm + sherk even had a scheme by which we'd set the BGP NH of all learned routes to a particular IP address, say "10.1.1.1" and then static route that 10.1.1.1/32 destination out all applicable peering interfaces. In this manner we'd just have a given /32 destination for each peer, and assign their routes to that. We never put it into practice because a/ the problem wasn't great, and b/ there were some "quote" technical "unquote" issues with this solution. Bottom line, this inconsistency issue is not significant.
wouldn't this mean that they wouldn't have consistent route announcments in various parts of their network?
My recollection of the issues being discussed are that they are inconsequential in practice, and resolution lays in the hands of the customer. -a
### On Mon, 17 Dec 2001 02:09:22 -0600, Alan Hannan <alan@routingloop.com> ### casually decided to expound upon nanog@merit.edu the following thoughts ### about "Re: AS 701 local-pref answer.": AH> > Do they expect consistent route annoucements from their peers? AH> > AH> > Many networks out there insist upon this as a requirement when peering. AH> AH> While many networks insist on this as a requirement when peering, AH> few folks audit it, and fewer still take action as a result of AH> noticing inconsistent announcements. A while back, networks peering with the RSng route servers had access to the PAIR reports which listed inconsistant and unregistered or policy-violated (as per the IRR) routing anniouncements. Quite a few people claimed they used PAIR to clean up their announcements and their registry objects. I don't know if there were any agreement ramifications however. AH> Bottom line, this inconsistency issue is not significant. Agreed... even with strict policy checking. Amongst all the peering points that the route servers were installed, inconsistant announcements accounted for very little (most list of violations would fit in a single browser window without having to scroll) with the occasional exception of misconfiguration or massive policy changes in the IRR. We're talking typically a maximum of a dozen inconsistancies and red-flagged routes overall... usually for a small prefix. -- /*===================[ Jake Khuon <khuon@NEEBU.Net> ]======================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --------------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=========================================================================*/
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 <mleber@he.net> wrote:
Not to be like Columbo... However, there's just one last question bothering me. Well ok, more than one :)
If it's like mentzer@mentzer.org 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
much into the statements:
smentzer@mentzer.org 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
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
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
dense and reading way too provided by German pref 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 | | mleber@he.net 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 | | mleber@he.net 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
It's probably not safe to assume every 701 peer peers with each other, or that 701 peers with every peer at every location 701 has a peering session, which means different peers could get different routes. In any case, it's easily adjusted by 701 customers that have a preference with the aforementioned communities. Mike. On Mon, 17 Dec 2001, David Barak wrote:
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 <mleber@he.net> wrote:
Not to be like Columbo... However, there's just one last question bothering me. Well ok, more than one :)
If it's like mentzer@mentzer.org 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
much into the statements:
smentzer@mentzer.org 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
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
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
dense and reading way too provided by German pref 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 | | mleber@he.net 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 | | mleber@he.net 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
+------------------- 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 | | mleber@he.net http://www.he.net | +---------------------------------------------------------------------------+
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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of David Barak Sent: Monday, December 17, 2001 10:55 AM To: Mike Leber Cc: nanog@merit.edu; smentzer@mentzer.org; rekoil@semihuman.com; gmartine@nic.gip.net 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 <mleber@he.net> wrote:
Not to be like Columbo... However, there's just one last question bothering me. Well ok, more than one :)
If it's like mentzer@mentzer.org 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
much into the statements:
smentzer@mentzer.org 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
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
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
dense and reading way too provided by German pref 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 | | mleber@he.net 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 | | mleber@he.net 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
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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of David Barak Sent: Monday, December 17, 2001 10:55 AM To: Mike Leber Cc: nanog@merit.edu; smentzer@mentzer.org; rekoil@semihuman.com; gmartine@nic.gip.net 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 <mleber@he.net> wrote:
Not to be like Columbo... However, there's just one last question bothering me. Well ok, more than one :)
If it's like mentzer@mentzer.org 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
much into the statements:
smentzer@mentzer.org 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
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
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
dense and reading way too provided by German pref 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 | | mleber@he.net 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 | | mleber@he.net 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
participants (6)
-
Alan Hannan -
Daniel Golding -
David Barak -
E.B. Dreger -
Jake Khuon -
Mike Leber