Solaris

Hi everybody,

One client asked me to configure network failover and load balancing for two Ethernet interfaces, I tried IPMP but I was unable to do so, because he's using his Gateway as firewall and PING is disabled.

so IPMP kept telling me that all interfaces failed because gateway can't be pinged.


I thought of using Link Aggregation, but I have never used it before.

So can anybody tell me the difference in the failover and loadbalancing provided by IPMP and link aggregation?

And what are the limitations of Link Aggregation ?

As far as i know you cannot do failover with link aggregation as linkaggregation wants you to have both the interfaces on the same switch and that defies the impm configuration basic which wants you to have the interfaces on 2 different switches .. that what i know correct me if wrong.

here is an article regarding some differences between them: Nicolas Droux' Blog

so fugitive is basically right. link aggregration is the act of basically taking multiple ethernet cables and trunking them together to increase the link speed beyond the limits of any one single cable or port, and to increase the redundancy for higher availability. at my shop, we do this to the same switch to increase our copper backup network speed (1 cat6 line to 2 cat6 lines, thus allowing for 2 gig limit). we use a juniper ex4200 that already comes more or less out of the box to do LA (although these switches i feel are a pain to deal with).

here is an article on how to work with dladm: Solaris tip of the week: Link Aggregation and Logical Interfaces - greetings from network.com

as for ipmp, you are looking to run 2 ethernet cables to two seperate switches which gives you the HA situation but not just at the host, but the switch and essentially the router levels (if you have cross-connects between switches and routers).
for ipmp, check out this article: Solaris IP Multipathing made easy

IPMP has two modes for checking the health of an interface:
a) Link Status
b) External ping


Utilizing the Link Status method (as provided by the NIC driver) should solve your issue. Assuming bge0 and nxge0, here is how to set it up.

Code:

I. Put and IP address and IPMP group name on the 1st NIC:

   /etc/hostname.bge0:
  192.168.1.1 group ipmp_front up

II. Put the same group name on the 2nd NIC:

   /etc/hostname.nxge0:
   group ipmp_front up

III. Then reboot to take effect.

This will create and active/passive IPMP failover group with outgoing load-balancing.

KW

Is the reboot necessary? This should be possible to setup by an unplumb/plumb sequence as well.

Hi

I thought that what ever route host statement you've manually added, ipmp would use this host to `ping` when deciding to failover. So, on the network, find 3 hosts that you can create a direct link into within your routing table and use those. E.g.

# Copyright (c) 2003 by Sun Microsystems, Inc.
# All rights reserved.
#
#ident "@(#)staticroutes 1.0.1
#
# Edit the following IPMP test TARGETS to suit your needs.
# To install:
# 1) cp S70staticroutes to /etc/rc2.d
# 2) perform edits on the script as required
# 3) chmod 744 /etc/rc2.d/S70staticroutes
# 4) chown root:sys /etc/rc2.d/S70staticroutes
# 5) ln /etc/rc2.d/S70staticroutes /etc/init.d/staticroutes
#
TARGET1=148.253.132.10
TARGET2=148.253.132.11
case "$1" in
'start')
/usr/bin/echo "Adding static routes for IPMP ..."
/usr/sbin/route add host $TARGET1 $TARGET1
/usr/sbin/route add host $TARGET2 $TARGET2
;;
'stop')
/usr/bin/echo "Deleting static routes for IPMP ..."
/usr/sbin/route delete host $TARGET1 $TARGET1
/usr/sbin/route delete host $TARGET2 $TARGET2
;;

SBK

Frozentin,
Yes, ifconfig can be used to setup IPMP live, but you still need to configure hostname.xxx files to make it persistent across reboots.

Reiterating, IPMP has two failure detection modes: 1) pinging, typically a router, 2) link status on the NIC, which does not ping. I have found link status to be a dependable IPMP failover trigger, conversely, I have found the ping method to falsely trigger failover when the default router was busy and could not respond to ping in a timely manner (but this is very rare).

KW