Mailing List Archive

* "Alok Dube" <alok.dube@apara.com> wrote:

> For example if there is AS1 (big guy), AS2(small guy) and AS3(big guy)
>
> AS2 peers with AS1 and AS3.
>
> AS4 is a client of AS2. AS4 however peers to AS1 too.....
>
> Do AS1 and AS3 ensure that "in someway", their announcement of the
> internet routing table to AS2 is ensuring that if routes go from AS1
> to AS3, or vice versa, they are "less preferred via that path from
> AS2"? (ebgp routes going across)....

I'm not sure whether I get you right or not, but AS2 shouldn't announce
AS1's routes to AS3 or vice versa. If AS2 does, it depends on the
weight/preference AS1 or AS3 assigns the routes learned from AS2. So if
AS2 is a customer of AS1 and AS3, I'd assume that its routes are more
preferred than the routes directly learned from AS1/AS3.

But that depends on each AS's policy and nobody probably will be able to
give you a correct answer. Simply avoid to announce unnecessary prefixes
to your upstreams/peerings.

sebastian

On 08/08/2003 03:31 AM, Alok Dube wrote:

> Do AS1 and AS3 ensure that "in someway", their announcement of the internet
> routing table to AS2 is ensuring that if routes go from AS1 to AS3, or vice
> versa, they are "less preferred via that path from AS2"? (ebgp routes going
> across)....
>
> In general who has to take care of such scenarios?? is it generall done that
> "advertise a longer ASPATH" to smaller peers/lower bandwidth paths?


Hi Alok,

In your scenario, are you worried about traffic between two large ASes (1 & 3)
going through the small AS (2) ? ASes of the same size usually have
"non-transit peering" connections while ASes of different sizes tend to have
"transit customer-provider" type connections. These kinds of business
relationships tend to have route filters associated with them to prevent the
scenario you are talking about. You can see papers by Lixin Gao @ UMass (just
google for them) on "AS relationships" for details.

Sharad.

Hi,

Thanks for the reply...

inline....
----- Original Message -----
From: "Sebastian Abt" <sabt@sabt.net>
To: <quagga-users@lists.quagga.net>
Sent: Friday, August 08, 2003 4:23 PM
Subject: [quagga-users 111] Re: BGP routing


> * "Alok Dube" <alok.dube@apara.com> wrote:
>
> > For example if there is AS1 (big guy), AS2(small guy) and AS3(big guy)
> >
> > AS2 peers with AS1 and AS3.
> >
> > AS4 is a client of AS2. AS4 however peers to AS1 too.....
> >
> > Do AS1 and AS3 ensure that "in someway", their announcement of the
> > internet routing table to AS2 is ensuring that if routes go from AS1
> > to AS3, or vice versa, they are "less preferred via that path from
> > AS2"? (ebgp routes going across)....
>
> I'm not sure whether I get you right or not, but AS2 shouldn't announce
> AS1's routes to AS3 or vice versa. If AS2 does, it depends on the
> weight/preference AS1 or AS3 assigns the routes learned from AS2. So if
> AS2 is a customer of AS1 and AS3, I'd assume that its routes are more
> preferred than the routes directly learned from AS1/AS3.
>
fine, whatever be the "cost"...assume its longest match....

so wont this be controlled by AS3 and AS1 itself? would they not try to
ensure that "specific networks are downlinked from a particular node" and
hence announce "more specifics" over other links compared to the link
towards AS2?

for example if as3 has network x.y.z.w/16 would he not try to advertise
x.y.z.w1/17 and x.y.z.w2/17 over the corresponding links he "actually wants
the traffic" to come via? and advertise /16 to AS2?

however AS2 might learn the /17s for AS3 from AS1 too, and hence send
traffic via AS1....is this what AS2 "wanted" or "not"..
by this logic, even accepting routes from 2 ASes can cause problems for the
AS.?


> But that depends on each AS's policy and nobody probably will be able to
> give you a correct answer. Simply avoid to announce unnecessary prefixes
> to your upstreams/peerings.

yes, so what is the general practice...specifcs to preferred downlink points
and full routes to everyone else? how does that help?


>
> sebastian
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-users
>

On Fri, 8 Aug 2003, Alok Dube wrote:

> Hi,
>
> Would like some feedback from the people on this list,
>
> What is the general method to balance BGP traffic used by ISPs?

that depends. for outbound there are quite a few knobs that can be
tweaked.

for inbound, there is only one: as prepend.

(well, MED too - but that applies only to links with same peer AS)

> For example if there is AS1 (big guy), AS2(small guy) and AS3(big
> guy)
>
> AS2 peers with AS1 and AS3.
>
> AS4 is a client of AS2. AS4 however peers to AS1 too.....


so...

AS1----AS4
ASx \ |
---\ |
AS3----AS2


ASx is somewhere to left of AS{1,3} (ie all its paths to AS{4,2}
are via 1 and 3. ASx will see the following AS paths for AS4:

.*_1_4$
.*_1_2_4$
.*_3_2_4$
.*_3_2_1_4$

hence it will prefer the first announcement. Indeed, all ASes that
are more or less equidistant to AS1, AS3 (ie as path length to best
route to AS1 and best route to AS3, is same) will prefer the first
path.


> Do AS1 and AS3 ensure that "in someway", their announcement of the
> internet routing table to AS2 is ensuring that if routes go from
> AS1 to AS3, or vice versa, they are "less preferred via that path
> from AS2"? (ebgp routes going across)....

BGP ensures this. BGP is a distance vector. Add up the number of ASes
in the path and all else being equal shortest path wins.

> In general who has to take care of such scenarios?? is it generall
> done that "advertise a longer ASPATH" to smaller peers/lower
> bandwidth paths?

You can, yes.

Thats a matter of traffic engineering. as prepending being the only
option if you wish to control inbound traffic.

> Would appreciate all the help,
>
> -thanks
> Alok

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Carmel, New York, has an ordinance forbidding men to wear coats and
trousers that don't match.

Hi Paul,

inline...

----- Original Message -----
From: "Paul Jakma" <paul@clubi.ie>
To: "Alok Dube" <alok.dube@apara.com>
Cc: <quagga-users@lists.quagga.net>
Sent: Friday, August 08, 2003 4:34 PM
Subject: [quagga-users 114] Re: BGP routing


> On Fri, 8 Aug 2003, Alok Dube wrote:
>
> > Hi,
> >
> > Would like some feedback from the people on this list,
> >
> > What is the general method to balance BGP traffic used by ISPs?
>
> that depends. for outbound there are quite a few knobs that can be
> tweaked.
>
> for inbound, there is only one: as prepend.

or longest match....

>
> (well, MED too - but that applies only to links with same peer AS)
>
> > For example if there is AS1 (big guy), AS2(small guy) and AS3(big
> > guy)
> >
> > AS2 peers with AS1 and AS3.
> >
> > AS4 is a client of AS2. AS4 however peers to AS1 too.....
>
>
> so...
>
> AS1----AS4
> ASx \ |
> ---\ |
> AS3----AS2
>
>
> ASx is somewhere to left of AS{1,3} (ie all its paths to AS{4,2}
> are via 1 and 3. ASx will see the following AS paths for AS4:
>
> .*_1_4$
> .*_1_2_4$
> .*_3_2_4$
> .*_3_2_1_4$
>
> hence it will prefer the first announcement. Indeed, all ASes that
> are more or less equidistant to AS1, AS3 (ie as path length to best
> route to AS1 and best route to AS3, is same) will prefer the first
> path.

yes but 1 and 3 may end up talking directly via AS2.........

>
>
> > Do AS1 and AS3 ensure that "in someway", their announcement of the
> > internet routing table to AS2 is ensuring that if routes go from
> > AS1 to AS3, or vice versa, they are "less preferred via that path
> > from AS2"? (ebgp routes going across)....
>
> BGP ensures this. BGP is a distance vector. Add up the number of ASes
> in the path and all else being equal shortest path wins.

"path vector"....eitherways, most ISPs loadbalance on bandwidth, not on
"hops" as I have seen....

is this a common observation?

>
> > In general who has to take care of such scenarios?? is it generall
> > done that "advertise a longer ASPATH" to smaller peers/lower
> > bandwidth paths?
>
> You can, yes.

but in that case , AS4 may have a better bandwidth path to AS1, so AS2 would
come via AS1 to AS4?

>
> Thats a matter of traffic engineering. as prepending being the only
> option if you wish to control inbound traffic.

yes, and i cant quite seem to get the ideas going, hence querying the list
in general...

-thanks
Alok

>
> > Would appreciate all the help,
> >
> > -thanks
> > Alok
>
> regards,
> --
> Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
> warning: do not ever send email to spam@dishone.st
> Fortune:
> Carmel, New York, has an ordinance forbidding men to wear coats and
> trousers that don't match.
>
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-users
>

* "Alok Dube" <alok.dube@apara.com> wrote:

> fine, whatever be the "cost"...assume its longest match....

ok.

> so wont this be controlled by AS3 and AS1 itself? would they not try
> to ensure that "specific networks are downlinked from a particular
> node" and hence announce "more specifics" over other links compared to
> the link towards AS2?

No, I don't think so.. That would be too much work and blew up the
table. At least big guys won't do so.

> for example if as3 has network x.y.z.w/16 would he not try to
> advertise x.y.z.w1/17 and x.y.z.w2/17 over the corresponding links he
> "actually wants the traffic" to come via? and advertise /16 to AS2?

I don't think. If shortest path wins, then there is no need for
splitting the prefixes into two or more parts.

> however AS2 might learn the /17s for AS3 from AS1 too, and hence send
> traffic via AS1....is this what AS2 "wanted" or "not"..
> by this logic, even accepting routes from 2 ASes can cause problems
> for the AS.?

That would be possible, but not realistic.

> yes, so what is the general practice...specifcs to preferred downlink
> points and full routes to everyone else? how does that help?

The general practice are AS-PATH prepends to regulate inbound traffic.

sebastian

> No, I don't think so.. That would be too much work and blew up the
> table. At least big guys won't do so.

so then if AS1 and AS3 dont directly peer......??
>
> > for example if as3 has network x.y.z.w/16 would he not try to
> > advertise x.y.z.w1/17 and x.y.z.w2/17 over the corresponding links he
> > "actually wants the traffic" to come via? and advertise /16 to AS2?
>
> I don't think. If shortest path wins, then there is no need for
> splitting the prefixes into two or more parts.

but consider it from AS-4s scenario, it may have a better bandwith via AS1
hence less "path prepends" via , but this could mean even AS2 comes via AS1?

>
> > however AS2 might learn the /17s for AS3 from AS1 too, and hence send
> > traffic via AS1....is this what AS2 "wanted" or "not"..
> > by this logic, even accepting routes from 2 ASes can cause problems
> > for the AS.?
>
> That would be possible, but not realistic.

okie so i assume its not done........

>
> > yes, so what is the general practice...specifcs to preferred downlink
> > points and full routes to everyone else? how does that help?
>
> The general practice are AS-PATH prepends to regulate inbound traffic.

so we assume in general "the internet is equally distributed on all sides",
we shall send ASPATH perpends based on link capacities?
or do we assume equal link capacities?

i am just kind of stuck on something here...so am looking for the general
practice by most people....

thanks for your comments,

rgds
Alok
>
> sebastian
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-users
>

> No, why? ^1$ is shorter than ^2_1$ and ^3$ is shorter than ^2_3$
> Same weight, same prefixes, same preference -> shortest path.
>

no not like Paul's diagram...

1 and 3 dont peer directly.....

they peer to others....and learn over the internet...from other peers

I actually have a scenario like that in my country.....

* "Alok Dube" <alok.dube@apara.com> wrote:

> > hence it will prefer the first announcement. Indeed, all ASes that
> > are more or less equidistant to AS1, AS3 (ie as path length to best
> > route to AS1 and best route to AS3, is same) will prefer the first
> > path.
>
> yes but 1 and 3 may end up talking directly via AS2.........

No, why? ^1$ is shorter than ^2_1$ and ^3$ is shorter than ^2_3$
Same weight, same prefixes, same preference -> shortest path.

> "path vector"....eitherways, most ISPs loadbalance on bandwidth, not
> on"hops" as I have seen....
>
> is this a common observation?

They indirectly loadbalance on bandwidth by manipulating AS-PATH.
That's common on ISP site, if they know that carrier x's uplink is
better than carrier y's one.

* "Alok Dube" <alok.dube@apara.com> wrote:

> so then if AS1 and AS3 dont directly peer......??

Of course, then. Provided that AS2 announces all its routes to all its
peers.

> but consider it from AS-4s scenario, it may have a better bandwith via
> AS1 hence less "path prepends" via , but this could mean even AS2
> comes via AS1?

That could happen, yes.

> so we assume in general "the internet is equally distributed on all
> sides", we shall send ASPATH perpends based on link capacities?
> or do we assume equal link capacities?

That depends on many factors.. The biggest one is the AS relationship
(customer or peering). If you pay for each Mbit/s your sending via AS1,
then you'll maybe send more via another AS where you're paying less.

> i am just kind of stuck on something here...so am looking for the
> general practice by most people....

The general practice depends on your position. If you've much money or
many peerings, then let BGP choose the best path and only adjust on
problems and bottlenecks. If you don't, fit it to your needs ;-)

> > No, why? ^1$ is shorter than ^2_1$ and ^3$ is shorter than ^2_3$
> > Same weight, same prefixes, same preference -> shortest path.
> >
>
> no not like Paul's diagram...
>
> 1 and 3 dont peer directly.....
>
> they peer to others....and learn over the internet...from other peers

In THAT case, since AS1 and AS3 are larger than AS2 is, then it's very
likely that both 1 and 3 peer with another AS, let's say 5, that has
larger pipes to 1 and 3. AS1 will see 2 paths to AS3, 2_3 and 5_3: but
metric is different so it'll prefer 5_3. It's also quite likely that AS1
and AS3 both peer with even MORE networks--all with the same path length.
It's up to AS1 (and AS3) to set the metrics internally to prefer the
larger or better latency pipes. If the best path is through AS2, then
that's the path they'll take. (If AS2 can't handle that, then they need
to work with the other peers to alter those preferences, but in general,
AS1 and AS3 will most likely be using some filters to set the preference
on those small pipes to AS2 in order NOT to use them for transit)

Another point: it's common for AS'es to prefer direct peers instead of
other AS'es (transit peers), so even though AS2 may see a path to you with
5 prefixes, it'll prefer that route over the shorter prefixes it sees from
AS1 or AS3, and thus use your direct connection. That's an option that
has to be set on AS2's side of the BGP session. (Generally done with
community strings to set the local preference)

If AS2 is very small (i.e. only peers with AS1 and AS3 and it's own
customers) then it's most likely that their peering sessions with AS1 will
filter out all routes from AS3 to avoid becoming transit for routes to AS3
(and the same goes for the peering with AS3). This neatly avoids the
1->2->3 path altogether because AS1 never sees the route 2_3 because AS2
didn't announce that route to them.

Hello Jeff....


>> > No, why? ^1$ is shorter than ^2_1$ and ^3$ is shorter than ^2_3$
>> > Same weight, same prefixes, same preference -> shortest path.
>> >
>>
>> no not like Paul's diagram...
>>
>> 1 and 3 dont peer directly.....
>>
>> they peer to others....and learn over the internet...from other peers
>
> In THAT case, since AS1 and AS3 are larger than AS2 is, then it's very
> likely that both 1 and 3 peer with another AS, let's say 5, that has
> larger pipes to 1 and 3. AS1 will see 2 paths to AS3, 2_3 and 5_3: but
> metric is different so it'll prefer 5_3.

....and this metric being "what" Jeff..u just ruled out AS path as a
metric...

>It's also quite likely that
> AS1 and AS3 both peer with even MORE networks--all with the same path
> length. It's up to AS1 (and AS3) to set the metrics internally to
> prefer the larger or better latency pipes. If the best path is through
> AS2, then that's the path they'll take.

i think u missed my question...

it was more like "how do i set up the best path"?

>(If AS2 can't handle that,
> then they need to work with the other peers to alter those preferences,
> but in general, AS1 and AS3 will most likely be using some filters to
> set the preference on those small pipes to AS2 in order NOT to use them
> for transit)
>
> Another point: it's common for AS'es to prefer direct peers instead of
> other AS'es (transit peers), so even though AS2 may see a path to you
> with 5 prefixes, it'll prefer that route over the shorter prefixes it
> sees from AS1 or AS3,

what is a direct peer? i am sorry but am soo new to all this....


>and thus use your direct connection. That's an
> option that has to be set on AS2's side of the BGP session. (Generally
> done with community strings to set the local preference)


"local preference" seems to work so well across ASes ;-).... doesnt it (i
neevr read CLI....)
>
> If AS2 is very small (i.e. only peers with AS1 and AS3 and it's own
> customers) then it's most likely that their peering sessions with AS1
> will filter out all routes from AS3 to avoid becoming transit for
> routes to AS3 (and the same goes for the peering with AS3). This
> neatly avoids the 1->2->3 path altogether because AS1 never sees the
> route 2_3 because AS2 didn't announce that route to them.



ahhaaa and then how does AS4 in the given problem work?
>
>
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-users

On Fri, 8 Aug 2003, Alok Dube wrote:

> From: "Paul Jakma" <paul@clubi.ie>

> > for inbound, there is only one: as prepend.
>
> or longest match....

longest match?

> > so...
> >
> > AS1----AS4
> > ASx \ |
> > ---\ |
> > AS3----AS2
> >
> > hence it will prefer the first announcement. Indeed, all ASes that
> > are more or less equidistant to AS1, AS3 (ie as path length to best
> > route to AS1 and best route to AS3, is same) will prefer the first
> > path.
>
> yes but 1 and 3 may end up talking directly via AS2.........

If AS2 advertises AS1 to AS3 and AS3 to AS1, and if AS1 and AS3 are
configured to accept the announcement of AS1/3 from AS2, then yes.

> "path vector"....eitherways, most ISPs loadbalance on bandwidth,
> not on "hops" as I have seen....

how do you mean?

> is this a common observation?

> but in that case , AS4 may have a better bandwidth path to AS1, so
> AS2 would come via AS1 to AS4?

The primary metric in BGP is AS path length. There is nothing in BGP
(in common usage anyway) to relate information about bandwidth per
hop. So AS2 will use its direct path.

You can make AS2 prefer paths via AS4, eg by assigning a lower
local-prefence to routes learned from AS4 versus those learned from
AS1.

> yes, and i cant quite seem to get the ideas going, hence querying the list
> in general...

One common way of doing traffic engineering is to tag incoming
announcements at your borders with one or more communities that have
some meaning you define (eg "learned this from as1 via the foo link"
or "learned at location y", and perhaps set a local preference. Then
other routers in your iBGP can apply their own route-maps and
reassign local-preference and/or weight as they wish.

> -thanks
> Alok

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
If a subordinate asks you a pertinent question, look at him as if he had
lost his senses. When he looks down, paraphrase the question back at him.

On Sun, 10 Aug 2003, Paul Jakma wrote:

> On Fri, 8 Aug 2003, Alok Dube wrote:
>
> > From: "Paul Jakma" <paul@clubi.ie>
>
> > > for inbound, there is only one: as prepend.
> >
> > or longest match....
>
> longest match?

Paul, hopefully, people are making announcements of their
aggregates. Granted, there are some cases where a downstream customer may
be announcing _a_portion_ of your address space as a specific and you're
aggregating for whatever reason but, as far as making different
announcements to _upstream_ providers, it will create more problems than
it will solve. Seriously... Both upstreams should be connected to the
GLOBAL internet and if you suddenly announce a longer announcement via
only ONE, the whole WORLD is going to preference that provider. This may
be a solution in a very few cases but, for the most part, what we're
trying to accomplish is a shorter transit path.


--
John Fraizer | High-Security Datacenter Services |
President | Dedicated circuits 64k - 155M OC3 |
EnterZone, Inc | Virtual, Dedicated, Colocation |
http://www.enterzone.net/ | Network Consulting Services |

On Mon, 11 Aug 2003, John Fraizer wrote:

> Paul,

> hopefully, people are making announcements of their aggregates.
> Granted, there are some cases where a downstream customer may be
> announcing _a_portion_ of your address space as a specific and
> you're aggregating for whatever reason but, as far as making
> different announcements to _upstream_ providers, it will create
> more problems than it will solve. Seriously... Both upstreams
> should be connected to the GLOBAL internet and if you suddenly
> announce a longer announcement via only ONE, the whole WORLD is
> going to preference that provider. This may be a solution in a
> very few cases but, for the most part, what we're trying to
> accomplish is a shorter transit path.

yes, indeed for prefixes its longest-match. i was confused whether
alok was possibly referring to longest-match on as-paths :)

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Support Bingo, keep Grandma off the streets.