interface ;)
>
> Have fun at the hackathon :)
>
> PS; Enjoyed your new queuing subsystem talk at EuroBSDcon.
>
> Thanks again, Andy.
>
>
> Original Message
> Subject: Re: BGP changes to support CARP better
> Date: Wed, 22 Jan 2014 01
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
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 wrote:
>
> andy [a...@brandwatch.com] wrote:
> > Hi,
> >
> > Cou
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
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 cod
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
n
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 bel
(Apologies for top-posting)
I've seen the same thing, but I assumed I'd made a mistake somewhere. Maybe
not.
-Adam
Andy 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
On Fri, 15 Nov 2013 10:14:20 -0800, Chris Cappuccio
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 round to pu
On Fri, 15 Nov 2013 11:31:14 -0600, Adam Thompson
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 that the
>
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-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)
interf
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
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 -
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 loc
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
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 wrote:
>Adam Thompson [athom...@athompso.net] wrote:
>>
>> Well, you could - perhaps - flip this on its head. Instead of changing BGP,
>> what about
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 prependin
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 ifsta
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 bac
> 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
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 ris
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 be
24 matches
Mail list logo
