AS 701 local-pref answer.

Mailman List Mirror (Read Only)
1

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

2

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

3

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.

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 -------------------+

4

Not to be like Columbo... However, there's just one last question
bothering me. Well ok, more than one :slight_smile:

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.

Thank you for pointing that out. I was being dense and reading way too
much into the statements:

> 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.

> 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 -------------------+

5

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

6

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. :slight_smile:

David Barak
I speak for myself only.
"Quis custodes ipsos custodiet?" - Juvenal

7

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.

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. :slight_smile:

David Barak
I speak for myself only.
"Quis custodes ipsos custodiet?" - Juvenal

>
> Not to be like Columbo... However, there's just one
> last question
> bothering me. Well ok, more than one :slight_smile:
>
> 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.
>
>
> >
> > Thank you for pointing that out. I was being
> dense and reading way too
> > much into the statements:
> >
> > > 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.
> >
> >
> > > 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 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 -------------------+

8

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 :slight_smile:

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
:slight_smile:

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

9

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