Hi Dana,

We were talking about Linux bonding compared to Solaris IPMP.
While Solaris link aggregation (apparently) cannot do active/backup, Linux
can, and therefore in Linux you can put each link on a separate switch
(http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentati
on/networking/bonding.txt).
The whole point of the discussion was how to take the level of redundancy
you get for LLT in Linux by using bonding to Solaris by using pure LLT level
solution instead of counting on OS specific solutions (As IPMP doesn't
actually create a logical interface, LLT cannot use it).


-----Original Message-----
From: Hudes, Dana [mailto:hud...@hra.nyc.gov] 
Sent: Tuesday, May 12, 2009 11:28 PM
To: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

Bonding is combining multiple links into one virtual circuit. It isn't
usually visible to the OS. IPMP is a bit different. While the result is
similar, it's a question of at what level of the tcp/ip stack the
combination is done. Bonding is at the media (MAC) layer from an IP
perspective (though the OSI model breaks the layers down differently).
IPMP is at the network layer. 

If the combined connections have individual IP addresses, that's
multi-path not bonding. 

There are implications here beyond clustering, including the switch and
the router as well as how the increase in bandwidth (if both links are
active at once) is achieved.  More usual is the use of IPMP to provide
standby links: each link has its own IP address and there is an IPMP IP
address. Remote hosts use the IPMP address. Often, you will have a
primary link which is higher speed / larger bandwidth than the secondary
(e.g. gigabit primary and 100 megabit secondary).

If you are bonding you must go to the same switch with both links. This
provides protection, in the form of degradation of capacity, against
port failure on either end of a given path or cable failure of a given
path. It does not protect you against switch failure.

IPMP, when done properly, has two paths each going to a separate switch.
This protects against everything that bonding does while also protecting
against switch failure. In the case of switch failure, the standby port
becomes active and ARP answers for the virtual IP on that port. The
routing protocol, which hopefully is OSPF, quickly redirects the traffic
to the new port and you don't even lose your TCP connection due to
retransmit (some UDP packets inevitably are lost; an application
protocol may have it's own retransmit timer but that's not UDP's
business).



=================
Dana Hudes
UNIX and Imaging group
NYC-HRA MIS
+1 718 510 8586
Nextel:  172*26*16684
=================

-----Original Message-----
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Imri
Zvik
Sent: Sunday, May 03, 2009 12:18 PM
To: Jim Senicka
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

On Sunday 03 May 2009 19:03:16 Jim Senicka wrote:
> This is not a limitation, as you had two independent failures. Bonding
> would remove the ability to discriminate between a link and a node
> failure.

I didn't understand this one - With bonding I can maintain full mesh 
topology - No matter which one of the links fails, if a node still has
at 
least one active link, LLT will still be able to see all the other
nodes. 
This achieves greater HA than without the bonding.


> My feeling is in the scenario you describe, VCS is operating properly,
> and it is not a limitation.

Of course it is operating properly - that's how it was designed to work
:)
I'm just saying that the cluster could be more redundant if it wasn't
designed 
that way :)

> If you have issues with port or cable failures, add a low pri
connection
> on a third network.



_______________________________________________
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
_______________________________________________
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

_______________________________________________
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

Reply via email to