Hi Matthew,

Unfortunately Nexenta doesn't have a bonding like feature. Only thing you can do via the GUI is link aggregation, but that will only work for switch redundancy if you have stackable switches.

If what you are looking is a Active-Passive bonding type(mode=1) you can achieve that using IPMP(IP Multipath), but that's something Nexenta never cared much to get on the GUI, so you have to do some work on command line. It does the job but I would still prefer to have a bonding like driver.

Thanks so much for your response.

I.m not sure what the exact terminology is but on openfiler it was a bonded nic for load balancing. Basically I would like to add more than one nic and have the transferred data split over the nics to increase the transfer speed.

I am also very new to command line so any step by step instruction would be great :)

Thanks again

If you want higher throughput than that is port aggregation and that you can make on the GUI of Nexenta(create an aggregated interface-aggr1), but be in mind that only works if the links go to the same switch or if the switches are stackable (and the switchports are configured as a portchannel using Cisco as example)

Link Aggregation

IPMP

NexentaStor supports both technologies. As i remember we added IPMP configuration to NMV/NMC in 3.1.3, but i am not sure :-)

Attached are instructions and a script to configure IPMP.

SFTP the script to /tmp using a program like winscp or filezilla. the follow the instructions. Once you reboot the IPMP interface should be configured. Be sure to take a checkpoint before you start.

No Roman, Nexenta never got IPMI into the NMV. They expect everybody have stackable switches or I guess it's not something that can be used to do much marketing about :-)

Thanks for the script Tommy. I tried it and it worked for me. Does that download and documentation exist anywhere else on the nexenta site?

The files are also available in the support.nexenta.com knowledge base.

Much more simpler way to get IPMP working without reboot. The result is linux bond-like configuration. No probes.

Create config files to stay persistent across reboot.

echo ipmp group bond1 10.0.0.21/24 up > /etc/hostname.bond1
echo group bond1 -failover up > /etc/hostname.bnx0
echo group bond1 -failover up > /etc/hostname.bnx1

Make the same with console.

ifconfig bond1 ipmp group bond1 10.0.0.21/24 up
ifconfig bnx0 group bond1 -failover up
ifconfig bnx1 group bond1 -failover up

Make sure everything is up and working.

ipmpstat -a
ipmpstat -i
ping 10.0.0.1

Destroy all.

ifconfig bnx0 group "" failover -deprecated
ifconfig bnx1 group "" failover -deprecated
ifconfig bond1 unplumb
rm /etc/hostname.{bond1,bnx0,bnx1}

And even better, in 3.1.4 IPMP is supported trough the NMC/NMV.

Um, I suppose for reference I should put this here, but in 3.1.4 adding the failover parameter in hostname.link file actually activates ICMP probe detection it seems, but the system randomly picks a probe target.

stacked IPMP and aggregates

seems to show the random probe target selection issue (you apparently need hard routes to trick the daemon into picking known targets)

Fooling around with it though, I get weird ipmpstat behavior. The IPMP address seems to work fine, but ipmpstat -a shows an up state but no outbound interfaces and ipmpstat -g lists the ipmp group as failed with no interfaces even though I can ping it and use the web GUI. Though I am doing the extreme of 2 double aggregates IPMP'd together, with only one NIC up.

Need to spend time with 4.0 beta to see if anything's changed.

Update:1

maybe things aren't working after all, after a reboot...

Update:2

Seems a reboot fails spectacularly. The underlying aggr1/aggr2/ipmp0 comes up at boot but any aggregate VLAN's and the related IPMP interface fail, with warnings that the VLAN aggregates can't be plumbed and their addresses are being moved to the associated IPMP interface. What's interesting is what dladm is reporting, as show-link shows the underlying true aggregates only, and show-vlan comes back empty. Trying to recreate the aggregate VLAN fails though, because there are still entries in /etc/dladm/datalink.conf that block creation, but somehow are not being used. NMC shows something weird as well, as inside "setup network interface vlan" the aggregate VLAN based IPMP interfaces are showing up, and trying to do a show fails as dladm is looking for ipmiXX00X rather than a registered physical/aggregate/VLAN interface, which naturally doesn't exist in dladm's area of management.

So, entering the stuff as the blog post states works, but rebooting creates a mostly broken network configuration. Trying to do the last step in the blog post of cycling disable/unplumb/enable again throws the same errors as boot after the restart, so something with how interfaces are done during boot is screwy (the error is probably the result of the aggregate VLAN's disappearing from dladm?)

Would this be considered a 3.1.4 bug considering the configuration seems to work until the reboot?