On Mon, 2015-07-20 at 22:58 +0200, Martin Pieuchot wrote:
> On 20/07/15(Mon) 19:10, Johan Ymerson wrote:
> > On 2015-07-18 16:03:00, Martin Pieuchot wrote:
> > > Committed! Thanks and sorry for the delay.
> >
> > Hi!
> >
> > You missed the previous patc
On 2015-07-18 16:03:00, Martin Pieuchot wrote:
> Committed! Thanks and sorry for the delay.
Hi!
You missed the previous patch "Fix ospfd segmentation fault on startup"
witch prevent ospfd from segfaulting on startup. Without this first
patch, ospfd will almost always segfault on startup (instead
Hi,
After the fix in carp to correctly initialize link state (ip_carp.c
r1.257), ospfd no longer detect all carp interfaces in "backup" mode
reliably on start-up. The problem is that carp interfaces in backup
state isn't handled the same way on start-up as it is when up and
running.
Here is an e
Hi,
When debugging problems with ospfd and carp on startup, I managed to get
ospfd to segfault a couple of times.
I tracked down the issue to if_change() and main_imsg_compose_ospfe().
if_change() is called before imsg_init is called to initialize the
imsgbuf struct. If a link state change to UP
vent), but is correctly reported as backup by ospfctl.
>From what I can see the event handler is correctly registered before
trying to start all interfaces in ospfe() so I really don't understand
where the race is.
/Johan Ymerson
On Wed, 20 May 2015 12:51:53 +0200
Martin Pieuchot wrote:
>
> > just for completeness: LINK_STATE_INVALID is 1, and that's what
> > carp_set_state uses for everything but master and backup. so far so
> > good.
> >
> > ifp is part of the sc which in turn is malloc'd with M_ZERO in
> > carp_clon
On Tue, 2015-05-19 at 11:16 +, Johan Ymerson wrote:
> On Tue, 2015-05-19 at 11:24 +0100, Stuart Henderson wrote:
> > On 2015/05/19 10:10, Johan Ymerson wrote:
> >
> > Yes I understand that, but if carp init was counted in "LINK_STATE_DOWN"
> > then th
On Tue, 2015-05-19 at 11:24 +0100, Stuart Henderson wrote:
> On 2015/05/19 10:10, Johan Ymerson wrote:
>
> Yes I understand that, but if carp init was counted in "LINK_STATE_DOWN"
> then the metric would be 65535 which I think would still avoid the
> problem you're
On Tue, 2015-05-19 at 10:10 +0100, Stuart Henderson wrote:
> On 2015/05/19 09:03, Johan Ymerson wrote:
> > On Fri, 2015-05-15 at 17:59 +0200, Johan Ymerson wrote:
> > > I have found a peculiar behaviour in ospfd when the physical link of the
> > > parent carp interface
On Fri, 2015-05-15 at 17:59 +0200, Johan Ymerson wrote:
> I have found a peculiar behaviour in ospfd when the physical link of the
> parent carp interface is down. The carp interface net is then announced
> with it's regular metric.
>
> An example:
> The cable
} else {
+ if (!LINK_STATE_IS_UP(iface->linkstate))
+ continue; /* UP or UNKNOWN */
+ }
+
log_debug("orig_rtr_lsa: stub net, "
"interface %s", iface->name);
Also, is the carp kernel code really correct when it leaves the
interface link state as "unknown" when in carp init state?
/Johan Ymerson
11 matches
Mail list logo
