<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: TA2384 &#8211; Deploying the Nexus 1000V</title>
	<atom:link href="http://blog.scottlowe.org/2009/09/02/ta2384-deploying-the-nexus-1000v/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.scottlowe.org/2009/09/02/ta2384-deploying-the-nexus-1000v/</link>
	<description>The weblog of an IT pro specializing in virtualization, storage, and servers</description>
	<lastBuildDate>Wed, 08 Feb 2012 17:13:47 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
	<item>
		<title>By: Nico</title>
		<link>http://blog.scottlowe.org/2009/09/02/ta2384-deploying-the-nexus-1000v/comment-page-1/#comment-47352</link>
		<dc:creator>Nico</dc:creator>
		<pubDate>Thu, 21 Jan 2010 12:41:10 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1641#comment-47352</guid>
		<description>Hi there,
After a lot of weird behaviours, i have tested the nexus 1000V in deep and my conclusion is that you should NEVER use cdp to create your sub-group in a critical environment.
The reason is that cdp can take at least 5s to advertise a link coming up and my tests show that you can loose about 7-8 pings when a link come up ine a vPC-HM config.
Use the manual or mac-pinning config. (cisco community thread https://www.myciscocommunity.com/thread/8023;jsessionid=BB9B9668B537623B904EB675C62B3523.node0)
By the way i try the same thing with vsphere standard vSwitches and the fact is that when you link a standard virtual switch to 2 cards on 2 physical switches (virtual port id LB), nothing is lost when failing-over, but if you choose reverting back to the link when it comes up, you loose 6-7 pings.
That was not the case with 3.5. 
After some tests, it does not happen with beacon probing activated, of course.
So i would recommand to activate beacon probing by default when configuring the type of LB!! (or do not choose to revert back to the original link)</description>
		<content:encoded><![CDATA[<p>Hi there,<br />
After a lot of weird behaviours, i have tested the nexus 1000V in deep and my conclusion is that you should NEVER use cdp to create your sub-group in a critical environment.<br />
The reason is that cdp can take at least 5s to advertise a link coming up and my tests show that you can loose about 7-8 pings when a link come up ine a vPC-HM config.<br />
Use the manual or mac-pinning config. (cisco community thread <a href="https://www.myciscocommunity.com/thread/8023;jsessionid=BB9B9668B537623B904EB675C62B3523.node0" rel="nofollow">https://www.myciscocommunity.com/thread/8023;jsessionid=BB9B9668B537623B904EB675C62B3523.node0</a>)<br />
By the way i try the same thing with vsphere standard vSwitches and the fact is that when you link a standard virtual switch to 2 cards on 2 physical switches (virtual port id LB), nothing is lost when failing-over, but if you choose reverting back to the link when it comes up, you loose 6-7 pings.<br />
That was not the case with 3.5.<br />
After some tests, it does not happen with beacon probing activated, of course.<br />
So i would recommand to activate beacon probing by default when configuring the type of LB!! (or do not choose to revert back to the original link)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Smith</title>
		<link>http://blog.scottlowe.org/2009/09/02/ta2384-deploying-the-nexus-1000v/comment-page-1/#comment-46150</link>
		<dc:creator>Chris Smith</dc:creator>
		<pubDate>Mon, 05 Oct 2009 14:36:23 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1641#comment-46150</guid>
		<description>After several weeks of testing with &quot;self-hosted&quot; VSMs (ie: VSMs running on top of VEMs), I&#039;ve pretty much given up on the idea.  The setup &quot;works&quot; - most of the time - but is far too fragile for production, in my opinion.  I found probably half the time during my failure and disaster testing (ie: rebooting random things, shutting down the VSMs and trying to bring them back up, etc), that the whole shebang would eventually, and inevitably, get twisted up so badly it was necessary to essentially start over from scratch - unlink all the vmnics from the Nexus 1000V, set them up on regular vSwitches, reconfigure the VSMs to use those vSwitches, then migrate everything back to the 1000V DVS again.  My feeling from that was that if you have a disaster that shuts down both VSMs, there&#039;s about a 20% chance you&#039;ll need to do some _serious_ recovery work to get them (and hence the entire cluster) running properly again.

For the moment, I&#039;ve moved the VSMs out onto a couple of independent, low-end ESXi hosts, which has at least improved things dramatically from a disaster recovery perspective (haven&#039;t been able to break it yet).  However, I can only hope the rumblings I&#039;ve heard about integrating the VSM functionality into the Nexus 5000 are true, and planned for the near future, because at the moment the 1000V doesn&#039;t really deliver what it promises, and that is in no small part because you effectively &quot;need&quot; separate server(s) for the VSM(s).


I&#039;ve also had trouble with vPC-HM in my UCS chassis, with the hardware and configuration described in this &quot;Best Practices&quot; document: http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white_paper_c11-558242.html (M71KR-Q CNAs).  In particular, whenever I link the second vmnic to the DVS, connectivity becomes extremely unpredictable and unreliable (sometiems it breaks immediatley, sometimes it takes an hour - but it always breaks eventually).  I think this might be something to do with the pinning within the UCS, and I&#039;m about to open up a TAC with Cisco to try and figure out what&#039;s wrong.

CS</description>
		<content:encoded><![CDATA[<p>After several weeks of testing with &#8220;self-hosted&#8221; VSMs (ie: VSMs running on top of VEMs), I&#8217;ve pretty much given up on the idea.  The setup &#8220;works&#8221; &#8211; most of the time &#8211; but is far too fragile for production, in my opinion.  I found probably half the time during my failure and disaster testing (ie: rebooting random things, shutting down the VSMs and trying to bring them back up, etc), that the whole shebang would eventually, and inevitably, get twisted up so badly it was necessary to essentially start over from scratch &#8211; unlink all the vmnics from the Nexus 1000V, set them up on regular vSwitches, reconfigure the VSMs to use those vSwitches, then migrate everything back to the 1000V DVS again.  My feeling from that was that if you have a disaster that shuts down both VSMs, there&#8217;s about a 20% chance you&#8217;ll need to do some _serious_ recovery work to get them (and hence the entire cluster) running properly again.</p>
<p>For the moment, I&#8217;ve moved the VSMs out onto a couple of independent, low-end ESXi hosts, which has at least improved things dramatically from a disaster recovery perspective (haven&#8217;t been able to break it yet).  However, I can only hope the rumblings I&#8217;ve heard about integrating the VSM functionality into the Nexus 5000 are true, and planned for the near future, because at the moment the 1000V doesn&#8217;t really deliver what it promises, and that is in no small part because you effectively &#8220;need&#8221; separate server(s) for the VSM(s).</p>
<p>I&#8217;ve also had trouble with vPC-HM in my UCS chassis, with the hardware and configuration described in this &#8220;Best Practices&#8221; document: <a href="http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white_paper_c11-558242.html" rel="nofollow">http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white_paper_c11-558242.html</a> (M71KR-Q CNAs).  In particular, whenever I link the second vmnic to the DVS, connectivity becomes extremely unpredictable and unreliable (sometiems it breaks immediatley, sometimes it takes an hour &#8211; but it always breaks eventually).  I think this might be something to do with the pinning within the UCS, and I&#8217;m about to open up a TAC with Cisco to try and figure out what&#8217;s wrong.</p>
<p>CS</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ProInteg</title>
		<link>http://blog.scottlowe.org/2009/09/02/ta2384-deploying-the-nexus-1000v/comment-page-1/#comment-46098</link>
		<dc:creator>ProInteg</dc:creator>
		<pubDate>Thu, 01 Oct 2009 16:32:59 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1641#comment-46098</guid>
		<description>Will the Cisco 1000V allow me to use multiple 1Gbps NIC&#039;s to create more bandwidth to my iSCSI Target?

If not then I guess I&#039;m stuck with moving to 10GbE.</description>
		<content:encoded><![CDATA[<p>Will the Cisco 1000V allow me to use multiple 1Gbps NIC&#8217;s to create more bandwidth to my iSCSI Target?</p>
<p>If not then I guess I&#8217;m stuck with moving to 10GbE.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jason</title>
		<link>http://blog.scottlowe.org/2009/09/02/ta2384-deploying-the-nexus-1000v/comment-page-1/#comment-46054</link>
		<dc:creator>jason</dc:creator>
		<pubDate>Mon, 28 Sep 2009 19:00:24 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1641#comment-46054</guid>
		<description>So.. can anybody tell me if there is a technical design that drives the use of 1000V over the Vsphere VDS or is it strictly to give the network folkes visibility into the virtual networking layer?</description>
		<content:encoded><![CDATA[<p>So.. can anybody tell me if there is a technical design that drives the use of 1000V over the Vsphere VDS or is it strictly to give the network folkes visibility into the virtual networking layer?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Omar Sultan</title>
		<link>http://blog.scottlowe.org/2009/09/02/ta2384-deploying-the-nexus-1000v/comment-page-1/#comment-45788</link>
		<dc:creator>Omar Sultan</dc:creator>
		<pubDate>Tue, 08 Sep 2009 05:25:05 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1641#comment-45788</guid>
		<description>Scott/Chris:

Just checked with the product team to make sure, but you can currently put a VEM and VSM on the same host.  What we don&#039;t currently recommend is VMotioning your VSM.  An upcoming update will offer more robust support for VSM VMotion.

Omar
Cisco</description>
		<content:encoded><![CDATA[<p>Scott/Chris:</p>
<p>Just checked with the product team to make sure, but you can currently put a VEM and VSM on the same host.  What we don&#8217;t currently recommend is VMotioning your VSM.  An upcoming update will offer more robust support for VSM VMotion.</p>
<p>Omar<br />
Cisco</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Smith</title>
		<link>http://blog.scottlowe.org/2009/09/02/ta2384-deploying-the-nexus-1000v/comment-page-1/#comment-45777</link>
		<dc:creator>Chris Smith</dc:creator>
		<pubDate>Sat, 05 Sep 2009 11:08:01 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1641#comment-45777</guid>
		<description>Scott:
That requirement was essentially from the horse&#039;s mouth - the Cisco-recommended people who have just finished installing our new Nexus(incl. 1000v)+UCS+VMWare infrastructure.

I haven&#039;t actually had time to make it to the 1000v docs myself, so if you have information otherwise, I&#039;d love to know - since we&#039;ve currently got an 8-core/48GB RAM blade that doesn&#039;t do anything more than vCenter and the 1000v VSM.</description>
		<content:encoded><![CDATA[<p>Scott:<br />
That requirement was essentially from the horse&#8217;s mouth &#8211; the Cisco-recommended people who have just finished installing our new Nexus(incl. 1000v)+UCS+VMWare infrastructure.</p>
<p>I haven&#8217;t actually had time to make it to the 1000v docs myself, so if you have information otherwise, I&#8217;d love to know &#8211; since we&#8217;ve currently got an 8-core/48GB RAM blade that doesn&#8217;t do anything more than vCenter and the 1000v VSM.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: slowe</title>
		<link>http://blog.scottlowe.org/2009/09/02/ta2384-deploying-the-nexus-1000v/comment-page-1/#comment-45774</link>
		<dc:creator>slowe</dc:creator>
		<pubDate>Sat, 05 Sep 2009 05:09:21 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1641#comment-45774</guid>
		<description>Steve,

Please be sure to provide full vendor disclosure. Since your message originated from an IP address block that belongs to HP, I can only assume that you work for HP. If that is not the case, please let me know.</description>
		<content:encoded><![CDATA[<p>Steve,</p>
<p>Please be sure to provide full vendor disclosure. Since your message originated from an IP address block that belongs to HP, I can only assume that you work for HP. If that is not the case, please let me know.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: slowe</title>
		<link>http://blog.scottlowe.org/2009/09/02/ta2384-deploying-the-nexus-1000v/comment-page-1/#comment-45772</link>
		<dc:creator>slowe</dc:creator>
		<pubDate>Sat, 05 Sep 2009 05:06:03 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1641#comment-45772</guid>
		<description>Chris Smith,

I think you&#039;re incorrect about not being able to run the VSM on a host with the VEM--I&#039;ve seen a couple of references to the necessary configuration although I&#039;ve not yet done it myself.</description>
		<content:encoded><![CDATA[<p>Chris Smith,</p>
<p>I think you&#8217;re incorrect about not being able to run the VSM on a host with the VEM&#8211;I&#8217;ve seen a couple of references to the necessary configuration although I&#8217;ve not yet done it myself.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Larry Passo</title>
		<link>http://blog.scottlowe.org/2009/09/02/ta2384-deploying-the-nexus-1000v/comment-page-1/#comment-45769</link>
		<dc:creator>Larry Passo</dc:creator>
		<pubDate>Fri, 04 Sep 2009 16:04:33 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1641#comment-45769</guid>
		<description>I usually refer to Layers 8-11 (Financial, Legal, Political, Religious). Since they all cause different problems.</description>
		<content:encoded><![CDATA[<p>I usually refer to Layers 8-11 (Financial, Legal, Political, Religious). Since they all cause different problems.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve Nicholson</title>
		<link>http://blog.scottlowe.org/2009/09/02/ta2384-deploying-the-nexus-1000v/comment-page-1/#comment-45768</link>
		<dc:creator>Steve Nicholson</dc:creator>
		<pubDate>Fri, 04 Sep 2009 13:13:55 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1641#comment-45768</guid>
		<description>Here is a great interview that was released this week.  The article reviews the emergence of VEPA as a base standard for exposing VM traffic beyond the NIC and it specifically points out the proprietary nature of Cisco’s plans with VNtag.  I found this article extremely interesting.  Any of your customers contemplating Cisco UCS (and VNTag) will definitely benefit from reading this article.  It also does a great job outlining the need for this technology.

http://www.eweekeurope.co.uk/interview/hp-claims-victory-in-virtualisation-standards--1734?page=1

Interesting sections are captured below:

&quot;Cisco has a proprietary packet format, that modifies the Ethernet frame to integrate UCS servers with switches,&quot; said Congdon. &quot;That was more intrusive than the Industry wanted to see. Modifying the frame is usually a bad thing, because it can make everyone&#039;s silicon obsolete, and customers have to buy new equipment, to address an incremental problem. If we can avoid that, it is a good thing.&quot;

Hardware NICs effectively now include an Ethernet switch, and Congdon wants to see a &quot;small evolutionary step&quot; that exposes the network traffic to the outside world. Cisco wanted a new tag format, new addresses, and new hardware structures, he said.

The end result wasn&#039;t a battle to the death (unlike all too many IEEE standards spats) says Congdon: &quot;Cisco and HP started out at odds with each other, but finally came to a compromise.&quot;

That compromise is for VEPA to form a base standard, while Cisco addresses extensions that it thinks are necessary.</description>
		<content:encoded><![CDATA[<p>Here is a great interview that was released this week.  The article reviews the emergence of VEPA as a base standard for exposing VM traffic beyond the NIC and it specifically points out the proprietary nature of Cisco’s plans with VNtag.  I found this article extremely interesting.  Any of your customers contemplating Cisco UCS (and VNTag) will definitely benefit from reading this article.  It also does a great job outlining the need for this technology.</p>
<p><a href="http://www.eweekeurope.co.uk/interview/hp-claims-victory-in-virtualisation-standards--1734?page=1" rel="nofollow">http://www.eweekeurope.co.uk/interview/hp-claims-victory-in-virtualisation-standards&#8211;1734?page=1</a></p>
<p>Interesting sections are captured below:</p>
<p>&#8220;Cisco has a proprietary packet format, that modifies the Ethernet frame to integrate UCS servers with switches,&#8221; said Congdon. &#8220;That was more intrusive than the Industry wanted to see. Modifying the frame is usually a bad thing, because it can make everyone&#8217;s silicon obsolete, and customers have to buy new equipment, to address an incremental problem. If we can avoid that, it is a good thing.&#8221;</p>
<p>Hardware NICs effectively now include an Ethernet switch, and Congdon wants to see a &#8220;small evolutionary step&#8221; that exposes the network traffic to the outside world. Cisco wanted a new tag format, new addresses, and new hardware structures, he said.</p>
<p>The end result wasn&#8217;t a battle to the death (unlike all too many IEEE standards spats) says Congdon: &#8220;Cisco and HP started out at odds with each other, but finally came to a compromise.&#8221;</p>
<p>That compromise is for VEPA to form a base standard, while Cisco addresses extensions that it thinks are necessary.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

