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: email@example.com 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: firstname.lastname@example.org 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 - Veritasemail@example.com http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha _______________________________________________ Veritas-ha maillist - Veritasfirstname.lastname@example.org http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha _______________________________________________ Veritas-ha maillist - Veritasemail@example.com http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha