Re: AS path prepending [OpenBGPD]
On Fri, Aug 18, 2006 at 07:25:17AM +0200, Per Engelbrecht wrote:
Claudio Jeker wrote:
On Thu, Aug 17, 2006 at 05:32:52PM +0200, Per Engelbrecht wrote:
Hi all,
(obsd3.8 / i386)
So fare I've used 'weight' and 'localpref' between our peers in order to
put one in favour of the other (mainly for pricing). Now I'm adding
third peer and wan't to use AS path prepending in ordet to compensate
for one of my old peer's inappropriate peering agreements in .eu making
the old peer a sort of backup peer only.
I expect that the attribute 'prepend-self' is the one I should use one
the peer I wan't to prepend/prefix/make less attractive, like:
neighbor $slowjoe {
remote-as
descr slowjoe
set localpref 100
set weight 45
announce self
announce IPv6 none
tcp md5sig passwd x
prepend-self 2
}
... right ?
Nope. prepend-self is an outgoing thing. You most probably need to use
prepend-neighbor.
And while I'm at it:
- if I wan't to make sure that $slowjoe is chosen as a last resort, how
many times (0-9) should I prepend ?
More than 5 is normaly not needed as the avarage path is about that long.
Normaly it is easier to use localpref to make a backup session only
eligible if no other route is aroung. Just lower the localpref of your
backup neighbor.
- in short, how will the 'prepend-[self|neighbor]' attributes affect the
'localpref' and/or 'weight' ?
The decision path is roughly like this:
1. nexthop
2. localpref
3. aspath lenght
4. origin
5. MED/metric
6. EBGP/IBGP
7. weight
- In contrast to 'prepend-self' when should the 'prepend-neighbor'
attribute be used ?
prepend-self is for outgoing filters (it adds your own AS) whereas
prepend-neighbor is for incomming filters (it adds the AS of the
neighbor). Prepend-self on incomming filters will render all sent prefixes
invalid because the aspath is not loop free.
Hi Claudio,
Just to make absolutely sure:
If I want to express a policy with prepend rules to prefer INCOMING
traffic via my better-connected $primetime peer and only use my
$slowjoe peer as a backup, I should do:
...
prepend-neighbor 5
...
If I want to express a policy with prepend rules to prefer OUTGOING
traffic via my better-connected $primetime peer and only use my $slowjoe
peer as a backup, I should do:
...
prepend-self 2
...
No, it is the other way around. Sorry to confuse you even more now.
Consider the following simple config:
AS 65001
neighbor 192.168.0.1 {
remote-as 65002
set prepend-self 2
}
neighbor 192.168.0.2 {
remote-as 65003
set prepend-neighbor 5
}
Now let's have a look what bgpd is doing with the config (bgpd -nv)
AS 65001
...
neighbor 192.168.0.2 {
remote-as 65003
...
}
neighbor 192.168.0.1 {
remote-as 65002
...
}
match to 192.168.0.1 set { prepend-self 2 }
match from 192.168.0.2 set { prepend-neighbor 5 }
As you can see the set statements where replaced by filterrules.
set prepend-self got replaced by a match to rule which changes outgoing
updates and set prepend-neighbor got replaced by a match from rule which
changes incomming updates.
Now comes the twist. If you change incomming updates you actually modify
your own routing table and so your OUTGOING traffic is influenced by this.
If you change outgoing updates (your own network announcements) you
influence the view of all other routers and so the INCOMMING traffic is
modified.
In short to discriminate an uplink for OUTGOING traffic you need to use
set prepend-neighbor 5. To discriminate an uplink for INCOMMING traffic
you need to set prepend-self 5.
Note: changing your incomming traffic is unprecise you normaly end up with
some traffic comming in on the wrong link but there is nothing you can do
about it because you can not control what the other ASs do.
The last part of your reply: Prepend-self on incomming filters will
render all sent prefixes invalid because the as path is not loop free.
kind of confuses me, the filter-part that is.
As shown above the set rules added to a neighbor are magically changed to
filter rules. Now there everything is done correctly but if you add your
own filter rule like
match from any set prepend-self 1
you will see that your RIB will stay empty because all prefixes are
invalid. The reason is that the resulting path is not loop free (it
already has your AS in the path).
Based on the syntax in bgpd.conf how can I (from what you're saying)
ever avoid creating a loop if/when using prepend-self ?
example:
neighbor $slowjoe {
remote-as
descr slowjoe
set localpref 100
set weight 45
announce self
announce IPv6 none
tcp md5sig passwd x
prepend-self 2
prepend-neighbor 5
}
... from what you're saying, I've just created at loop ?
I would appreciate you answer
Re: AS path prepending [OpenBGPD]
Claudio Jeker wrote:
On Fri, Aug 18, 2006 at 07:25:17AM +0200, Per Engelbrecht wrote:
Claudio Jeker wrote:
On Thu, Aug 17, 2006 at 05:32:52PM +0200, Per Engelbrecht wrote:
Hi all,
(obsd3.8 / i386)
So fare I've used 'weight' and 'localpref' between our peers in order to
put one in favour of the other (mainly for pricing). Now I'm adding
third peer and wan't to use AS path prepending in ordet to compensate
for one of my old peer's inappropriate peering agreements in .eu making
the old peer a sort of backup peer only.
I expect that the attribute 'prepend-self' is the one I should use one
the peer I wan't to prepend/prefix/make less attractive, like:
neighbor $slowjoe {
remote-as
descr slowjoe
set localpref 100
set weight 45
announce self
announce IPv6 none
tcp md5sig passwd x
prepend-self 2
}
... right ?
Nope. prepend-self is an outgoing thing. You most probably need to use
prepend-neighbor.
And while I'm at it:
- if I wan't to make sure that $slowjoe is chosen as a last resort, how
many times (0-9) should I prepend ?
More than 5 is normaly not needed as the avarage path is about that long.
Normaly it is easier to use localpref to make a backup session only
eligible if no other route is aroung. Just lower the localpref of your
backup neighbor.
- in short, how will the 'prepend-[self|neighbor]' attributes affect the
'localpref' and/or 'weight' ?
The decision path is roughly like this:
1. nexthop
2. localpref
3. aspath lenght
4. origin
5. MED/metric
6. EBGP/IBGP
7. weight
- In contrast to 'prepend-self' when should the 'prepend-neighbor'
attribute be used ?
prepend-self is for outgoing filters (it adds your own AS) whereas
prepend-neighbor is for incomming filters (it adds the AS of the
neighbor). Prepend-self on incomming filters will render all sent prefixes
invalid because the aspath is not loop free.
Hi Claudio,
Just to make absolutely sure:
If I want to express a policy with prepend rules to prefer INCOMING
traffic via my better-connected $primetime peer and only use my
$slowjoe peer as a backup, I should do:
...
prepend-neighbor 5
...
If I want to express a policy with prepend rules to prefer OUTGOING
traffic via my better-connected $primetime peer and only use my $slowjoe
peer as a backup, I should do:
...
prepend-self 2
...
No, it is the other way around. Sorry to confuse you even more now.
Consider the following simple config:
AS 65001
neighbor 192.168.0.1 {
remote-as 65002
set prepend-self 2
}
neighbor 192.168.0.2 {
remote-as 65003
set prepend-neighbor 5
}
Now let's have a look what bgpd is doing with the config (bgpd -nv)
AS 65001
...
neighbor 192.168.0.2 {
remote-as 65003
...
}
neighbor 192.168.0.1 {
remote-as 65002
...
}
match to 192.168.0.1 set { prepend-self 2 }
match from 192.168.0.2 set { prepend-neighbor 5 }
As you can see the set statements where replaced by filterrules.
set prepend-self got replaced by a match to rule which changes outgoing
updates and set prepend-neighbor got replaced by a match from rule which
changes incomming updates.
Now comes the twist. If you change incomming updates you actually modify
your own routing table and so your OUTGOING traffic is influenced by this.
If you change outgoing updates (your own network announcements) you
influence the view of all other routers and so the INCOMMING traffic is
modified.
Okay, got it.
In short to discriminate an uplink for OUTGOING traffic you need to use
set prepend-neighbor 5. To discriminate an uplink for INCOMMING traffic
you need to set prepend-self 5.
Note: changing your incomming traffic is unprecise you normaly end up with
some traffic comming in on the wrong link but there is nothing you can do
about it because you can not control what the other ASs do.
From time to time I actually see incoming traffic heading for/through
one of our peers and then at the last core-router before reaching our
network, changing direction and enter through our second peer.
That's beyond me .. and beyond my reach as well.
The last part of your reply: Prepend-self on incomming filters will
render all sent prefixes invalid because the as path is not loop free.
kind of confuses me, the filter-part that is.
As shown above the set rules added to a neighbor are magically changed to
filter rules. Now there everything is done correctly but if you add your
own filter rule like
match from any set prepend-self 1
you will see that your RIB will stay empty because all prefixes are
invalid. The reason is that the resulting path is not loop free (it
already has your AS in the path).
i.e. my own crafted filter rules containing 'prepend-self' is where the
loop could occur.
You've just put 1 major and 2 minor building blocks in place!!
:)
Based on the syntax in
AS path prepending [OpenBGPD]
Hi all,
(obsd3.8 / i386)
So fare I've used 'weight' and 'localpref' between our peers in order to
put one in favour of the other (mainly for pricing). Now I'm adding
third peer and wan't to use AS path prepending in ordet to compensate
for one of my old peer's inappropriate peering agreements in .eu making
the old peer a sort of backup peer only.
I expect that the attribute 'prepend-self' is the one I should use one
the peer I wan't to prepend/prefix/make less attractive, like:
neighbor $slowjoe {
remote-as
descr slowjoe
set localpref 100
set weight 45
announce self
announce IPv6 none
tcp md5sig passwd x
prepend-self 2
}
... right ?
And while I'm at it:
- if I wan't to make sure that $slowjoe is chosen as a last resort, how
many times (0-9) should I prepend ?
- in short, how will the 'prepend-[self|neighbor]' attributes affect the
'localpref' and/or 'weight' ?
- In contrast to 'prepend-self' when should the 'prepend-neighbor'
attribute be used ?
Thank you in advance.
/per
[EMAIL PROTECTED]
Re: AS path prepending [OpenBGPD]
On Thu, Aug 17, 2006 at 05:32:52PM +0200, Per Engelbrecht wrote:
Hi all,
(obsd3.8 / i386)
So fare I've used 'weight' and 'localpref' between our peers in order to
put one in favour of the other (mainly for pricing). Now I'm adding
third peer and wan't to use AS path prepending in ordet to compensate
for one of my old peer's inappropriate peering agreements in .eu making
the old peer a sort of backup peer only.
I expect that the attribute 'prepend-self' is the one I should use one
the peer I wan't to prepend/prefix/make less attractive, like:
neighbor $slowjoe {
remote-as
descr slowjoe
set localpref 100
set weight 45
announce self
announce IPv6 none
tcp md5sig passwd x
prepend-self 2
}
... right ?
Nope. prepend-self is an outgoing thing. You most probably need to use
prepend-neighbor.
And while I'm at it:
- if I wan't to make sure that $slowjoe is chosen as a last resort, how
many times (0-9) should I prepend ?
More than 5 is normaly not needed as the avarage path is about that long.
Normaly it is easier to use localpref to make a backup session only
eligible if no other route is aroung. Just lower the localpref of your
backup neighbor.
- in short, how will the 'prepend-[self|neighbor]' attributes affect the
'localpref' and/or 'weight' ?
The decision path is roughly like this:
1. nexthop
2. localpref
3. aspath lenght
4. origin
5. MED/metric
6. EBGP/IBGP
7. weight
- In contrast to 'prepend-self' when should the 'prepend-neighbor'
attribute be used ?
prepend-self is for outgoing filters (it adds your own AS) whereas
prepend-neighbor is for incomming filters (it adds the AS of the
neighbor). Prepend-self on incomming filters will render all sent prefixes
invalid because the aspath is not loop free.
Thank you in advance.
/per
[EMAIL PROTECTED]
--
:wq Claudio
RE: AS path prepending [OpenBGPD]
neighbor $slowjoe {
remote-as
descr slowjoe
set localpref 100
set weight 45
announce self
announce IPv6 none
tcp md5sig passwd x
prepend-self 2
}
... right ?
And while I'm at it:
- if I wan't to make sure that $slowjoe is chosen as a last resort,
how
many times (0-9) should I prepend ?
See the combined explanation below...
- in short, how will the 'prepend-[self|neighbor]' attributes affect
the
'localpref' and/or 'weight' ?
It's my understanding that prepending excludes the 'weight'
decision-making so long as the paths being compared are no longer of
equal as-path length... so to answer your question 'how many times
should I prepend' I'd answer... 'as many times until the $slowjoe
as-path appears longer than the other carrier as-paths.' Keep checking a
looking glass (preferably $slowjoe's if they have one) for $slowjoe's
announcements of your blocks to be sure.
- In contrast to 'prepend-self' when should the 'prepend-neighbor'
attribute be used ?
It's also my understanding that if you are looking to make $slowjoe your
backup peer, then you could use 'prepend-self' for your outgoing
announcements, and 'prepend-neighbor' for their incoming announcements.
The former would make reachability to you via $slowjoe less attractive
than via other carriers you have, and the latter makes the routes you
receive from $slowjoe less attractive than routes you received from
other carriers... so imho, use both.
Thank you in advance.
/per
[EMAIL PROTECTED]
If I'm wrong about these statements, please let me know...
Re: AS path prepending [OpenBGPD]
Claudio Jeker wrote:
On Thu, Aug 17, 2006 at 05:32:52PM +0200, Per Engelbrecht wrote:
Hi all,
(obsd3.8 / i386)
So fare I've used 'weight' and 'localpref' between our peers in order to
put one in favour of the other (mainly for pricing). Now I'm adding
third peer and wan't to use AS path prepending in ordet to compensate
for one of my old peer's inappropriate peering agreements in .eu making
the old peer a sort of backup peer only.
I expect that the attribute 'prepend-self' is the one I should use one
the peer I wan't to prepend/prefix/make less attractive, like:
neighbor $slowjoe {
remote-as
descr slowjoe
set localpref 100
set weight 45
announce self
announce IPv6 none
tcp md5sig passwd x
prepend-self 2
}
... right ?
Nope. prepend-self is an outgoing thing. You most probably need to use
prepend-neighbor.
And while I'm at it:
- if I wan't to make sure that $slowjoe is chosen as a last resort, how
many times (0-9) should I prepend ?
More than 5 is normaly not needed as the avarage path is about that long.
Normaly it is easier to use localpref to make a backup session only
eligible if no other route is aroung. Just lower the localpref of your
backup neighbor.
- in short, how will the 'prepend-[self|neighbor]' attributes affect the
'localpref' and/or 'weight' ?
The decision path is roughly like this:
1. nexthop
2. localpref
3. aspath lenght
4. origin
5. MED/metric
6. EBGP/IBGP
7. weight
- In contrast to 'prepend-self' when should the 'prepend-neighbor'
attribute be used ?
prepend-self is for outgoing filters (it adds your own AS) whereas
prepend-neighbor is for incomming filters (it adds the AS of the
neighbor). Prepend-self on incomming filters will render all sent prefixes
invalid because the aspath is not loop free.
Hi Claudio,
Just to make absolutely sure:
If I want to express a policy with prepend rules to prefer INCOMING
traffic via my better-connected $primetime peer and only use my
$slowjoe peer as a backup, I should do:
...
prepend-neighbor 5
...
If I want to express a policy with prepend rules to prefer OUTGOING
traffic via my better-connected $primetime peer and only use my $slowjoe
peer as a backup, I should do:
...
prepend-self 2
...
The last part of your reply: Prepend-self on incomming filters will
render all sent prefixes invalid because the as path is not loop free.
kind of confuses me, the filter-part that is.
Based on the syntax in bgpd.conf how can I (from what you're saying)
ever avoid creating a loop if/when using prepend-self ?
example:
neighbor $slowjoe {
remote-as
descr slowjoe
set localpref 100
set weight 45
announce self
announce IPv6 none
tcp md5sig passwd x
prepend-self 2
prepend-neighbor 5
}
... from what you're saying, I've just created at loop ?
I would appreciate you answer very much.
The best
/per
[EMAIL PROTECTED]
Thank you in advance.
/per
[EMAIL PROTECTED]
