Link-based IPMP setup with VCS

network, Solaris, vcs

With Solaris 10 came a nice feature – Link-based IP Multipathing (IPMP). It determines NIC availability solely on the NIC driver reporting the physical link status – UP or DOWN. Previous versions used “probe-based” IPMP, where connectivity is tested by pinging something on the network from each interface. While probe-based is actually a more thorough test (tests network layer 3 as well as 2), it is much more cumbersome to configure, and you need an extra IP address for each interface for “test” addresses. IMO Link-based IPMP is sufficient for most applications.

For some reason, configuring link-based IPMP in VCS is somewhat tricky, and the documentation doesn’t seem to help much. It seems all the default values for VCS are for probe-based IPMP only.

To achieve link-based IPMP, here’s how I’ve configured my MultiNICB resource:

Link-based IPMP MultiNICB properties

Link-based IPMP MultiNICB properties


These are the values you must change from the defaults:

UseMpathd: 1
Tells VCS to use mpathd for network link status
MpathCommand: /usr/lib/inet/in.mpathd -a
The default, /usr/sbin/in.mpathd is just incorrect – it doesn’t live there.
ConfigCheck: 0
If you leave this at 1, it will overwrite your /etc/hostname.xxx files with probe-based IPMP configuration
Device: (your IPMP interfaces here)
The “interface alias” for each device is not needed, leave them blank.
IgnoreStatus: 0
You want VCS to NOT ignore link status, since this is how link-based IPMP works.
GroupName:
Do not use your IPMP group name here, it’s not needed. VCS is not monitoring the group, mpathd is.

Here’s how it looks in main.cf:

MultiNICB csgmultinic (
UseMpathd = 1
MpathdCommand = “/usr/lib/inet/in.mpathd -a”
ConfigCheck = 0
Device = { ce0 = “”, ce4 = “” }
IgnoreLinkStatus = 0
)

Share

8 Responses

  1. Charles says:

    What if you’re using aggragates like so:

    [Wed Jul 01 11:47:36 root@wolverine: MP3] # ifconfig -a
    lo0: flags=2001000849 mtu 8232 index 1
    inet 127.0.0.1 netmask ff000000
    aggr1: flags=201000843 mtu 1500 index 2
    inet 10.110.18.97 netmask fffff000 broadcast 10.0.31.255
    groupname production
    ether 0:15:17:ad:2:46
    aggr1:1: flags=209040843 mtu 1500 index 2
    inet 10.110.18.95 netmask fffff000 broadcast 10.0.31.255
    aggr2: flags=201000843 mtu 1500 index 3
    inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
    groupname production
    ether 0:21:28:14:dd:1e
    aggr2:1: flags=209040843 mtu 1500 index 3
    inet 10.110.18.96 netmask fffff000 broadcast 10.0.31.255

  2. admin says:

    To be honest I’ve never tried it with aggregates. Have you tried just using the aggregate names in the devices instead of the physical interface names? Not sure how or if mpathd works with aggregates.

  3. this is a greatly interesting enter, thank you for the information. Pitiful my english is not the uncommonly best. do you remember if it is practicable to translate this to the spanish language. that would be very helpfull.

  4. Have you seen Rio’s tweets about this?

  5. In my next article I’m preparing to reveal to you my thinking process when is shows correspondence to this.

  6. You really make it seem so easy with your presentation but I find this matter to be really something that I think I would never understand. It seems too complicated and very broad for me. I am looking forward for your next post, I will try to get the hang of it!

  7. Jacobs Greg says:

    Some truly good blog posts on this web site , regards for contribution.

  8. Laurene Menn says:

    Your blog is amazing, i subscribed your blog!