Hi Claudio, > Yes, since you disconnected the link between the carp interfaces without > dropping their physical connections both will become MASTER. > This normaly results in havoc since bad luck will flow all traffic to the > wrong box. This is the typical problem with too much redundancy (the > result has more error cases and is often less stable).
That makes sense. I guess the havoc can be resolved by either using ifstated or by not using carp on the inside lan and using OSPFd to advertise the correct routes since OSPFd plays nicely with carp. The later case is actually something that I am experimenting with as it seems like a simpler way to get the redundancy on the internal lan without using multiple switches for CARP interfaces. The other benefit to this is that ifstated does not need to be insanely complex if multiple interfaces are involved. > Yes, this is expected behaviour. You unplugged the cable to the physical > interface. Because of that the link state goes down and carp(4) noticed > it. Since that interface is no longer useable the carp demotion counter is > raised and so the other system (where all 3 carps are still fine) will > take over (the backup box is considered in better shape and becomes > master). That makes sense. So what will happen if the box that just became the master loses one of the interfaces as well? Will the demotion counter be raised on that box as well? Will the former box resume to be the master on the working interface? This could happen in the situation where there is a single interface for the inside lan on each box that advertises routes using OSPFd and two carp interfaces A and B for the external lans on each box. Suppose interface A physically fails on box 1 (either disconnected or port failure on the switch) and the demotion counter is raised making box 2 to be the master. Now, interface B fails on box 2 but is still available from box 1. In theory since routes are advertised using OSPFd both A and B can still be reached from their respective boxes 2 and 1, but that would work only if carp allows box 1 to become the master for interface B. Will this work based on what you have described above? > In your first case no interface failed and so both systems became master > (at least on that interface where the LAN was cut in two segments). In > this case both systems are equally healthy and so the demotion counter is > not raised. Definitely makes sense. Maybe this detailed explanation could be useful to someone else and could be added to the man page. I can potentially help out with that. > It is not a bug, it is the intended behaviour. > > -- > :wq Claudio Great! Thank you Claudio. --peter
