March 30, 2008

A quick word from the field...

Brad Hedlund, a Cisco Systems Engineer out of Illinois and author of a very nice blog that strives to help network engineers worldwide wrote this nice write-up on the Nexus 7000.

I like how Brad brings forward some of the key differentiators that will be sustainable for a very long time. Brad- have you had any feedback on the usability feature set on the Nexus?

Posted by Douglas Gourlay at 09:05 PM Permalink | Comments (1) | TrackBacks (0)

March 27, 2008

FCoE, FibreChannel, Ethernet, Eagles, and Parrots

I had a discussion with some folks today who told me that customers wondered what Cisco's position on FibreChannel was. One of our FC competitors was telling them that we are 'getting rid of' the Cisco MDS 9500 Storage Director in favor of the Nexus 7000, etc. I am reminded again of another of my favorite Winston Churchill quotes (yes, am a fan and have a book of them)

"When the eagles are silent, the parrots begin to jabber"

(Sir WInston Churchill)

I guess it's time to 'chirp up' and silence the jabber.

FibreChannel is here to stay. I joked a little in my last entry about some of the things that existed in 1998. I can guarantee 10 years from now FibreChannel will still exist, and still be deployed actively in our customers networks. It's a good protocol, it works, it works well, and it will continue to solve some network problems that even by that time I do not think Ethernet and FCoE will have evolved to deliver.

Additionally, newsflash for some companies here, customers that I have talked to really don't like changing their network equipment out every 2-3 years, most like equipment that 'has legs'. (longer ones than a parrot does btw)

FCoE will happen. Of this I am certain. But I also believe that the pragmatic adoption path of FCoE will be first on the host, then over a period of time switch to switch, and then eventually to the target. Why?

1) Hosts get churned faster than Targets
2) By running FCoE to the hosts more workload processing capability gets connected to the SAN. This means there is more data to protect and safeguard. This is GREAT for storage. The entire Storage market is predicated on 15-20% of the hosts connecting to the SAN. Fast-forward 3-5 years and imagine a world with 100% of the servers connected to the SAN. Pretty powerful!
3) Existing SAN services that Cisco has integrated into the MDS like Storage Virtualization, Encryption of Data at Rest, and Data Migration can get applied against all the corporate data in the FC SAN.
4) For Cisco customers, uniquely, this lets their existing MDS infrastructures continue to soar and interconnect with FCoE for host-access to the SAN.
5) Cisco is continuing to invest in R&D for the MDS 9500 series, delivering on a strong roadmap of innovative products that continue to lead the market in services, stability, investment protection, etc. (Will we get to 8Gb and such? Certainly, the MDS is already shipping 10Gb, if you can do 10Gb, I assure you you can do 8Gb ;) But we felt it was also important to not require 'yet another director' to get there.

I hope this helps clarify where we see FC and FCoE.

Chirp ;)

Posted by Douglas Gourlay at 12:44 AM Permalink | Comments (0) | TrackBacks (0)

Another day in paradise...

Sitting in my big green chair at home (it's been with me for 13 years and is kind of a faithful frind like that although it's fading on the side the sun glares on all day) and reading a few blogs, catching up on my email, and reminiscing a bit.

Tonight at Cisco we had a party for employees that are celebrating their 10-year anniversary here. Pretty neat to think about where things were in 1998...
Google was being founded.
FibreChannel Switching was being developed.
I was an SE installing ATM to the desktop
'Analysts' proselytized Fast Token Ring and Gigabit Token Ring
We both learned.
Layer-3 Switching was 'cool and new'
There was a difference between switches and routers
We were installing FEPs into Routers to connect Mainframes over WANs without OSA adapters
Voice over ATM was cutting edge
MPLS... ??? it was a year later we got the first multi-vendor label swapping working at Interop
I just got a new laptop with a smoking Pentium II processor with MMX extensions! It was a Toshiba Tecra I believe.
Windows 98 was money
But my NT 4.0 was more stable
The companies I competed with.. don't exist now

Strange how quick a decade can go. From a pure technology time though it's also neat to learn the lessons from the past, see how they fit to the future, look at what we're building and where the market and industry are going and pull your sunglasses off your head, fasten your seatbelt, and get ready for a wild ride...

You ever wake up the day after your birthday as a kid, a bit tired from the sugar rush leaving your body after having a wee too much cake and ice-cream and realize as you stare around at that new GI Joe with Kung Fu Grip that it'll be another year before it's your day again?

Don't you sometimes wish you could have two birthdays in a year? I mean, that would be pretty cool right?

A few weeks ago we introduced the Cisco Nexus 7000, a data center class switching system. A lot of people have written about the system, Unified Fabrics, technologies like FibreChannel over Ethernet, Virtual Device Contexts, NX-OS, Zero Service Disruption Upgrades, etc... some people probably thought that was it, and we'd have a lull for a while as we went and built something new to talk about in another year, another "birthday". Hang on to your hats, the next few weeks are going to be quite fun again.

Posted by Douglas Gourlay at 12:00 AM Permalink | Comments (0) | TrackBacks (0)

March 26, 2008

Data Center Virtualization R Us

Allan Leinwand had a provocative blog post on gigaom.com the other day about the imminent arrival of a blade server for the Nexus. Doug ably explained why we would not do such a thing, so I am not going to revisit that, but I do want to explore the question Allan posed at the end of his entry:

Who do you think can provide those resources more effectively -– a blade server manufacturer using virtualization with networking added to the system or a data networking manufacturer adding blade servers and virtualization?

Not wanting to let Allan have all the fun, let me take a run at answering this question of who is better positioned to support data center virtualization, and, by extension, server virtualization. If you think about it, data center virtualization is about pulling down walls and blowing up silos--its about giving an application the most appropriate resources at a given moment based on the priorities and needs of the business. Underlying this is the idea of making data center infrastructure appear as homogenous pools of resources--you are able to supply processor cycles to your application or storage to your application without being so concerned about the specifics of the underlying physical asset. Cisco DNA is rooted in concept of delivering ubiquitous access to data center resources. With an AGS+ in my data center I could access a collection of disparate hosts without concerning myself with how those particular systems connected to the network. A few years, our SNA integration strategy (DLSw anyone?) opened up the value companies had locked up in their mainframes to anyone with an IP stack. Fast forward to today and one of the benefits of a unified fabric is providing ubiquitous SAN access to any server. See the common theme here? Expect that trend to continue as we continue to execute on Data Center 3.0.

Contrast this with the blade environment, which is, by nature, proprietary and closed. What ever innovation is delivered, no matter how cool, is walled inside a vendor specific, form factor specific silo. Multiple blade vendors? Too bad, you are locked-in. Application requirements dictate rack servers, tower servers, or mainframes? Sorry, can’t help you. You end up in an architectural cattle chute or you end up trying to manage disparate virtualization schemes across your data center. Neither seems all that appealing to me.

Finally, when it comes to virtualization experience, the leading blade server vendors today are not delivering server virtualization, VMware, Xen, and Microsoft are. On the other hand, we are delivering network resource virtualization with VDCs in the Nexus, VLANs across the Catalyst family, VSANs in the MDS family, L4-7 service virtualization in products like ACE and the Firewall Service Module, VBS switch virtualization in our next-gen blade switches, heck, even the new ASR is running KVM.

Granted I am a little biased these days--although I did start out life as a VAX and System V sysadmin--but getting back to Allan’s original question, while we are not quite there yet, I think Cisco has the shorter distance to travel here....but I am guessing there are some of you out there that might have a different viewpoint...? ;)

Posted by Omar Sultan at 12:16 AM Permalink | Comments (0) | TrackBacks (0)

March 23, 2008

'Om'nidirectional Nexus

Was just reading this article on GigaOm about the Nexus 7000 as a sort of mutated blade server chassis. I wanted to reply to it that there isn't much possibility of the Nexus 7000 as a server platform itself, although it, I believe, is one of the best Server Interconnect platforms ever delivered. :)

Interesting conjecture, but doubt we'll see that as an evolutionary path unless there is a major reduction in power draw for both CPUs and DRAM.

Posted by Douglas Gourlay at 06:51 PM Permalink | Comments (0) | TrackBacks (0)

March 21, 2008

Managing the Lego Data Center

During customer briefings, I’ll often use the concept of the Lego data center when talking about the vision behind Data Center 3.0. The joy of Lego (for me at least) is the ability to build something then, (sometimes violently) break it apart and build something else. This is the operational model we look to bring to the data center—sans most of the violence--with Data Center 3.0.

Virtualization has a central role in this vision, but asset virtualization introduces its own challenges. Arthur Cole has a posting today where he notes that “Management issues begin to get more complicated once virtual servers start to rely on virtual storage.” I’d actually take it a step further than that.

Even today, I would say that data center virtualization efforts are simply tactical responses to a given problem, say server sprawl. Within a given technology silo, they may fix a problem, but, as a whole, is the data center any better off? Probably not, and managing disparate virtualized assets on top of physical environments might make things a bit worse.

I don’t think “virtualization” is going to deliver any net benefits to the data center until we can address the issues of orchestrating services across technology silos. So, if I move a virtual machine, the SAN, firewall, switch and load balancer, etc, all have a clue on what to do next. This should be the next great battle in the data center. There are a lot of interesting solutions out there and, of course, we have some interesting things in the pipeline too. The problem is that, to date, no one has a good holistic solution, so it seems like some M&A activity needs to happen (no, that’s not a hint) or at least some solid alliances built, before customers get something truly practical.

Posted by Omar Sultan at 09:53 AM Permalink | Comments (0) | TrackBacks (0)

March 19, 2008

One Big Happy Fabric

Was recently reading this article about FibreChannel over Ethernet, something we have written just a few times about :) I came across this article today on the technology and how it is coming along in the standards bodies and with a full slate of multi-vendor support coming in behind it.

The really interesting part of FCoE is going to be how the adoption/evolution works. The way we are looking at it is fundamentally how do we evolve our existing director line to support FCoE interconnects with our Nexus line. The Nexus will primarily be interconnecting hosts/initiators, while the MDS will primarily be interconnecting arrays/targets. I think this is a rational adoption and evolution plan because at least historically IT departments seem to adopt new technologies on hosts more quickly than on targets. Additionally there is the outlier of a groundswell effect...

If PCIe converged network adapters are available this year, they will be used primarily for test and qualification of an FCoE infrastructure. Test the Nexus interconnecting with hosts, JBODs, then into SANs via a separate VSAN, and then into wholesale production.

The groundswell happens in 2009 and onward. When the 10GbE FCoE technology is integrated into the server mainboard with LAN on Mainboard ports and new servers start shipping with this technology available, by default the game will change.

Fundamentally every server will have a Virtualized I/O. Similar to what the VMWare Hypervisor did to abstract O/S from Server Hardware allowing any workload to be located on any server; our Unified Fabric virtualizes the I/O so that any server can be software provisioned to have the I/O characteristics it needs to process the workload you would choose to locate on that host.

Hypervisors enabled software provisioning of server CPUs
Unified Fabric enables software provisioning of Server I/O

Posted by Douglas Gourlay at 06:07 PM Permalink | Comments (0) | TrackBacks (0)

Gold = Good, Happy Customers = Great

All vendors get excited when their products win awards and get listed publicly. Cisco was no different when we won not one, but two GOLD MEDALS for our application networking products in SearchNetworking's Product of the Year awards for WAN Optimization and Application Delivery Controllers.

But what really should make vendors the happiest is growing numbers of satisfied customers that are getting real business benefits from their products...

Cisco was happy in this context also this week -- analyst firm IDC published a
case study on a large US bank which deployed the Cisco ACE platform.

The 8000+ end users of a key bank application, supported by 450 IT professionals, gained "very high marks" from the following benefits per IDC's write-up:

* Strong load balancing capabilities. All of these features improve performance
across the MPLS network.

* SSL load balancing. The Cisco ACE platform provides SSL offload so the
external Web site servers do not have to use CPU cycles to encrypt/unencrypt
Web traffic. This feature improves both performance and security of the
externally facing Web servers.

* Role-based administration. This allows approved IT personnel to perform
maintenance on specific servers without the involvement of the network team.
The result is more efficient management of servers and lower operational and
administrative overhead.

(source: IDC case study, March 2008)

Clearly one customer's achieved benefits and point of view. Now here's the open question to readers: what makes you (or your end users) "happy" when it comes to deploying and using application delivery equipment? And what doesn't??

We would like to hear your thoughts....

Posted by Mark Weiner at 03:30 PM Permalink | Comments (0) | TrackBacks (0)

March 18, 2008

Data Centers Down Under

On a plane flying to Sydney to start a week long Asia Pacific Tour. Will be meeting with customers across a few parts of Asia and rushing home to paint Easter Eggs, hide them, and then wonder oddly enough a few days later where that interesting sulphur-like smell is coming from.

This week I am going to try something new for me. Yes, I know, I am years behind on technology and using the web, but am going to try to do a few video blogs of the different data centers we may see, if their are architectural differences 'Down Under', does airflow work differently in Australia? i.e. does hot air fall and cold air rise?

What will be different about data centes in APAC? Same cooling and power challenges as in the US? Will the power infrastructure be leaning toward 'dark green' i.e. sustainable, renewable, and non carbon emitting sources? Will the availability of bandiwdth have a different end-user expectation on service delivery? Can a global corporation truly effectively support their APAC employee base from centralized US data centers or are their regulatory issues and bandwidth latency issues for certain applications that mandate local presence? These are some of the things I want to determine and learn about. Does anyone have any insight into this?

I've been to many APAC data centers and met with many customers over there and it strikes me as very similar in some countries and wildly different models in others. I know our local teams have a deep partnership with our customers in Asia and a long history of supporting their business, but are their macro level trends in Asia that are different than the rest of the world?

Posted by Douglas Gourlay at 05:50 PM Permalink | Comments (0) | TrackBacks (0)

March 17, 2008

Why You'll Want This Switch, Part 3

So, as an impressionable young “yout”, as Joe Pesci would say, in the early days of networking, I learned an important lesson. I have to admit I started out as a Wellfleet bigot (http://en.wikipedia.org/wiki/Wellfleet_Communications for those of you who, sadly, have no idea what I'm talking about). At first blush, it looked to be a better box: elegant hardware architecture, checked all the boxes in terms of standards compliance, better performance (on paper at least)—hands down, the BCN won the data sheet wars.

But a curious thing happened…

...I learned that when it came to deploying features and functionality that mattered to people who’s jobs depended on the network being up and running, those people consistently chose Cisco. Case in point: I worked for a service provider that sold both Cisco and Wellfleet access routers as part of our managed router service. I learned that our field engineers would take a Cisco router out with them, even if they were installing Wellfleet routers at the customer prem. Why? Because the Cisco router did a better job of helping them troubleshoot problems bringing the network—‘nuff said. I started prepping for my CCIE shortly after.

So, fast forward a decade or so (long enough for Wellfleet to become Bay Networks and then part of Nortel), and you can see this heritage in the Nexus 7000. As we look to help our customers build more scalable systems, one of the areas we concerned ourselves with is helping the operations staff scale by giving them tools to help them be more productive. We put a lot of thought into the Nexus 7000 to make it more manageable and we think you will find we baked in some useful innovations. One of my favorites is CMP, which is an independent sub-system that gives you lights-out style management capabilities with the system. Anyone who has had to reboot a remote system and is familiar with the praying that goes on while waiting for the login prompt to come back will appreciate this feature. Folks have been doing this for years with terminal servers and modems, but we built-in the functionality and let you access the system at network speeds. Another favorite feature is a built in protocol analyzer for the control plane. We built WireShark (http://www.wireshark.org/) into the Nexus 7000 to give you a distributed sniffer network to allow you to do packet captures and decodes of control plane traffic. Off the top of my head, couple of more manageability features include Call Home and Flexible NetFlow. Finally, all the high-availability features, like the stateful restartable processes help keep the staff out of fire drill mode in the first place.

While I will always have fond memories of the venerable BCN, I think the choice then, and now, is a no-brainer. So, why do you want this switch? :)

Posted by Omar Sultan at 09:21 AM Permalink | Comments (0) | TrackBacks (0)

March 14, 2008

Death Star Network Design Contest

I was trolling through some stuff last night and came across this new building being proposed as a convention center in the United Arab Emirates. It's an interesting piece from a design perspective, and in this case I would say function is clearly following form. Let's call this for now the Death Star Convention Center.

Now I realize that this is an interesting building, and a wonderful concept. Would the network cabling come up the risers into the main reactor? How do the tractor beams interface with the TIE fighters? Ethernet? 802.11n? These things keep me curious.

If anyone can post some decent designs in PPT, Visio, or as a Video Blog and link them in I will send a Cisco Nexus Fleece to my faves. Eddie Izzard had some ideas on things that were necessary in the Canteen/Cafeteria of this convention center that are worth noting as they directly relate to the design criteria...

Posted by Douglas Gourlay at 11:38 AM Permalink | Comments (0) | TrackBacks (0)

Virtual Devices by Michael Morris

Just a quick link to our reader to check out Michael Morris's write-up on Virtual Device Contexts. Michael, nice blog, detailed, and very well thought out. Michael's blog.

I wanted to point out that this is another example of 'organic innovation' brought forth by Cisco Engineers and Product Managers working intimately with our cutting edge customers. The genesis of this idea by the way came from a variety of sources, but one was Mike van Norman from UCLA's networking group who wanted to share a large switch with four departments and optimize his infrastructure without proliferating a lot of smaller devices. Mike, wanted you to know we never forgot, and we delivered. Even though that lunch was in a deli in LA in 2003/2004 I think.

Also, for anyone who wants to copy this innovation (not that I encourage blatantly copying others pioneering efforts): have fun rewriting your entire operating system architecture to be modular, multi-threaded, with separate memory-state machines for each stateful process. Should take 3-4 years if you start today...

Posted by Douglas Gourlay at 05:39 AM Permalink | Comments (0) | TrackBacks (0)

March 13, 2008

Branching Out

I'm sitting here in my office at 8:30 on Thursday night when I should seriously be out having a cold adult beverage somewhere. But instead I read an article that just got to me. I don't write much about things not totally linked to the data center, so this was a bit of a departure, but one with which I hope you find worth investing a few minutes of your time on reading.

Network World has this habit of dignifying things that employees of a company up north happen to write a bit. The latest ill-conceived spawn from their fingertips is of course linked right here as always.

I do hope someone could take a stab at helping Tony out with how to design and build his mythical branch. I also think there is a life lesson here to be learned. While I like to hit back with a bit of a wit which has earned such fun comments as 'So Gourlay is a Schmuck' or my favorite 'my passive aggressive style that I am known for'. (which by the way I find endearing, heart warming, and just downright funny) I do hope everyone can see that I have yet to call out any person at a competitor, link to a competitors collateral, or even call another company out by name.

I guess this approach is part of what separates the lead dog from the ones with a much different view...

Happy Thursday, enjoy the view.

Posted by Douglas Gourlay at 08:29 PM Permalink | Comments (1) | TrackBacks (0)

March 11, 2008

Don't take my Kodachrome Away...

I have to hand it to Brad Reese for being able to drive a discussion :) Ok, or maybe to fan the flames of a mild-mannered campfire into that of a forest-sweeping conflagration. But either way it is just downright funny to me the comments people are making on Network World.

I guess being called a 'Schmuck' isn't so bad, even though it means I am probably off of our northern neighbor's holiday card list for eternity.

I titled this 'Don't take my Kodachrome Away' not only because I happen to like the song, but also because we asked one of our top customers once if they thought it would be to their advantage for us to invest more in using merchant silicon, or to keep innovating in our own custom designs. This rather large web company was adamant that we keep our own silicon investments up. Why? Because if the market 'devolved' to only having two main suppliers of switch fabrics, forwarding engines, and port asics there would be a significant reduction in innovation, but also an increase in 'churn rates' of their equipment.

Not my opinion mind you, a customers.

But one worth digging into a bit... especially the last point as the one about innovation has already been supported by our competitors who praise merchant silicon, but when it comes to invention/innovation validated the custom ASIC route. (note to any disaffected silicon developers- we love you guys)

But as to the lifecycle comment- when we build high-end modular platforms we make design decisions around building platforms that last at least a decade. This requires not only foresight, participation and leadership in standards bodies, and the deliberate application of decades of lessons learned in leading the Ethernet market but more importantly it also requires an architectural decision. These architectural decisions around lifecycle preclude merchant silicon- mostly because the vendors of these chipsets have a penchant for changing their system architecture every few years. If Cisco followed this route we would be no different from the companies who change their switching platforms introducing new ones and obsoleting others at 3-4 times the rate we do.

btw- if we forklifted the Catalyst 6500 at the same rate as some of our merchant silicon based competitors we would generate a pile of Catalyst 6500s about 53 miles high... annually. Now that may be a good thing for revenue, but its not the right decision for our customers.

Happy Tuesday, and may it continue to be a colorful one...

Posted by Douglas Gourlay at 05:51 PM Permalink | Comments (0) | TrackBacks (0)

March 06, 2008

On Merchant Silicon and Mowing My Yard

Recently there was a quick write-up by one of my favorite competitors in the switching market arguing against my assertion that 'merchant silicon' is essentially 'not a good thing' in the switching space. Let me clarify...

Maybe an analogy will help. If a switch is like a car then the switching silicon would be most analogous to the engine and/or transmission. i.e. the core of the car and a major point of competitive advantage and differentiation. Do major automobile manufacturers outsource engine design and development to other firms? Of course not, they design and build their engines. Do manufacturers of more consumer goods like lawn mowers outsource their engines? Absolutely, they go to specialized engine manufacturers because the core value of what they offer is either a certain price point, or the value is not tied to the engine.

So the question then - is do you want to ride to work or school in a car, or on a lawnmower? I know one would get me laughed at if I was in school, the other... not so much :)

Applying it back to switching, I'd rather control my own destiny and align the core value creation in the silicon with the hardware and then with the software and continue to drive innovation at every tier and not saddle up on my Toro in my enterprise. (no offense to the manufacturer of lawn mowers, I am a good customer of yours too :)

Posted by Douglas Gourlay at 12:10 PM Permalink | Comments (7) | TrackBacks (0)