On 4 December 2010 01:12, Dimitri Maziuk <[email protected]> wrote: > Pavlos Parissis wrote: > >> I've just done a quick test. Since I don't have physical access on >> systems, I shutdown the port on the switch and run ping on the IP >> assigned to the interface, which has NO-CARRIER flag on and flag >> LOWER_UP was gone. The ping was successful! >> I am not 100% sure that shut-downing the port on the switch simulates >> 100% the removal of the cable but I don't think pinging the IP of the >> interface is the best option for identifying layer1 and layer 2 >> problems. May be that is the reason the ping functionality is not on >> IPaddr2. > > IPaddr2 doesn't have the "monitor" option at all. > > I doubt you can be 100% sure of the monitor results: if you ping the > interface itself, kernel may (arguably, should) be smart enough to send > the packets to lo. If you ping the gateway, switch (or gateway, or > firewall) reset will cause it to fail on both nodes at once. You may be > better off grepping for "link detected" in the output of ethtool -- > that's not portable and may change in the next version of ethtool. And > so on.
Will make no sense to ping a device which doesn't allow ICMP or denies them under certain conditions. At the moment someone configures ping resource he/she has already made sure that ping target hosts allow ICMP. At the moment you are depending on monitor results of a component outside of the cluster control you take the risk of running into a situation where false results can cause unavailability of your service. I have always believed that if you put an application under cluster control then you also put under cluster control any resource which the application depends on. If you do that then you wont run into situations with false results, since these resources are always available and if not Cluster will take the right decision. In this particular case, I believe you can safely depend on a component outside of the cluster control, the ping target, if the following are true 1) if a single target is used and there is layer 2 (redundant switches with Spanning Tree enabled) and layer 3 (HSRP or similar protocol) availability. or if multiple targets are used and you consider a failure on the link if all targets are inaccessible 2) if the loss of the target(s) nodes makes your service inaccessible to the clients Since the above can't be applicable for all cases, I believe IPaddr2 should have a way to identify failure on the link without the usage of Layer 3 protocol. If someone wants connectivity test as part of the IP monitor then he can use the already available method of ping resource. Cheers, Pavlos _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
