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 xxxx
descr "slowjoe"
set localpref 100
set weight 45
announce self
announce IPv6 none
tcp md5sig passwd xxxxxxxxx
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 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 xxxx
descr "slowjoe"
set localpref 100
set weight 45
announce self
announce IPv6 none
tcp md5sig passwd xxxxxxxxx
prepend-self 2
prepend-neighbor 5
}
... from what you're saying, I've just created at loop ?
I would appreciate you answer very much.
No bgpd does the right thing in this case.
>From the manpage:
Set parameters are applied to the received prefixes; the only exceptions
are prepend-self, nexthop no-modify and nexthop self.
Thank you very much for the thorough explanation Claudio.
Appreciate it.
/per
[EMAIL PROTECTED]
