On Tue, Mar 12, 2013 at 08:10:12AM +0000, Stuart Henderson wrote: > We changed the default state from UNKNOWN to INVALID, but backup is > still DOWN (which probably needs to stay like that, most things do want > it to work like this but ospfd is a special case).
Still this feels wrong -- at least for my morning mind. Why should we annonce a stub network of a down carp interface in a RTR LSA? That box has no business to get the traffic and in the worst case all or some traffic will hit the backup box (depends on metrics). This will result in forwading troubles (at least I always get into trouble when that happens). Unlike passive interfaces that get an own NET LSA and can have a different metric stub networks can not do that. So we need to make sure that the resulting routing table on other systems stays correct. This is why I tell people to add carp interfaces as "interface carpX" to the config. -- :wq Claudio > Claudio Jeker <[email protected]> wrote: > > >On Mon, Mar 11, 2013 at 10:44:21PM +0000, Stuart Henderson wrote: > >> In gmane.os.openbsd.misc, you wrote: > >> > On 09/03/13 14:50, Stuart Henderson wrote: > >> >> Yes, the routes to carp interfaces in BACKUP are advertised but > >with a > >> >> low priority (better to have the route stay in the table, even if > >it goes > >> >> to a backup firewall, rather than have it drop in and out). > >> > > >> > Sorry to jump in, but Stuart are we sure about this? > >> > In a current setup only the active firewall (carp master) is > >advertising > >> > the network. > >> > >> Hmm. Well that is the idea, but it seems it was accidentally eaten > >> by a tidy-up diff (ospfe.c r1.83). This restores it: > >> > > > >Didn't we change the linkstate value for carp to be not not DOWN for > >backup and shouldn't LINK_STATE_IS_UP take care of that? > >Guess I need to start looking into that again. > > > >> Index: ospfe.c > >> =================================================================== > >> RCS file: /cvs/src/usr.sbin/ospfd/ospfe.c,v > >> retrieving revision 1.85 > >> diff -u -p -r1.85 ospfe.c > >> --- ospfe.c 17 Jan 2013 10:07:56 -0000 1.85 > >> +++ ospfe.c 11 Mar 2013 22:31:31 -0000 > >> @@ -870,9 +870,12 @@ orig_rtr_lsa(struct area *area) > >> * do not add a stub net LSA for interfaces that are: > >> * - down > >> * - have a linkstate which is down > >> + * unless they're carp, in which case down == backup > >> */ > >> if (!(iface->flags & IFF_UP) || > >> - !LINK_STATE_IS_UP(iface->linkstate)) > >> + (!LINK_STATE_IS_UP(iface->linkstate) && > >> + !(iface->media_type == IFT_CARP && > >> + iface->linkstate == LINK_STATE_DOWN))) > >> continue; > >> log_debug("orig_rtr_lsa: stub net, " > >> "interface %s", iface->name); > >> > >> > In advance I still cannot add carp interfaces (carpXX) to a > >different > >> > area except 0.0.0.0 > >> > http://marc.info/?l=openbsd-misc&m=136267654831883&w=2 > >> > >> No idea about this, config below pretty much works for me. > >> > >> area 0.0.0.1 { > >> stub > >> interface lo1 { passive } > >> interface vlan700 { > >> metric 4 > >> demote carp > >> } > >> interface carp193:xxxxx { passive } ## on vlan80 > >> interface carp410 { passive } > >> interface carp411 { passive } > >> interface carp412 { passive } > >> <...snip some lines...> > >> interface carp721 { passive } > >> interface carp881 { passive } > >> } > >> > >> Only problem is with the config parser getting confused about carp > >> interfaces added at runtime when the subnet is on both the vlan > >backing > >> interface and the carp interface because carp(4) doesn't send the > >> expected rtm's when the address is added in those cases. (Pondering > >> how best to fix that. It might be saner if ospfd notices the /32 > >> on the carp interface and picks a matching network on the carpdev > >> instead, as that would also sort out some lladdr confusion..).
