Hi Marcus thanks.. I didn't think that was an issue when the arp storm pushed ff:ff:ff:ff:ff. I'm giving it a try.
I did notice in a vmware VMs, the client request does have the correct mac, but doesn't "always" make to through the stack. I'm tracking that down as well.. it could be the same issue, I can't inspect the routing tables on the vmware internal switch. again thanks On Fri, Aug 9, 2013 at 2:30 AM, Marcus Bointon <mar...@synchromedia.co.uk>wrote: > On 9 Aug 2013, at 06:29, Gary Mazzaferro <ga...@oedata.com> wrote: > > > Additionally, the traffic to the nodes seem interleaved, random > connection > > to node1/node2 from clients. > > > > And, when I shut down node2 or place it in standby, the VIP doesn't shift > > to node1, it appears the the node1 is down. > > This sounds like you may not have an ARP resource grouped with the IP, so > switches are serving to cached nodes. This is my usual config for managing > a floating IP: > > primitive ip2 ocf:heartbeat:IPaddr2 params ip=x.x.x.x cidr_netmask=24 op > monitor interval=10s nic="eth0" > primitive ip2arp ocf:heartbeat:SendArp params ip=x.x.x.x nic="eth0" > group proxyfloat2 ip2 ip2arp > location cli-standby-proxyfloat2 proxyfloat2 rule > $id="cli-standby-rule-proxyfloat2" -inf: #uname eq proxy1 and #uname eq > proxy2 > colocation ip_with_arp2 inf: ip2 ip2arp > order arp_after_ip2 inf: ip2:start ip2arp:start > > Change your IPs and node names as appropriate. > > Marcus > _______________________________________________ > Linux-HA mailing list > Linux-HA@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > _______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
