On 13-11-15 04:17 AM, Andy wrote:
On 12/11/13 05:48, Chris Cappuccio wrote:
Two BGP sessions from different IPs (no CARP)
BGP next-hop pointing to CARP-protected IP
Hi Chris,
This sounds good.. Could you clarify further?
I can clarify for him, see below. (Apologies if he's already done it -
I'm on the daily digest.)
Setup eBGP to the Transit router on both OBSD boxes using physical
IPs, and iBGP between the OBSD routers. Got that working fine without
'depends on' (don't want the BGP teardown/setup delay.
Yup.
How are you configuring the BGP next-hop to the CARP IP??
"match to x.x.x.x set nexthop x.x.x.x"
"allow from any"
"allow to any"
Hi Adam,
The problem is to do with ensuring inbound packets always go to the
CARP master.
That's what "set nexthop" does in BGP - it tells the *other* router what
to use for its nexthop.
'match to X.X.X.161 set nexthop X.X.X.162' Wouldn't this only mean
that the outbound packets would egress to the transit via the CARP IP?
Its the inbound control that's needed.
Nope. It's actually much more difficult to control the egress IP, AFAIK.
I was thinking about using ifstatd to dynamically change the MED /
path prepending based on the CARP status, rather than trying to force
which router is master. Experience says that fail-overs happen for
many reasons (probably once every couple of months), but so far never
because the master is actually dead, which means BGP will pretty much
always be left running on the old master (unless ifstatd does
something to it)..
With 'set nexthop', it's OK if the old BGP session stays up - packets
will always come inbound to the CARP master. You don't need to do
anything to bgpd or routing tables on the old box.
What you *might* have to do is use ifstated(8) to ensure that the "LAN"
carp(4) interface always stays in sync with the "WAN" carp(4)
interface. (i.e. router #1 being master for inside-facing while #2 is
master for outside-facing will break pf(4).)
I just can't seem to figure out a true clean way of doing this without
configuring multiple BGP attributes in OpenBGPd based on CARP status :(
I think that's only because you had the wrong end of the stick for the
nexthop attribute.
PS; For inbound path control which would you recommend? MED or padding
the AS path? I.e. is one potentially more responsive than another..
Neither! Just "set nexthop" appropriately.
--
-Adam Thompson
athom...@athompso.net
Cell: +1 204 291-7950
Fax: +1 204 489-6515
