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.

> Thank you in advance.
> 
> /per
> [EMAIL PROTECTED]
> 

-- 
:wq Claudio

Reply via email to