.
Original Message
Subject: Re: BGP changes to support CARP better
Date: Wed, 22 Jan 2014 01:39:47 +0100
From: Henning Brauer lists-open...@bsws.de
To: Andy a...@brandwatch.com
I'm at a hackathon and can't analyse in detail, but from glancing over
I don't see
Hi,
Does anyone have an idea how I can get this nexthop qualify to work?
from the man page it says;
nexthop qualify via (bgp|default)
If set to bgp, bgpd(8) may use BGP routes to verify
nexthops. If
set to default, bgpd may use the default route to verify
Hi, I've got something really interesting to show, which shows this
clearly and should help point to the root cause.
In short, it seems that the desired nexthop is not applied by the CARP
master when it is in state 'nexthop 180.25.32.20 now valid: via
180.25.32.20'. I.e. when it is 'via' even
Hi,
Could someone help me with this issue we have found where the OpenBGPd
rule 'match to bgppeerip set nexthop bgpcarpip' doesn't work if OpenBGPd is
started whilst the OpenBSD host is a carp master. It only works if it is a
CARP backup :(
Or could someone give me a clue where in the source
andy [a...@brandwatch.com] wrote:
Hi,
Could someone help me with this issue we have found where the OpenBGPd
rule 'match to bgppeerip set nexthop bgpcarpip' doesn't work if OpenBGPd is
started whilst the OpenBSD host is a carp master. It only works if it is a
CARP backup :(
Or could
No, I'm seeing the same thing - the carp master advertises the carp IP as
next-hop no matter what.
The carp backup advertises whatever you've told it to advertise via set
nexthop.
-Adam
On Dec 2, 2013 6:43 PM, Chris Cappuccio ch...@nmedia.net wrote:
andy [a...@brandwatch.com] wrote:
Hi,
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
(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
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
On Fri, 15 Nov 2013 11:31:14 -0600, Adam Thompson athom...@athompso.net
wrote:
On 13-11-15 11:26 AM, Andy wrote:
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
On Fri, 15 Nov 2013 10:14:20 -0800, Chris Cappuccio ch...@nmedia.net
wrote:
Adam Thompson [athom...@athompso.net] wrote:
What have I missed? (Or is this yet another breakdown in OpenBSD's
documentation?)
If you find a deficiency in the documentation, please submit a patch.
Once I get
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
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
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
On 13-11-15 11:26 AM, Andy wrote:
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)
Adam Thompson [athom...@athompso.net] wrote:
What have I missed? (Or is this yet another breakdown in OpenBSD's
documentation?)
If you find a deficiency in the documentation, please submit a patch.
On 13-11-11 11:48 PM, 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
On Sat 09 Nov 2013 15:57:14 GMT, athom...@athompso.net wrote:
PS; We are against 'sloppy state' so much because we cannot sanitize
the sessions anywhere else (these firewalls connect to raw Transit).
In the meantime I think we're going to be forced to use ifstated to
shutdown OpenBGPd on the
On 13-11-11 06:18 AM, Andy wrote:
On Sat 09 Nov 2013 15:57:14 GMT, athom...@athompso.net wrote:
PS; We are against 'sloppy state' so much because we cannot sanitize
the sessions anywhere else (these firewalls connect to raw Transit).
In the meantime I think we're going to be forced to use
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
Oh. Duh. That makes perfect sense...
I can't test it until tomorrow morning but that solves all the problems, I
think.
-Adam
Chris Cappuccio ch...@nmedia.net wrote:
Adam Thompson [athom...@athompso.net] wrote:
Well, you could - perhaps - flip this on its head. Instead of changing BGP,
PS; We are against 'sloppy state' so much because we cannot sanitize
the sessions anywhere else (these firewalls connect to raw Transit).
In the meantime I think we're going to be forced to use ifstated to
shutdown OpenBGPd on the backup :(
Ugly and very slow, but I would rather this than
Hi,
We have upgraded to 5.4 in production and now have our OSPF routes being
announced from our CARP 'backup' with a max value metric, and the CARP
'master' announcing with the default/defined metrics. This works great
in testing so far and directs all traffic to the CARP master.
Would it
PS; We are against 'sloppy state' so much because we cannot sanitize
the sessions anywhere else (these firewalls connect to raw Transit).
In the meantime I think we're going to be forced to use ifstated to
shutdown OpenBGPd on the backup :(
Ugly and very slow, but I would rather this than
24 matches
Mail list logo
