On 12/11/13 05:48, Chris Cappuccio wrote:
Adam Thompson [athom...@athompso.net] wrote:
Well, you could - perhaps - flip this on its head. Instead of changing BGP,
what about forcing one router to be the master (via advbase/advskew),
advertising a lower BGP preference (probably by using both localpref for
iBGP and path prepending for eBGP) from the slave, using pfsync (default,
not defer) to sync the state tables, and simply assuming that if the slave
becomes the master it's because the master is dead, so losing a few packets
isn't the end of the world?
If you're talking about eBGP..or even iBGP for that matter, an interesting
way to go could be:
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?
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.
How are you configuring the BGP next-hop to the CARP IP??
Hi Adam,
The problem is to do with ensuring inbound packets always go to the CARP
master.
'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.
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)..
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 :(
PS; For inbound path control which would you recommend? MED or padding
the AS path? I.e. is one potentially more responsive than another..
Cheers, Andy.
