You sir have just made my weekend! :)
I thought that nexthop directive was a PF rule.. D'oh.. Clearly a long
week ;)
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).)
Absolutely.. I always put my carp interfaces into the same carp group
to ensure this.
Thank you very much, I will test this ASAP :)
Thanks again, Andy.
On Fri 15 Nov 2013 16:50:24 GMT, Adam Thompson wrote:
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.
