policy-statement logic - help!!

I suspect I am being thick here, but I'm really struggling with how the logic of policies works

I have a very simple setup of 4 routers in the lab like this:

--- ---- ---- ---
|AS1|--ebgp--|AS10|--ibgp--|AS10|--ebgp--|AS2|
--- ---- ---- ---

I have static null routes on the AS10 routers which I want to export to egbp & ibgp

so I wrote a policy-statement to export statics & set next-hop-self for iBGP:

policy-statement ibgp-foo {
term redist-static {
from protocol static;
then {
next-hop self;
accept;
}
}
then {
next-hop self;
accept;
}
}

the idea being to inject the statics into ibgp with n-h-s (which I guess they would be anyway), & then set the remaining eligible (ie BGP) routes to n-h-s too. however, as well as injecting the statics, it injects all the other active routes too!

if I change it to the following, it does what I want it to:

policy-statement ibgp-foo {
term redist-static {
from protocol static;
then {
next-hop self;
accept;
}
}
term bgp-next-hop-self {
from protocol bgp;
then {
next-hop self;
accept;
}
}
}

on my ebgp sessions I'm exporting the following, which works fine - advertises the statics & the other BGP routes:

policy-statement ebgp-foo {
from protocol static;
then accept;

also, if I forget about injecting the statics into ibgp & just set n-h-s, then that works fine too:

policy-statement next-hop-self {
then {
next-hop self;
}
}

if someone could point out the error of my ways, I would be very grateful! the AS10 routers are Olives running 7.4, the AS1/AS2 routers are ciscos

thanks

Andy

Find more posts tagged with

Comments

networker050184

On your first policy there is not match clause at the end so it matches all routes which you are accepting. If you want to narrow down what you let it then use a match clause like you did in your second example.

andyh123

networker050184 wrote: »

On your first policy there is not match clause at the end so it matches all routes which you are accepting. If you want to narrow down what you let it then use a match clause like you did in your second example.

thanks for the reply, but it still doesn't make sense to me. let me try to explain my reasoning ...

AIUI, BGP is only meant to export BGP by default. in my ebgp-foo policy-statement, this exports statics & also exports BGP through an implied 'from protocol bgp'. what I'm not getting is why when I add a 'set next-hop self' to an implied 'from protocol bgp' in the first ibgp-foo policy-statement, this causes it to export all protocols

unclerico

Maybe I'm missing something here as well, but as Networker says your first statement has a catch-all at the end. When the policy is evaluated and the first term is not satisfied it falls through to the last statement which says to accept all routes and set NHS.

lrb

Yes the default policy for BGP is to export all active BGP routes but you're not ever hitting that default policy because the ibgp-foo policy statement at the end (the one without a match command so therefore match all) is catching all the routes. If you were to omit the last statement in both your cases, I think this would be what you want (1. export statics, 2. export BGP routes, 3. let everything else hit the default policy for the protocol). If you want to let it hit the default policy of exporting active BGP routes, then you don't need a catchall statement at the end of your policy-statement configs.

andyh123

thanks for the replies, it just clicked. what I wanted is either:

policy-statement ibgp-foo {
term redist-static {
from protocol static;
then {
next-hop self;
accept;
}
}
then {
next-hop self;
}

or

policy-statement ibgp-foo {
term redist-static {
from protocol static;
then {
next-hop self;
accept;
}
}
term bgp-next-hop-self {
from protocol bgp;
then {
next-hop self;
accept;
}
}

which do the same thing, the latter just more explicitly than the former