<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>My EtherealMind&#187; Blessay</title>
	<atom:link href="http://etherealmind.com/category/blessay/feed/" rel="self" type="application/rss+xml" />
	<link>http://etherealmind.com</link>
	<description>Network design, architecture, thinking, working. Tech.</description>
	<lastBuildDate>Sun, 20 May 2012 09:15:21 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
		<item>
		<title>How TRILL (and SPB) Can Reduce STP Risk and Mitigate Impact</title>
		<link>http://etherealmind.com/trill-spb-spanning-tree-stp-risk-impact-design-reduce-domain-size/</link>
		<comments>http://etherealmind.com/trill-spb-spanning-tree-stp-risk-impact-design-reduce-domain-size/#comments</comments>
		<pubDate>Sun, 13 May 2012 18:08:32 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[campus]]></category>
		<category><![CDATA[data]]></category>
		<category><![CDATA[data centre]]></category>
		<category><![CDATA[datacenter]]></category>
		<category><![CDATA[lan]]></category>
		<category><![CDATA[spanning-tree]]></category>
		<category><![CDATA[spb]]></category>
		<category><![CDATA[stp]]></category>
		<category><![CDATA[trill]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=6610</guid>
		<description><![CDATA[In this post, I'm looking at network designs with ECMP cores using TRILL or SPB, I'm realising that STP is equally improved in terms of risk and performance by reducing the STP domain size which leads to better stability, reduced risk and impact mitigation]]></description>
		<wfw:commentRss>http://etherealmind.com/trill-spb-spanning-tree-stp-risk-impact-design-reduce-domain-size/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>OpenFlow Might Lower CapEx While SDN Will Increase OpEx</title>
		<link>http://etherealmind.com/openflow-might-lower-capex-while-sdn-will-increase-opex/</link>
		<comments>http://etherealmind.com/openflow-might-lower-capex-while-sdn-will-increase-opex/#comments</comments>
		<pubDate>Fri, 13 Apr 2012 19:35:15 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[OpenFlow]]></category>
		<category><![CDATA[Opinion]]></category>
		<category><![CDATA[openflow]]></category>
		<category><![CDATA[SDN]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=6467</guid>
		<description><![CDATA[A lot of people have talked extensively about OpenFlow making significant changes to the networking business. In particular, many writers have focussed on the possibility that OpenFlow enables a choice of using low cost network equipment instead of the expensive networking equipment that we use today.

Well, that's highly unlikely.]]></description>
		<wfw:commentRss>http://etherealmind.com/openflow-might-lower-capex-while-sdn-will-increase-opex/feed/</wfw:commentRss>
		<slash:comments>19</slash:comments>
		</item>
		<item>
		<title>ConsultoBabble Deployment Analysis Report for Cloud Deployment of EtherealMind.Com</title>
		<link>http://etherealmind.com/consultobabble-deployment-report-for-cloud-deployment-of-etherealmind-com/</link>
		<comments>http://etherealmind.com/consultobabble-deployment-report-for-cloud-deployment-of-etherealmind-com/#comments</comments>
		<pubDate>Thu, 05 Apr 2012 22:14:00 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[cloud]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=6425</guid>
		<description><![CDATA[I don&#8217;t use a Cloud for any of my blogs or email services. I&#8217;ve looked at three different cloud providers including Amazon, Rackspace and others. I guessed that they all would work,  more or less. Except they cost between four to ten times the solution from a managed service provider. Here is my exit report for the fictitious consulting engagement with myself.]]></description>
		<wfw:commentRss>http://etherealmind.com/consultobabble-deployment-report-for-cloud-deployment-of-etherealmind-com/feed/</wfw:commentRss>
		<slash:comments>11</slash:comments>
		</item>
		<item>
		<title>My Knowledge Management Process With PDF Files &#8211; Part 2</title>
		<link>http://etherealmind.com/knowledge-management-pdf-files-collecting-organising-part-2/</link>
		<comments>http://etherealmind.com/knowledge-management-pdf-files-collecting-organising-part-2/#comments</comments>
		<pubDate>Tue, 13 Mar 2012 18:00:09 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[OSX]]></category>
		<category><![CDATA[osx]]></category>
		<category><![CDATA[study]]></category>
		<category><![CDATA[tools]]></category>
		<category><![CDATA[work life]]></category>
		<category><![CDATA[worklife]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=6293</guid>
		<description><![CDATA[I've been asked a few times about how I organise my PDF files and keep track of documents. This post looks at my workflow for capturing, storing, tagging and organising my Knowledge Management system. This is Part 2]]></description>
		<wfw:commentRss>http://etherealmind.com/knowledge-management-pdf-files-collecting-organising-part-2/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>My Knowledge Management Process With PDF Files &#8211; Part 1</title>
		<link>http://etherealmind.com/knowledge-management-pdf-files-collecting-organising-part-1/</link>
		<comments>http://etherealmind.com/knowledge-management-pdf-files-collecting-organising-part-1/#comments</comments>
		<pubDate>Mon, 12 Mar 2012 17:35:51 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[OSX]]></category>
		<category><![CDATA[osx]]></category>
		<category><![CDATA[work life]]></category>
		<category><![CDATA[worklife]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=6291</guid>
		<description><![CDATA[A few times I've mentioned about how I manage collections of PDF documents, Text files and the accreted detritus of a Network Engineer. Since a number of people have asked me to talk in more detail about how I organise this and what methods I use, here is some rough description of how I perform knowledge management.]]></description>
		<wfw:commentRss>http://etherealmind.com/knowledge-management-pdf-files-collecting-organising-part-1/feed/</wfw:commentRss>
		<slash:comments>9</slash:comments>
		</item>
		<item>
		<title>My Way of Selecting a Cisco IOS Release With a Bug Scrub</title>
		<link>http://etherealmind.com/selecting-cisco-ios-release-choice-which-how-choose-decide-bug-scrub/</link>
		<comments>http://etherealmind.com/selecting-cisco-ios-release-choice-which-how-choose-decide-bug-scrub/#comments</comments>
		<pubDate>Thu, 08 Mar 2012 18:39:05 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Cisco]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[IOS]]></category>
		<category><![CDATA[Operation]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=6249</guid>
		<description><![CDATA[Cisco is known for shipping products early to deliver new features quickly. But this leads to a reputation for buggy code which has customers report bugs (and Cisco fixing them). This means that you should never buy a newly released Cisco product unless you are willing to take this risk. This post looks a my process for analysing this risk and then selecting an IOS version by performing a bug scrub. In this case, I've been asked whether the Cisco C3750-X switches are ready for live deployment.]]></description>
		<wfw:commentRss>http://etherealmind.com/selecting-cisco-ios-release-choice-which-how-choose-decide-bug-scrub/feed/</wfw:commentRss>
		<slash:comments>14</slash:comments>
		</item>
		<item>
		<title>Predicting What Will Be Big in 2012 &#8211; Part 1</title>
		<link>http://etherealmind.com/etherealmind-prediction-2012-big-part1/</link>
		<comments>http://etherealmind.com/etherealmind-prediction-2012-big-part1/#comments</comments>
		<pubDate>Sun, 26 Feb 2012 21:59:00 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Opinion]]></category>
		<category><![CDATA[predictions]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=6168</guid>
		<description><![CDATA[Following from my predictions on what WILL NOT be big in 2012, finally, my predictions for 2012. Not early, but hey, the future never arrives on time anyway.]]></description>
		<wfw:commentRss>http://etherealmind.com/etherealmind-prediction-2012-big-part1/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Tech Notes: Juniper QFabric &#8211; A Perspective on Scaling Up</title>
		<link>http://etherealmind.com/tech-notes-juniper-qfabric-scaling-up-review-how-architecture/</link>
		<comments>http://etherealmind.com/tech-notes-juniper-qfabric-scaling-up-review-how-architecture/#comments</comments>
		<pubDate>Tue, 14 Feb 2012 19:30:40 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[Tech Notes]]></category>
		<category><![CDATA[ethernet]]></category>
		<category><![CDATA[fabric]]></category>
		<category><![CDATA[juniper]]></category>
		<category><![CDATA[network design]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=6136</guid>
		<description><![CDATA[Juniper QFabric is a new approach to Ethernet Switch Fabrics. When it was announced last year,it was noted  that the underlying physical design is a completely different approach to building Switch Fabrics. Here I'm taking a loosely research based approach to understand how Juniper QFabric is different from all other approaches to the problem, and also a look at some of the challenges ahead.]]></description>
		<wfw:commentRss>http://etherealmind.com/tech-notes-juniper-qfabric-scaling-up-review-how-architecture/feed/</wfw:commentRss>
		<slash:comments>11</slash:comments>
		</item>
		<item>
		<title>Using Underscores, Hyphens or CamelCase in Naming Standards</title>
		<link>http://etherealmind.com/using-underscores-hyphens-or-camelcase-in-naming-standards/</link>
		<comments>http://etherealmind.com/using-underscores-hyphens-or-camelcase-in-naming-standards/#comments</comments>
		<pubDate>Fri, 27 Jan 2012 17:05:32 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Operation]]></category>
		<category><![CDATA[Opinion]]></category>
		<category><![CDATA[naming]]></category>
		<category><![CDATA[network design]]></category>
		<category><![CDATA[standards]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=6009</guid>
		<description><![CDATA[I&#8217;ve been considering a small but vital problem in naming conventions in Networking. Namely, the use of underscores and hyphens in object names and devices. It&#8217;s a hot topic for argument when the time comes for corporate standards (and when Network Engineers have beverages in  a public house). Now, I figure that there are three possible grammar options for making names - hyphens, underscore and CamelCase.]]></description>
		<wfw:commentRss>http://etherealmind.com/using-underscores-hyphens-or-camelcase-in-naming-standards/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>Scaling Virtual Appliances With Embrane</title>
		<link>http://etherealmind.com/scaling-virtual-appliances-embrane/</link>
		<comments>http://etherealmind.com/scaling-virtual-appliances-embrane/#comments</comments>
		<pubDate>Mon, 12 Dec 2011 17:07:43 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[appliances]]></category>
		<category><![CDATA[network design]]></category>
		<category><![CDATA[virtualization]]></category>
		<category><![CDATA[vmware]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=5937</guid>
		<description><![CDATA[Embrane uses concepts of IP Flows to scale virtual appliances. Embrane does this by managing IP flows and then directing to other appliances, in effect creating what I would call a two tier load balancing.]]></description>
		<wfw:commentRss>http://etherealmind.com/scaling-virtual-appliances-embrane/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Cisco, Culture of Buggy Code and the Failure of the TAC</title>
		<link>http://etherealmind.com/cisco-culture-of-buggy-code-and-the-failure-of-the-tac/</link>
		<comments>http://etherealmind.com/cisco-culture-of-buggy-code-and-the-failure-of-the-tac/#comments</comments>
		<pubDate>Wed, 16 Nov 2011 13:06:14 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Cisco]]></category>
		<category><![CDATA[Rant]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=5890</guid>
		<description><![CDATA[In recent months I seem to have hit a lot of bugs in Cisco software. Across the board on the main software releases of IOS, NX-OS or IOS-SX I seem to be hitting a wide range of bugs, and some of them are pretty stupid. And I've realised that, in recent years, it has become so commonplace, so <strong>accepted</strong> that we actually plan our projects with time to test, locate and check for bugs. And that’s become an expensive and time-consuming problem.

Why do we put up with this ?]]></description>
		<wfw:commentRss>http://etherealmind.com/cisco-culture-of-buggy-code-and-the-failure-of-the-tac/feed/</wfw:commentRss>
		<slash:comments>57</slash:comments>
		</item>
		<item>
		<title>Cisco Nexus 5000 / 2000 Pricing Bundles and Fabric Extension Transceivers (FETs) vs 10GbaseSR SFPs.</title>
		<link>http://etherealmind.com/cisco-nexus-5000-2000-fet-fabric-extension-transceiver-sfp-10gbasesr-comparison/</link>
		<comments>http://etherealmind.com/cisco-nexus-5000-2000-fet-fabric-extension-transceiver-sfp-10gbasesr-comparison/#comments</comments>
		<pubDate>Thu, 03 Nov 2011 20:18:26 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Cisco]]></category>
		<category><![CDATA[Design]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=5864</guid>
		<description><![CDATA[Recently I noticed that Cisco is selling "Fabric Ethernet Transceivers" for the Nexus switch family. Some research shows that these are replacements for 10GBaseSX SFP modules. Importantly, it's cheaper to install new cabling than to buy 10BaseSR SFP+ modules.]]></description>
		<wfw:commentRss>http://etherealmind.com/cisco-nexus-5000-2000-fet-fabric-extension-transceiver-sfp-10gbasesr-comparison/feed/</wfw:commentRss>
		<slash:comments>16</slash:comments>
		</item>
		<item>
		<title>Top Five Things About VXLAN &#8211; And Why It&#8217;s Full of Fail</title>
		<link>http://etherealmind.com/top-5-things-vxlan-fail/</link>
		<comments>http://etherealmind.com/top-5-things-vxlan-fail/#comments</comments>
		<pubDate>Fri, 16 Sep 2011 16:31:59 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[vmware]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=5820</guid>
		<description><![CDATA[It's obvious #VXLAN was conjured up by a cloudtard. Simple minds devise simple solutions without seeing the complex problems they missed. Here are five things that VXLAN tells us about the networking industry. ]]></description>
		<wfw:commentRss>http://etherealmind.com/top-5-things-vxlan-fail/feed/</wfw:commentRss>
		<slash:comments>9</slash:comments>
		</item>
		<item>
		<title>Switch Fabrics: Input and Output Queues and Buffers for a Switch Fabric</title>
		<link>http://etherealmind.com/switch-fabric-input-output-buffers-queues/</link>
		<comments>http://etherealmind.com/switch-fabric-input-output-buffers-queues/#comments</comments>
		<pubDate>Tue, 06 Sep 2011 19:14:45 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=5807</guid>
		<description><![CDATA[Now that this has established that a Switch Fabric has buffers, I want to flip back into something practical about this application. Lets use an example of four servers connecting to single switch and sharing an Ethernet Storage Array. The array might be using iSCSI or FCoE to delivery SCSI applications to the Servers. The nature of storage traffic is such that it has transient spikes in traffic that must maintain low latency and should not be dropped.]]></description>
		<wfw:commentRss>http://etherealmind.com/switch-fabric-input-output-buffers-queues/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Soft Switching Fails at Scale</title>
		<link>http://etherealmind.com/soft-switching-fails-at-scale/</link>
		<comments>http://etherealmind.com/soft-switching-fails-at-scale/#comments</comments>
		<pubDate>Sat, 09 Jul 2011 18:12:05 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[hypervisor]]></category>
		<category><![CDATA[vmware]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=5723</guid>
		<description><![CDATA[There is a significant camp of software developers who are developing software switching solutions for hypervisors. Which is nice, I guess. The use of software switching in the hypervisor has some good points but, in my view they are heavily outweighed by the bad. I present the use case, and show that software]]></description>
		<wfw:commentRss>http://etherealmind.com/soft-switching-fails-at-scale/feed/</wfw:commentRss>
		<slash:comments>29</slash:comments>
		</item>
		<item>
		<title>What Is the Definition of a Switch Fabric ?</title>
		<link>http://etherealmind.com/what-is-the-definition-of-switch-fabric/</link>
		<comments>http://etherealmind.com/what-is-the-definition-of-switch-fabric/#comments</comments>
		<pubDate>Wed, 29 Jun 2011 23:19:04 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[trill]]></category>
		<category><![CDATA[worklife]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=5711</guid>
		<description><![CDATA[<p>The marketing people in IT tend to be overwhelmed by complexity and deep technology.  For many liberal arts graduates,  they take the drowning option and latch onto certain terms and then grossly abuse it. The most egregious abuse today is "cloud" but "fabric" comes a close second. In this series of posts I want to look at what <strong>is</strong> a <em>FABRIC</em> and provide a canonical look at what it does and how it works for us.</p>]]></description>
		<wfw:commentRss>http://etherealmind.com/what-is-the-definition-of-switch-fabric/feed/</wfw:commentRss>
		<slash:comments>30</slash:comments>
		</item>
		<item>
		<title>Cisco C6500 Service Modules &#8211; Not My Choice, Now.</title>
		<link>http://etherealmind.com/cisco-c6500-service-modules-not-my-choice-now/</link>
		<comments>http://etherealmind.com/cisco-c6500-service-modules-not-my-choice-now/#comments</comments>
		<pubDate>Sun, 19 Jun 2011 20:38:51 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Cisco]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[network design]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=5693</guid>
		<description><![CDATA[These all suggest that the time for planning and designing Service Modules is over. There are no suggestions that service modules for the Nexus 7000 will be developed that I can see. I can prognosticate that it would slow down the development of the core switch / route / performance functions, and it will be some years before those core capabilities is complete enough that service modules would become viable product development tasks &#8212; they might be in development, but not much chance of going into production. [^1]

Do I sound bitter about Service Modules ? A bit. I've had a number of hard to solve problems that lasted months before code fixes arrived. I've been fan of the NAM but the price is now far removed from it's practical value. USD$30K List is way over priced for its capabilities and even with a 30% discount, you can buy a lot of network management systems that deliver much better functions and features for that price.]]></description>
		<wfw:commentRss>http://etherealmind.com/cisco-c6500-service-modules-not-my-choice-now/feed/</wfw:commentRss>
		<slash:comments>10</slash:comments>
		</item>
		<item>
		<title>VMware: Let&#8217;s Get Logical &#8211; The Case for OpenFlow Network Virtualization (and Their Failed Network Plans)</title>
		<link>http://etherealmind.com/vmware-openflow-failed-networking-plans/</link>
		<comments>http://etherealmind.com/vmware-openflow-failed-networking-plans/#comments</comments>
		<pubDate>Thu, 02 Jun 2011 18:35:23 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[industry]]></category>
		<category><![CDATA[openflow]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=5638</guid>
		<description><![CDATA[VMware has made several strategic moves to implement dynamic networking - vSwitch, vDS, Nexus 1000 (in partnership with Cisco), vCloud External Networks (using MAC in MAC of all things) and have basically failed to deliver  overlay technology without implementing technology in the network itself. Equally, VMware hasn't been willing to engage with the networking vendors to develop technologies that would solve this problem - VNtag / VEPA/ VEP combined with TRILL / SPBB, instead letting them argue amongst themselves. VMware attempt with vCloud networking using MACinMAC encapsulation seems to have failed and stalled and is getting another attempt using MACinIP. VMware/Xen/HyperV are all desperate to have a more dynamic network that can be controlled from their software and this might be where OpenFlow gets a big lift - as a configuration engine.]]></description>
		<wfw:commentRss>http://etherealmind.com/vmware-openflow-failed-networking-plans/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Review: HP and Optical Backplanes</title>
		<link>http://etherealmind.com/hp-optical-backplanes/</link>
		<comments>http://etherealmind.com/hp-optical-backplanes/#comments</comments>
		<pubDate>Sun, 15 May 2011 13:05:19 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Opinion]]></category>
		<category><![CDATA[Reviews]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[hp]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=5609</guid>
		<description><![CDATA[<p>There were a lot of cool things at InterOp, but not much that was new from the big vendors. For example, Cisco didn't announce anything, probably waiting announce at Cisco Live in July where they can control the press and message much more tightly. However, HP announced the A10500 switch (<a rel="nofollow" href="etherealmind.com/hp-a10500-flexicampus-action-pics/" target="_blank">action pictures </a>) which is a new campus switch and <a href="http://www.gnodal.com/" target="_blank">Gnodal</a> arrived with new products.</p>
<p>However in the centre of the HP stand there was something very cool - a prototype E8212 ProCurve switch with a <strong>fully optical backplane.</strong> <img style="display: block; margin-left: auto; margin-right: auto;" src="http://etherealmind.com/wp-content/uploads/2011/05/hp-procurve-optical-backplane-1.jpg" border="0" alt="Hp procurve optical backplane 1" width="610" height="455" /></p>

]]></description>
		<wfw:commentRss>http://etherealmind.com/hp-optical-backplanes/feed/</wfw:commentRss>
		<slash:comments>13</slash:comments>
		</item>
		<item>
		<title>Complex Systems Have Complex Failures. That&#8217;s Cloud Computing.</title>
		<link>http://etherealmind.com/complex-systems-complex-failures-cloud-computing/</link>
		<comments>http://etherealmind.com/complex-systems-complex-failures-cloud-computing/#comments</comments>
		<pubDate>Tue, 26 Apr 2011 17:00:48 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[Opinion]]></category>
		<category><![CDATA[cloud]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=5527</guid>
		<description><![CDATA[Exposing cloud failures The result of the Amazon EC2 failure this week has exposed a number of technology strategies in cloud infrastructure as being less than perfect. Complex systems have complex failures The most vexing problem of Cloud Computing is that these systems are complex, and the more complex system the more complex the failure. [...]]]></description>
		<wfw:commentRss>http://etherealmind.com/complex-systems-complex-failures-cloud-computing/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Fate Sharing, Failure Domains and Why VTP Is Awesome</title>
		<link>http://etherealmind.com/vtp-design-fate-sharing-failure-domains/</link>
		<comments>http://etherealmind.com/vtp-design-fate-sharing-failure-domains/#comments</comments>
		<pubDate>Wed, 20 Apr 2011 15:00:10 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[Operation]]></category>
		<category><![CDATA[Cisco]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=5494</guid>
		<description><![CDATA[A lot of people regard Virtual Trunking Protocol(VTP) as nothing but trouble. Indeed, it's hard to find many people who will implement it on their network. I find this baffling - it's a great tool that dramatically reduces time, errors, and troubleshooting is something that we should all embrace and use wherever we can. Naturally, with great power comes great evil. So, lets be clever instead.]]></description>
		<wfw:commentRss>http://etherealmind.com/vtp-design-fate-sharing-failure-domains/feed/</wfw:commentRss>
		<slash:comments>34</slash:comments>
		</item>
		<item>
		<title>Musing: How Many 10Gigabit Ethernet Ports Do You Really Need ?</title>
		<link>http://etherealmind.com/how-many-10-gbe-ports-do-you-need/</link>
		<comments>http://etherealmind.com/how-many-10-gbe-ports-do-you-need/#comments</comments>
		<pubDate>Mon, 18 Apr 2011 22:11:53 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[Musing]]></category>
		<category><![CDATA[VMware]]></category>
		<category><![CDATA[10GbE]]></category>
		<category><![CDATA[data centre]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=5484</guid>
		<description><![CDATA[I was doing a Data Centre Design recently and did some numbers around the numbers of 10 Gigabit Ethernet ports that need to be deployed. I got a bit of a realisation shock.]]></description>
		<wfw:commentRss>http://etherealmind.com/how-many-10-gbe-ports-do-you-need/feed/</wfw:commentRss>
		<slash:comments>9</slash:comments>
		</item>
		<item>
		<title>Low Level Design &#8211; Think About the Next Step</title>
		<link>http://etherealmind.com/low-level-design-think-about-the-next-step/</link>
		<comments>http://etherealmind.com/low-level-design-think-about-the-next-step/#comments</comments>
		<pubDate>Fri, 18 Mar 2011 21:13:58 +0000</pubDate>
		<dc:creator>John McManus</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[CCIE]]></category>
		<category><![CDATA[network design]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=5192</guid>
		<description><![CDATA[A while back Greg wrote a great article about the &#8220;Rules of Design Documentation&#8221; http://etherealmind.com/rules-design-documentation-etherealmind/ these are really valuable rules when it comes to writing a design document and in my opinion is particularly relevant to a Low Level Design AKA Detailed Design Document. &#160; Ask yourself Before you can apply these rules of design you must [...]]]></description>
		<wfw:commentRss>http://etherealmind.com/low-level-design-think-about-the-next-step/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Checkpoint/Nokia Firewall Clustering. Uh Oh.</title>
		<link>http://etherealmind.com/checkpoint-nokia-firewall-cluster-xl/</link>
		<comments>http://etherealmind.com/checkpoint-nokia-firewall-cluster-xl/#comments</comments>
		<pubDate>Thu, 17 Mar 2011 17:00:37 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[Security]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=5182</guid>
		<description><![CDATA[I've been reviewing a network that has some CheckPoint firewalls that have been unstable, and while this isn't surprising (in my experience, it's common enough for Checkpoint firewalls to be unstable for some reason or the other), this time I've been faced with Checkpoint Clustering. A few years back I tried to make this work, but gave up when CheckPoint couldn't make it work either. 

A few years later, I find someone brave enough to attempt it. This time it's different, I'm the one who has to justify why it's a bad idea. Now that the manuals are not secret anymore I think I've found out why.]]></description>
		<wfw:commentRss>http://etherealmind.com/checkpoint-nokia-firewall-cluster-xl/feed/</wfw:commentRss>
		<slash:comments>49</slash:comments>
		</item>
		<item>
		<title>Blessay: Comparing Merchant and Custom Silicon</title>
		<link>http://etherealmind.com/analysis-merchant-custom-silicon/</link>
		<comments>http://etherealmind.com/analysis-merchant-custom-silicon/#comments</comments>
		<pubDate>Fri, 11 Mar 2011 12:51:52 +0000</pubDate>
		<dc:creator>Greg Ferro</dc:creator>
				<category><![CDATA[Blessay]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Cisco]]></category>
		<category><![CDATA[industry]]></category>

		<guid isPermaLink="false">http://etherealmind.com/?p=5160</guid>
		<description><![CDATA[Merchant Silicon is an marketing term used to describe the use of "off the shelf" chip components to create a networking product and commonly used by company that design their own silicon chips when explaining that their process is better and more efficient.

The networking industry has two types of silicon: ìcustom or in houseî or ìmerchant or off the shelfî. The 'in house silicon' argument goes something like this :

We have our specialist engineers who can custom design an ASIC and supporting chips that are completely focussed on the features needed to deliver Product X. As a result, our designs are purposefully built to be faster, better etc. Our prices are more expensive because our products are faster and more focussed and because our costs are higher.

The 'merchant silicon' argument goes something like this:

The levels of expertise required to design and build a silicon chip is very high. It requires specific skills, tools, and high levels of expertise. If your core business is producing a networking device, then having your own silicon development is not core business. By relying on companies who specialise in silicon design and manufacture, we can focus on software and integration to deliver new and better features at a cheaper price.

.......]]></description>
		<wfw:commentRss>http://etherealmind.com/analysis-merchant-custom-silicon/feed/</wfw:commentRss>
		<slash:comments>20</slash:comments>
		</item>
	</channel>
</rss>

<!-- Served from: etherealmind.com @ 2012-05-21 13:10:57 by W3 Total Cache -->
