Hi Claudio,
thanks a lot for your prompt reply!
On Jul 3, 2006, at 4:32 PM, Claudio Jeker wrote:
as "network x.x.x.x/19" sends the announcement stating that $peerip
is the
nexthop, I am not using "depend" options on carp, what I want is that
<snip>
I guess you want to set the nexthop to the $carpip instead.
Sure, typo on my side.
- Having inside the "neighbor" configuration block a "set nexthop
$carpip",
but this seems to be plainly ignored
This will change the incomming routes and not the outgoing ones.
Yes, it actually did change incoming routes (which I forced back outside
the neighbor block) but did nothing on the outgoing announce.
- Having an explicit "match to $peerip set nexthop $carpip", but that
seems
to affect only routes re-announched to the peer and not routes
coming
from my "network a.b.c.d/19" option.
match to + set nexthop was "broken" until recently. The problem is
that
nexthops are added and verified asynchronously and so setting them on
outgoing rules did not work. I fixed this by preloading nexthops
that are
used by the filters.
YES!
This was the trick: upgraded to current (the snapshot of Jul 03) and
added a match to $peer_colt set nexthop $carp_colt
where carp_colt = "62.152.98.4", now this is the announce out:
Update Message (2), length: 45
Origin (1), length: 1, Flags [T]: IGP
AS Path (2), length: 4, Flags [T]: 35193
Next Hop (3), length: 4, Flags [T]: 62.152.98.4
Updated routes:
85.239.160.0/19
With -current it works like a charm, I have it in production right now.
Have you tried
network a.b.c.d/19 set nexthop $carpip
This would not be possible, obviously (not obvious because I
did not say it, but it is so) each of our BGP routers has multiple
sessions with sifferent peers, each on a different interface with
a different CARP IP.
Map at http://www.break.net/~blackye/routing20060621.pdf
As you see OpenBGPd is doing a great job for us!
First try the "network a.b.c.d/19 set nexthop $carpip" option if
that does
not help you need to run a -current bgpd. Additionally
mrt_dump_bgp_msg()
is totaly the wrong spot to fix this. The code is more in
rde_update.c and
rde_filter.c plus some parts in rde_rib.c.
I am sorry I did not really have the chance (or did not apply enough
time)
to understand the code structure in deep enough (lost into qmail-ldap
code these days :-), this morning I looked better because I also had
to port the -current bgpd on FreeBSD (we run this other *BSD brother :)
which involved stripping out the carp.c code (FreeBSD does not have
interface groups AFAIK).
Looking at the rationale behind that code I found interesting that it
does
something very similar to what we do here with a shell script: if the
main
router has one or more sessions down widthdraw its precedence on
CARP interfaces.
Only point of difference is that in the script we "lower" the precedence
of 100 if one peer is down, of 200 if all peers are down, adding this
with a base delta of 50 between the master and slave routers always
keeps the one "in better shape" as both ingress and egress traffic.
Another difference is that I think CARP interfaces should be demoted
when bgpd is.. actually not running!
Perhaps a per-peer config option like "promote <mask> <delta>" which
actually promotes the skew of interfaces matching <mask> of a value
<delta> would be more flexible (so one might boot with carp interfaces
at skew say 200 and promote them of 50 for each session which is up).
If anyone needs the script we use it can be downloaded here (no
guarantees, and surely needs to be hacked for your environment):
http://www.break.net/~blackye/bgprobe
I am managing to have the openbgpd-20060703 snapshot go into the
FreeBSD's ports, if anyone can't wait take the tarball of the package
at http://www.break.net/~blackye/openbgpd-devel.tgz and the snapshot
at http://www.break.net/~blackye/openbgpd-devel-20060703.tgz
So if one needs the current version of FreeBSD _now_ this:
curl http://www.break.net/~blackye/openbgpd-devel-20060703.tgz \
> /usr/ports/distfiles/openbgpd/openbgpd-devel-20060703.tgz
cd /usr/ports/net
http://www.break.net/~blackye/openbgpd-devel.tgz | tar zpxf -
portinstall openbgpd-devel
... will do the job.
Claudio, you have been very kind in responding so quickly, thanks a lot,
I see that most of the work done in porting openbgpd on FreeBSD is
quite non-intrusive, if you agree I might prepare a clean and non-
intrusive
pach that makes it a bit more platform independent without affecting
any feature on OpenBGPd (perhaps for who does not have interface
groups we might use masks, like "carp*")
Ciao and thanks,
Andrea