<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Etherchannel on sigtar.com</title>
		<link>https://sigtar.com/tags/etherchannel/</link>
		<description>Recent content in Etherchannel on sigtar.com</description>
		<generator>Hugo</generator>
		<language>en-nz</language>
		
		
		
		
			<lastBuildDate>Wed, 14 Mar 2012 00:00:00 +1300</lastBuildDate>
		
			<atom:link href="https://sigtar.com/tags/etherchannel/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>LACP - HP vs Cisco</title>
				<link>https://sigtar.com/2012/03/14/lacp-hp-vs-cisco/</link>
				<pubDate>Wed, 14 Mar 2012 00:00:00 +1300</pubDate>
				<guid>https://sigtar.com/2012/03/14/lacp-hp-vs-cisco/</guid>
				<description>&lt;p&gt;Great article on setting up connection between HP &amp;amp; Cisco&amp;hellip;.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;http://evilrouters.net/2011/08/12/configure-lacp-between-hp-procurve-and-cisco-catalyst-switches/&#34;&gt;http://evilrouters.net/2011/08/12/configure-lacp-between-hp-procurve-and-cisco-catalyst-switches/&lt;/a&gt;&lt;/p&gt;</description>
			</item>
			<item>
				<title>vmware - hp procurve lacp / trunk</title>
				<link>https://sigtar.com/2010/09/21/vmware-hp-procurve-lacp-trunk/</link>
				<pubDate>Tue, 21 Sep 2010 00:00:00 +1200</pubDate>
				<guid>https://sigtar.com/2010/09/21/vmware-hp-procurve-lacp-trunk/</guid>
				<description>&lt;p&gt;Cisco&amp;rsquo;s Etherchannel and HP&amp;rsquo;s LACP are very similar – probably why I assumed both are supported by vmware. But as per below – it is not the case.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&amp;amp;cmd=displayKC&amp;amp;externalId=1004048&#34;&gt;http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&amp;amp;cmd=displayKC&amp;amp;externalId=1004048&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;From a procurve perspective the differences between a “trunk” and “static lacp” trunk is the total bandwidth &lt;strong&gt;per connection&lt;/strong&gt;. A typical end point on a “trunk” trunk can transmit various connections down both pipes, but only receive down one – sometimes refered to as TLB (transmit load balancing). In vmwares case when you are using a &amp;ldquo;trunk&amp;rdquo; trunk you will have ip hash set as a load balancer, effectively meaning a different nic will be used on the vmware side for each connection a virtual machine makes.&lt;/p&gt;</description>
			</item>
			<item>
				<title>ESX - network utilization</title>
				<link>https://sigtar.com/2009/08/22/esx-network-utilization/</link>
				<pubDate>Sat, 22 Aug 2009 00:00:00 +1200</pubDate>
				<guid>https://sigtar.com/2009/08/22/esx-network-utilization/</guid>
				<description>&lt;p&gt;One of the best articles i have found on this subject is here : &lt;a href=&#34;http://blog.scottlowe.org/2008/07/16/understanding-nic-utilization-in-vmware-esx/&#34;&gt;http://blog.scottlowe.org/2008/07/16/understanding-nic-utilization-in-vmware-esx/&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;There is some additional information here on setting up an etherchannel on the cisco side : &lt;a href=&#34;http://blog.scottlowe.org/2006/12/04/esx-server-nic-teaming-and-vlan-trunking/&#34;&gt;http://blog.scottlowe.org/2006/12/04/esx-server-nic-teaming-and-vlan-trunking/&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;This can be handy if you need a single VM to use both physical nics in a load-balanced manner - both outbound and &lt;strong&gt;inbound&lt;/strong&gt;. Of course its not really that simple though. This will really only add a benefit if the VM is communicating to &lt;em&gt;multiple&lt;/em&gt; destinations (using ip hash - a single destination from a single VM with one IP will always be limited to the same physical nic).&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
