In our case, link state is an issue because your immediate neighbor switch could have link up, but the uplinks from that switch to the distribution layer could be gone. :-)
After we get clear of a big event that's happening this week, our game plan is to SPAN their port and get a frame capture of what's going on as the machine boots. This should help us determine why the host thinks that a unicast ping to the default gateway is failing. Thanks to all for the responses... From: tech-boun...@lopsa.org [mailto:tech-boun...@lopsa.org] On Behalf Of Doug Hughes Sent: Wednesday, September 15, 2010 2:58 PM To: tech@lopsa.org Subject: Re: [lopsa-tech] Solaris IP multipath behavior On 9/15/2010 12:50 PM, Jeremy Charles wrote: One of our server admins is telling me that his Solaris server's IP multipathing software is checking connectivity to the default gateway by sending ICMP echo requests addressed to the following: MAC address ff:ff:ff:ff:ff:ff IP address 0.0.0.0 He's telling me that the Solaris host is expecting to see the default gateway respond to that. Does anyone else view this as one or more of the following: 1) The actual expected behavior of Solaris IP multipathing 2) Something isn't completely configured 3) Non-intelligent design My google-fu is coming up empty on trying to either substantiate this as the expected behavior or provide troubleshooting help. (The operational problem is that the Solaris host is in a subnet where the default gateway is a Cisco Firewall Services Module, which doesn't respond to the above. There are two Solaris hosts in that subnet and they DO respond to those pings. Unfortunately, when one Solaris host goes down, the other one stops seeing the ping responses, so it takes down its services too.) I haven't done anything with in.mpathd in a while, preferring to do trunking almost exclusively anymore (LACP), but, there are 2 ways to do mpathd that are documented. 1) using ICMP packets (though it leaves unspecified the precise details of this. the one you mention above is plausible. I'd have to sniff an in.mpathd before I answered this one, and I don't have one running) 2) using linkstate. You can set it to only watch the link state and then do the failover. Maybe you should configure mpathd to use method 2 in your circumstance, though it is not without its own problems. It's perfectly plausible for the link to be up and not passing any packets, especially when firewalls are involved.
_______________________________________________ Tech mailing list Tech@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
