Ah, so we have a potential bug here then I'm thinking!
After all, why would the setting of nexthop have anything to do with
CARP?
On Thu 21 Nov 2013 16:14:33 GMT, Adam Thompson wrote:
(Apologies for top-posting)
I've seen the same thing, but I assumed I'd made a mistake somewhere. Maybe
not.
-Adam
Andy <a...@brandwatch.com> wrote:
On 15/11/13 16:50, 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.
Hi, I have observed some strangeness with this! :(
I have two OpenBSD firewalls running in a CARP pair. Each firewall in
the pair has a single eBGP neighbor with the same single Cisco router
using its physical IP with no 'depends on' statement.
I have added the following line to /etc/bgp.conf on both firewalls;
match to 170.16.3.1 set nexthop 170.16.3.4
NB; 170.16.3.1 is the Cisco router and 170.16.3.4 is the CARP IP of the
firewall pair.
If I start BGP on FW1 (master), the announced network seen in the Cisco
has a nexthop = the physical IP and not the CARP IP :(
If I start BGP on FW2 (backup), the announced network seen in the Cisco
has a nexthop = the CARP IP :)
Hmm, strange.. Maybe something is wrong with the master config I
thought, but lets just try switching CARP first.
So I stopped OpenBGPd on both and swapped the CARP master to be the
other firewall etc.
If I start BGP on FW1 (backup), the announced network seen in the Cisco
has a nexthop = the CARP IP :)
If I start BGP on FW2 (master), the announced network seen in the Cisco
has a nexthop = the physical IP and not the CARP IP :(
This is really strange! It seems that only the CARP backup sets the
nexthop properly.
Just for kicks, I shut down BGP on both and restarted BGPd on just the
backup. Cisco shows one route via the CARP IP as wanted.
I then swapped the CARP master again, and started BGP on the other
firewall (just made backup). And now the Cisco shows two routes both via
the CARP IP... This is what we want all the time.
This confirms that if BGP is started when its the backup it works, but
if its started when its the master, its the nexthop is the physical IP?
Any thoughts as I'm lost.. This is just strange!
Cheers, Andy.
'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.
