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.
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 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.
--
:wq Claudio
