Intellectual capital driving the cloud

It is wise to follow the movements of thought leaders in Silicon Valley. Why is that? Because when enough smart people land at the same company, it is only a matter of time something great happens. This “human network” of intellectual capital has been the seed of many successful tech companies, and will continue to be true in the future.

One of these tech companies with a wealth of intellectual capital is Arista Networks. There are A LOT of ex Cisco folks walking the halls of Arista. Many of them come from the Granite Systems acquisition (Cisco’s 4500 platform). This platform, while designed with line card oversubscription to keep it between the 3560 and 6500 platforms in price and performance has an extremely elegant internal architecture. Case in point, the 4500 platform has had in service software upgrade (ISSU) for over two years, something that the 6500 still struggles with.

Now that this team, and key leaders from Cisco and other tech companies are putting together a network platform, what can they do? And more importantly, what will they do?

Before I dive into that answer, I think it is important to take a quick overview of the two major camps of network platform development, and what the advantages and drawbacks of each method is.

Creating your own ASICS in house

The first way is to create your own ASICS that handle switching and security functions. In this case, you are effectively a chipset manufacturer, who then bundles your own chipsets into routing, switching and security platforms. On one hand, developing your own ASICS can give you a competitive advantage by rolling in features that are not available to your competitors.

On the downside however because of the high cost of developing these chipsets you are forced to design for a very long lifecycle (7+ years). Another downside is that if you have any problems with manufacturing, you cannot just call up another supplier and change your sourcing strategy because you are that supplier. In the case of any Fab issues you are forced to slip your product delivery dates.

Utilizing market silicon

The second way is to utilize routing, switching, and security ASICS that are commercially available through many manufacturers and wrap your own software and chassis integration around them. This is commonly referred to as “market silicon”. In this case, your focus is end to end integration of commodity ASICS and most importanly creating  software differentiation to add value to your product.

The positives aspects of this model is that you are not locked into your own chipset design time lines. If your primary chipset supplier has a Fab issue, then you can easily change your supplier and hit your deployment time lines.

The downsides of this model is that every single networking manufacture in the world has access to the same chipsets. This forces a vendor to differentiate through better software, support, and integration of these “Market Silicon” ASICS into a superior platform.

Who uses what?

With all the talk of Market Silicon being evil, the reality is that the major networking manufacturers use a mix of home grown ASICS and market silicon to drive their products. I can’t say who uses what, but feel free to crack open your switch and take a look at the chipsets on the line cards. Don’t be surprised if you can find some market silicon sprinkled here and there. Now that doesn’t mean that these platforms are bad, it just means that for certain functions it is cheaper to source ASICS externally then to create them in house.

How does Arista approach this problem?

Aristas focus is to create an extensible network operating system that can manage and enable multiple switching ASICS and switching platforms (VMware Virtual Network Distributed Switch – vNDS).

Extensible Operating System (EOS/vEOS)

Arista created a new operating plaform, based on Linux that manages both the physical and virtual implementations of switching devices (ASIC and Virtual Switches). It is called the Extensible Operating System. This operating system has hooks into all the ASICS and vSwitches that it supports. Most importantly it provides one single operating system for all supported platforms both physical and virtual.

sysDB

Core to the functionality of EOS is the sysDB. What is the sysDB? It is a custom real time database written specifically for the interaction of individual system processes. These include routing, switching, security, management processes. By centralizing all of this information in a central location the time to react to events is minimized . This is especially true when compared to classic networking implementations where independent processes keep independent state.

vEOS

Virtual Extensible Operating system is just that – A virtualized instance of the items mentioned above. This can be run inside a vmware virtual machine. It is the same operating system, database, and daemons that run on Arista’s physical hardware. The only difference that it happens to run inside of your virtual infrastructure.

You may ask the question, why would you want to take a network operating system / hardware combination and split it apart?

vEOS and VMware Virtual Distributed Network Switch

EOS and vEOS have implemented a hook into VMware’s vNetwork Distributed Switch (vNDS) API. In effect, you can think of the vNDS as just another ASIC to the operating system. Instead of connected through a device driver, EOS and vEOS connect in through an XML API. This accomplished the function of both retrieving status and performance information that the vNDS provides, and creating policies inside EOS and publishing them into your VMware switching infrastructure.

If you have an Arista switch directly northbound of your ESX servers, you get this monitoring and configuration feature for free. If you don’t have Arista switches, (say you have Cisco, HP, Juniper or Foundary) you can use vEOS (the virtual instance) and pay a fee to get a cli interface into the VDS.

vEOS vs Nexus 1000V

This is a likely to be a highly contested item, complete with competing bumper stickers. In my opinion it isn’t that big of a deal. The reason being is that the 1000v and Arista’s vEOS implementation are completely different. Cisco’s 1000V is a dedicated piece of code running on your ESX servers that handles switching differently then VMware’s vNDS. Arista’s implementation of EOS and vEOS is more of a management interface to VMwares vNDS. vEOS does not replace the switch inside VMware, it configures and monitors it through the vNetwork API.

When comparing the two products head to head, the discussion is really a VMware vNDS vs Nexus 1000v discussion. If you have already decided to move to the 1000V because of the feature differential between the native vNDS then nothing really changes.

This doesn’t mean that vEOS does not add value. In smaller environments where the 1000V is not an option, or in an intercloud situation where state needs to be passed between disparate network instances vEOS’s vNDS implementation can be very valuable. If the vNDS features are all you need, but you would prefer a CLI for your VMware switching and cannot justify the expense for the 1000V licenses, then Arista might be right for you.

Want to learn more?

Arista Networks – Extensible Operating System

Andy Bechtolsheim’s opinion on Market ASICs

VMware Virtual Network Distributed Switch

Cisco Systems – Nexus 1000V

Similar Posts:

• Jayshree Ullal takes the helm of Arista Networks
• Cisco Nexus 4000 Blade Switch
• Cisco NX-OS 4.0 | Next Generation Internet Operating System
• Cisco’s Cloud Computing Offering
• Altor Virtual Network Security Analyzer (VNSA) integrated with Cisco’s Nexus 1000v for VMware
• Cisco is using Linux virtualization and 40 core CPU’s for its next generation routers

--Colin McNamara

Arista Networks – Their approach to cloud networking

If you happen to be in the same class, or see me passing in the hall, feel free to pull me aside and say hi.

Tuesday
10:00 AM-11:00 AM	EA3605 Room 302	Virtualizing Tier 1 Applications: The Value of the vSphere Internal Cloud as a Better Platform for Apps
11:30 AM-12:30 PM	VM4800 Room 110	The “Next Generation Data Center” for Telecommunication Companies
1:00 PM-2:00 PM	SS5240 Room 134	Engineering Developments Enabling the Virtual Datacenter – VMware, Cisco and EMC
2:00 PM-3:30 PM	EA3234 Room 104	Virtualizing SQL Server in a VMware vSphere environment
4:00 PM-5:00 PM	VM2472 Room 303	Introduction to VMware vCenter Chargeback
6:00 PM-7:00 PM	EA1820 Room 310	Virtualizing Critical Healthcare Applications

Wednesday
10:00 AM-11:00 AM	TA3286 Room 132	Applications in the Cloud: Getting off the ground
11:30 AM-12:30 PM	EA2583 Room 110	HPC/Grid Computing and Virtualization
1:00 PM-2:00 PM	TA1962 Room 121	How and Why we Upgraded Herning Kommune’s Production Environment to vSphere 4.0 at GA
2:30 PM-3:30 PM	TA4100 Room 303	Internal Clouds: Customer perspective and implementations
4:00 PM-5:00 PM	VM3881 Room 309	Business Objects SAP Virtual Infrastructure Lab Manager Deployment and An Overview of the Best Practices and Process of Migrating Between Network Ranges

Thursday
9:30 AM-11:30 AM	LAB11 Nob Hill A	VMware vCenter Chargeback
11:30 AM-12:30 PM	TA4881 Room 132	Designing Dynamic Data Centers with NetApp and VMware
12:30 PM-2:30 PM	LAB09 Salon 4	VMware vCenter AppSpeed
2:30 PM-3:30 PM	EA3241 Room 301	Beyond Infrastructure as a Service: Developer and Runtime Services with VMware and our Partners
4:00 PM-5:00 PM	EA3481 Room 301	Virtualization of Analytic Databases

Similar Posts:

• Cisco EMC and VMware partneship VCE VBlocks Acadia and the Partner Ecosystem
• Cisco’s Cloud Computing Offering
• Link Love – Blogs that linked to me this month
• Where is Colin ? Passing the VCP exam (VMware Certified Professional)
• Interesting TechWise TV episode on virtualization
• Is your network ready for Cloud Computing with Virtual Infrastructure 4?

--Colin McNamara

VMworld 2009 Schedule

“it looks like one of the key features not on the list of components for the California boxes is going to be a red discount pen”

Timothy references sources who have obtained a price list and shared it with “El Reg” . I wish Timothy would have contacted an actual Cisco Unified Computing System Advanced Technology Partner, because any partner that is involved in the launch could have explained to him the concepts of List price (List), Manufacturers Suggested Retail Price (MSRP), and Purchase or Buy price.

In this article I want to dispel the myths of server and network manufacturer pricing, demonstrate the true cost of building a data center with blade systems, and at the end provide a cost comparison between legacy server vendors options and Cisco’s Unified Compute System.

First, lets go over some the basic concepts of vendor pricing. At the end of this you should understand the difference between list price, manufacturers suggested retail price, and purchase price.

List Price

List price is a high level number that Cisco publishes weekly in its global price list. The purpose of this list price is to provide a uniform price list across all product sets that Cisco offers. The most important thing about list price is NOBODY EVER PAYS LIST PRICE. Let me repeat that again NOBODY EVER PAYS LIST PRICE. Are we clear? This is similar to list price on a car on the car lot. All list price provides is a starting point where a Cisco partner and a customer can negotiate a common discount and end up with something close to (generally at or below depending on technology type and yearly spend) MSRP.

Manufacturers Suggested Retail Price (MSRP)

This concept is something that anyone who has purchased a car before is familiar with. The number that is on the window of the car when you look on the lot is list price. The first number the dealer brings up lower then sticker is MSRP. Depending on the popular of the product, the competition in that particular space, and the negotiating power of the customer you will either pay that price, or some percentage below. For example if you are buying one new car you may have the negotiating power to get the price to drop 5% off of list. If you are buying 200 new cars (say a fleet) you have significantly higher negotiating power, and you may be able to drop the price by 15% of of list price.

In Networking Sales MSRP is significantly less then list price. A good exercise to see what this number is, is to find a device, say a WS-C3560E-12SD-E (3560 with 12 Gig SFP ports and 2 10 Gig ports) in the Global Price List. You have access to this at any partner level at www.cisco.com/dprg . (my point here is that this is no big secret). As of Friday June 12 2009 the LIST price for this product is $19,995.

Now take that same part number - WS-C3560E-12SD-E and pop it into your google search window. Within the top four links I found this product for $12,434.15 . This price is for  pure fulfillment, with no value added consulting or design work from you local Cisco partner.

If you do the quick math, this price difference is equal to 38% off of list price. Come to your own conclusions, but it would be safe to say that this could be considered MSRP for Cisco products.

Purchase / Buy Price

Buy price is just that, the price at which the customer purchases (buys) the product. This is can be at MSRP, or if the customer is buying significant amounts of hardware at a time, or if there is a “special” (programs and incentives) going on the number could be slightly lower then MSRP.

Percent off of list differences between legacy server vendors and networking vendors

This is where the biggest confusion is coming from. Legacy server manufacturers  have set their list prices much closer to MSRP then networking vendors (remember, MSRP is the price where most customers purchase at).

Why is this? In the networking space, vendors have historically created their own processors, ASICS and boards. This means that the sales discussions are feature to feature. It also meant that you had to have a conversation with the networking vendor or networking partner to properly size your network devices and get a quote – which is around MSRP, not List price.

In the legacy server space, especially the majority of the x86 server space, the market has been essentially commoditized. E.G. – You can buy an intel based server with X amount of memory and hard drives that will perform roughly equally from any of the main manufacturers. That made it much easier for a sever admin to just pull a price off of the web and compare. So what the server vendors ended up doing is setting their list price  only slightly above MSRP.

What this translates to is the list price, between legacy compute vendors and Cisco will be drastically unequal. What is equal is MSRP, or the generally accepted purchase price by common customers.

Why did Cisco set the list price of UCS higher then the legacy server manufacturers?

For the vast majority of its sales, Cisco relies on what is called the channel model. This means that Cisco partners with local Value Added Resellers (VAR’s) who sell Cisco’s products and then provide consultative services to design and implement them in customer networks. Most customers who purchase any regular amount of Cisco product either have a general expectation that they will buy Cisco product at a certain percentage discount off of list and sometimes the partner and customer have entered into purchasing contracts which require that all Cisco product is provided at a specific discount off of list price.

If Cisco decided to set the List price at a small percentage lift over MSRP, this would cause a problem for the entire channel. This would be especially hard for any customer who had a contract to buy product at a specific discount. What would happen is contracts would have to be renegotiated, which generally takes months and is about as fun as pulling teeth.

The second reason for setting list price the for compute the same as list for network is quoting. Right now, if you buy hundreds of different Cisco devices through a reseller it is very likely that the discount is going to be the same across all products. This makes the mechanics of sales much simpler, because you don’t have a lot of math in the quote (this can cause errors). On the customer side, having one set discount makes it much easier to compare quotes and to ensure that they are getting the best deal possible. In short, sticking with Cisco’s current list pricing structure benefits both the customer and the partner.

Now that we have set the record straight on list price, MSRP, and Buy price, lets take a deeper dive into what components make up a blade system powered data center. And then we will compare the price structures of both.

Components of all Blade Systems

Blade Server – The compute blade where commodity silicon elements such as the CPU and RAM are housed. As of writing this article, the latest high performance blades from all major server manufactures support two xeon 5500 processors (Nehalem) and DDR3 memory.

Mezzanine cards – These cards take the place of PCI-e cards in a rack form factor server. In a blade system these provide data network and storage network connectivity. They attach to the blade itself via proprietary connectors that implement either PCI-e 8 or 16 lane connectivity at the time of writing. In some cases other functions such as IO accelerators can also be attached in the mezzanine card form factor.

Blade Enclosure – This is functionally a tin can where eight to sixteen blades are placed. It also is used to provide a centralized power distribution fabric, as wells as slots for interconnections of data and storage network devices.

Data Network Modules – These are effectively ethernet switches that have been miniaturized to fit into the tight confines of a blade enclosure. Classically they have provided 1 gig connectivity to the servers, and 10 gig to the distribution layer, however with Nehalem processors and VMware there is a move towards presenting 10 gig connections to the server, and multiple 10 Gig connections into the distribution layer.

Storage Network Modules – The local disk in a blade server is classically anemic. To provide higher IOPS (input outputs per second) to disk, Fibre Channel connectivity is extended by taking SAN fabric switches and miniaturizing them to fit into the blade enclosure.

Data Network Distribution – If you have multiple blade enclosures there is a need to connect them together at a reasonably high bandwidth. To serve that need a variety of 10 Gig distribution switches are provided from all server manufactures at varying cost and performance levels.

Storage Network Distribution – Along the same lines of the data network distribution, SAN fabric switches have to aggregate up to a SAN distribution layer, or if the installation is reasonably large a “director” class SAN switch. This allows all the blade enclosures to see the same storage network, as well as providing for deterministic storage network performance as you scale out.

Management Infrastructure – All manufactures have a need to manage and monitor all of the devices that comprise their blade system. Many manufactures have multiple management modules per blade enclosure.

Comparison of Costs – Cisco vs Legacy Server Manufacturers

The funny thing, is that many people have assumed that Cisco’s Unified Computing System will be priced higher then legacy server manufactures products. In my mind this is because they associate higher quality with higher price (basically the Mercedes vs Kia discussion). Here is something that will shock you - it costs less to buy an entire blade system through Cisco then to buy from the legacy server manufacturers.

When people hear this, they are puzzled. How can two server manufacturers, who buy their CPU’s from the same company (Intel) and their memory from the same fabs end up with different prices? The answer is elegance in engineering. Lets go through each of the elements of a blade system infrastructure and find out where the costs are. More importantly lets look at where Cisco has innovated to provide higher performance at a lower cost.

Dollars and Cents – How much is the cost difference

I worked up two quotes recently. These quotes included all elements required to build an end to end blade system using both legacy server manufactures devices, and using Cisco’s Unified Computing System. I have broken out two scenarios.

8 blade servers - Cisco wins with a savings of 11%

In this scenario the cost of servers and enclosures were fairly equal. The cost savings started racking up as storage and data networking devices were included, as well as base management software was taken into consideration.

320 blade servers - Cisco wins with a savings of 31%

With 32o blade servers the same cost savings seen in the 8 server scenario were amplified. Economies of scale translated into significantly less devices being required to support the individual compute blades. This resulted in 31% savings compared to the legacy server manufacturers.

Summing it up

Cisco has entered into a highly competitive server market by taking an elegant approach to its blade systems. This approach lowers the purchase price of the UCS through reducing the amount of components compared to legacy server manufacturers. I know that there is a lot of misinformation flying around, and I hope this helps to set the record straight on the pricing of Cisco’s Unified Computing System.Similar Posts:

• Cisco Nexus 4000 Blade Switch
• Simplifying your Data Center with Cisco’s Nexus 2000 Fabric Extender (FEX)
• Cisco introduces the C-Series Rack Servers
• Nexus 5020 – Consolidated 10 Gig Ethernet and 4 Gig Fibre Channel
• Cisco’s Unified Computing System – It’s not just a blade center
• Is your network ready for Cloud Computing with Virtual Infrastructure 4?

--Colin McNamara

Confusion about Cisco UCS pricing – Setting the Record Straight

First and foremost it is important to discuss how many networks are right now (click for larger images)

Figure 1.1

This is a pretty common setup, with 80% of so of systems still physically attached to a mix of 100 and 1000 Megabit access layer switches. The other 20% of virtual systems are attached as through blade center switches with 10 gig to distribution or larger (8-16 core) systems with bundled uplinks to the distribution switches. Service aggregation such as firewall, load balancing, and wan acceleration , image deployment, monitoring / management and other key Data Center services generally provisioned off 1000 Megabit ports in the distribution.

Last but not least, a shadow storage network runs connected to a small percentage of physical servers, and connected to all of the virtual servers via Fiber Channel, iSCSI, or NFS presentation. One thing to keep in mind that all of these elements may not be configured in the “optimal” SRND setup, but it is something that you can expect to see in a real life network today.

What’s so special about Vi4 Application vServices ?

Figure 1.2

The one new feature that is going to throw your network on its heels is vApp. Imagine if any application could be installed on any server in any location of your network at any time. What vApp enables you to do is create a portable application, similar to a Java application that installs in your web browser. But this application can be dynamically deployed to any virtual system in your Data Center as needed in response to a new application request, or the need to dynamically scale an application. What this means to us as network engineers is that any corner of our networks where virtualization is present can become a hot spot for critical application flows. This introduces a new dynamism to our fabrics which wasn’t there before, and frankly many networks are not equiped to handle it successfully.

Currently, to provide virtual machine redundancy we have VMware HA, where we both monitor the availability of a virtual machine. If there is a problem we can restart that virtual machine on another ESX host. With Application vServices there are many new elements and traffic flows. The two most important ones are vLockstop and vCenter Data Recovery. VMware is taking high availability to the next level by keeping a hot standby VM running on a second physical ESX server. If you think about it, you now are adding both additional latency sensitive heartbeat traffic as well as creating a situation where your storage traffic flows can be highly volatile. Additionally vData Center Recovery will be throwing traffic in new and interesting ways across your links.

Adjusting your network designs to deal with the cloud

Figure 1.3

First and foremost application virtualization needs a front end, in network engineering circles we have been handling this successfully for a long time with content switches (load balancers). These provide the logical rallying point for dynamic cloud applications. Since more and more systems will be utilizing these services it is important to ensure that your current content switches have headroom to grow, and if you don’t have any content switching capabilities, it is probably time to take a look at adding them to your data center.

Since applications can exist in any corner of the network, dynamic provisioning of storage and network connections has become critical. Maintaining “shadow” storage networks can provide some dynamic access to storage, however it is now becoming advantageous to virtualize your storage fabric along with your systems and network devices. Fibre Channel Over Ethernet (FCOE) provides just that.

If you look at figure 1.3 above, you will notice a new color introduced into the diagram, as well as the “shadow” storage network removed. This is possible because all the orange links run Data Center Ethernet (DCE) which provides a lossless path for FCOE to follow. The ESX servers now only connect into the Nexus 5000 switches. As you can see, we also have removed the shadow storage network, as it is now consolidated onto our new data center fabric. There may be use cases where we need to extend classic fibre channel connectivity out to certain hosts, and we can do that of the Nexus 5000. However if all possible it is advantageous to utlize FCOE to gain storage mobility and higher bandwidth for your hosts.

You may notice that our uplink counts have doubled. Since we are moving both storage and data traffic over the same links, as well as supporting vMotion and other bandwidth intensive network applications it is time to make the push to port channeled 10 gig adapters. Luckily prices have dropped considerably, where it is not cheaper to use 10 Gig then to bundle 8 1 Gig adapters together.

Last but not least you will notice the core switching is a different color. This is because the Nexus 7000 has found its home in the data center. I wont go to deep into the nexus as that is an article in and of itself. What I will say is that it is the best platform to use to aggregate the amount of 10 Gig links that are populating the data center in a highly available fashion. If you want to learn more about the 7000 I recommend reading these previous articles here here and here, as well as Cisco’s Data Center Switching page.

Your network once Virtual Infrastructure 4 (Vi4) and the Nexus 1000V are released

Figure 1.3

Fast forward to early summer 2008 VMware Virtual Infrastructure 4 (Vi4) and Cisco’s Nexus 1000V are released. Of course a new major version of VMware running your compute cloud, application vServices are in effect, vLockstep is running, and many other features that go with the platform such as the Nexus 1000V.

The Nexus 1000V brings a long missing feature to the Data Center, a defined network edge. Since VMware has taken hold in the Data Center, the boundary layer between the virtual machine and the network has devolved to a dumb bridge running in the memory of a ESX server. Installing the Nexus 1000V in your ESX servers creates a virtual switch with interface counters, pvlans, access controls, QOS and many other features that are critical to operating a Data Center. (check out a previous article about the Nexus 1000V).

Enjoying the fruits of our labors

Cloud computing in general, and specifically Virtual Infrastructure 4 have specific benefits that will drive efficiency and agility in IT as a whole. The mechanisms for these benefits will put increasing load on the storage and data networks in your Data Center. It is our responsibility as network architects to take a proactive stance and provision a network with the immediate future in mind. Luckily planning and preparing for these changes in advance have both benefits for our current infrastructure, as well as allowing us to enjoy the fruits of our labors as Cloud Computing changes from a buzz word to a reality.Similar Posts:

• Where is Colin ? Passing the VCP exam (VMware Certified Professional)
• Cisco releases Nexus 1000V virtual switch for VMware
• VMworld 2009 Schedule
• Altor Virtual Network Security Analyzer (VNSA) integrated with Cisco’s Nexus 1000v for VMware
• Cisco’s Cloud Computing Offering
• Measuring and mitigating risk involved with sharing virtual infrastructure between DMZ and Internal environments

--Colin McNamara

Is your network ready for Cloud Computing with Virtual Infrastructure 4?

Because VMware is central to Data Center architectures, I decided to do a deep dive over the past week. This is not my first foray into virtualization, I have used vmware workstation since 1999 and got my first exposure to Storage Networking in 2004 with ESX. Read an article from 2005 about me dealing with network issues in ESX. However VMware has has added so many interesting and relevant features that I found it was good to do a ground up review on. I have to say, that review was helpful. There are many features that as a network designer that should have been in the forefront of my mind, that I hadn’t grasped the full potential of.

As always, after a deep dive into game changing technology I am filled with more questions then answers. But the answers I do have are enough to try my luck at an exam. With an afternoon free, I decided to try my luck at the VMware Certified Professional Exam (VCP-310). Apparently my deep dive worked, because I walked away with a new cert for the binder

Now with a better understanding of the value adds that VMware Infrastructure 3 (Vi3) has in the Data Center, I need to deep dive again on VMware Infrastructure 4 (Vi4) and figure out how Virtual Data Center OS (VDC-OS) and VMware based application virtualization tie into the classic methods of application virtualization (load balancing and content switching) as well as lay down some common network architectures utilizing the Nexus and converged data center fabrics for the move towards cloud computing in the enterprise. I’ll keep you posted on the results of these deep dives, I am sure it will be interesting.

Needless to say, it is a fun time to be a Data Center geek…Similar Posts:

• Interesting TechWise TV episode on virtualization
• Is your network ready for Cloud Computing with Virtual Infrastructure 4?
• About Colin McNamara
• I’ll be at Cisco Live 2008 (networkers) in Orlando all week
• Nexus 5020 – Consolidated 10 Gig Ethernet and 4 Gig Fibre Channel
• Cisco Nexus 7000 DataCenter switch released – Welcome to DataCenter 3.0

--Colin McNamara

Where is Colin ? Passing the VCP exam (VMware Certified Professional)

Altor networks goal is to provide a single pane view of communications within your ESX clusters, as well as ease access control list creation and deployment. With this single pane virtualization customers should be able to decrease the time needed resolve availability and security issues, allowing virtual enviornments to continue to scale.

This is a sign that we can look forward to many other software vendors adding Nexus 1000v  support to their existing product lines. I wonder who is next ? NetQOS maybe ….

Want to learn more ?

Altor NetworksSimilar Posts:

• Cisco releases Nexus 1000V virtual switch for VMware
• Is your network ready for Cloud Computing with Virtual Infrastructure 4?
• Interesting TechWise TV episode on virtualization
• Arista Networks – Their approach to cloud networking
• Challenges integrating VMware into Cisco networks
• Where is Colin ? Passing the VCP exam (VMware Certified Professional)

--Colin McNamara

Altor Virtual Network Security Analyzer (VNSA) integrated with Cisco’s Nexus 1000v for VMware

The boundary between server team and network team responsibilities has become “fuzzy”

Cisco address’s this issue by putting a switch that can be managed via the same methods common to other network devices inside the ESX cluster. This switch runs the same code that has become standard on Cisco’s Nexus series of Data Center switches – NX-OS.

Prior to adoption of virtualization, when there was a connectivity problem with a host it was quite common for the network team to verify functionality down to the switch port. The server team would do the same. This allowed for each team to focus on areas that met their core competancy. Once we moved from a real switch port, to a dumb bridge inside ESX, lots of finger pointing resulted.

Now, with a Nexus 1000V sitting virtually inside the ESX clusters, the boundary between network and systems teams has been re-estabilished. Now when there is a problem with a host inside an ESX cluster, the network team can use the same day to day troubleshooting tools available to them in other portions of the network to resolve issues faster, and with less finger pointing.

Security controls have been moved further away from the hosts then we would like

A best practice for applying security policy is to apply controls as close to the source as possible. Think of this analogy – Your kids are blasting Radio Disney from their computer. Which of the following do you do?

A. Turn down the speakers at the source

B. Distribute earplugs to all members or the household

Of course, the obvious action is to go to the source, and apply a control (turn down the volume, and tell the kids to clean their rooms). The same principle is valid on the networking side. The best practice is to apply security policies such as VLAN ACL’s and TrustSec policies directly to the switchports that host your switches. Before the Nexus 1000V this was impossible to do in ESX, and forced many environments to move security controls further up into the distribution layer. The side effect of this was that now the security stance from host to host inside ESX clusters was diminished.

The Nexus 1000V brings something called port policies to the table to address this. What these are is pre-configured application security descriptions that are available to you systems administrators to apply in a point and click fashion. Once these policies are applied to the virtualized host, they follow the host where ever it is moved in your virtual cluster.

Provisioning and integrating the networks of VMware ESX clusters with classic networks for most is challenging at best

I wrote an article in march about this specific issue in my post – Challenges integrating VMware into Cisco networks . The core of this issue is that in general that the network integration portions of VMware ESX clusters is not really designed to address server teams , or network teams. In fact, you need to be pretty savy with both portions to successfully integrate VMware clusters into your network. In the real world, you generally find people that are good at one or the other, not both.

By putting a Nexus 1000V in your VMware clusters, you know give the networking teams something they can understand without having to learn Linux, and how it handles bridges (key to understanding ESX networking). With a Cisco switch running virtually inside your clusters, network teams can follow standard core / distribution / access models with the access layer now residing inside the ESX clusters. The network teams can also leverage their existing LAN switching skills for integrating the virtual switches in the clusters with the existing Data Center switching fabrics.

With these roadblocks addressed, Cisco is moving to further the DC 3.0 vision

To realize the DC 3.0 vision, the network inside of VMware clusters had to be under control, and follow the same architectural guidelines that the rest of our network is subject to. With the Nexus 1000V this is now a reality. The next steps withing the DC 3.0 vision to are to extend virtualization and mobility throughout our storage fabrics, and to continue to extend virtualization to the network as a whole, as well as focusing on application virtualization and acceleration to truly realize the vision of cloud computing in the data center.

On the storage virtualization side, Cisco will be using a technology called FlexAttach to enable virtual and physical hosts to change locations in the datacenter without storage team intervention (more on this in a near future post). And on the application virtulization and acceleration side, expect Cisco to continue to enhance it’s existing Application Control Engine (ACE) and Wide Area Application Services (WAAS), and further integrate these into their virtualization offerings.

Want to learn more ?

Introduction to VN-Link network services – Cisco.com

Nexus 1000V overview – Cisco.com

VMware distributed vNetwork switch demo – VMware.com

Challenges integrating VMware into Cisco networks – colinmcnamara.com

Douglas Gourley speaking about how Cisco and VMware will drive Cloud Computing in the Data CenterSimilar Posts:

• Altor Virtual Network Security Analyzer (VNSA) integrated with Cisco’s Nexus 1000v for VMware
• Cisco Nexus 4000 Blade Switch
• Nexus 5020 – Consolidated 10 Gig Ethernet and 4 Gig Fibre Channel
• Where is Colin ? Passing the VCP exam (VMware Certified Professional)
• Simplifying your Data Center with Cisco’s Nexus 2000 Fabric Extender (FEX)
• Is your network ready for Cloud Computing with Virtual Infrastructure 4?

--Colin McNamara

Cisco releases Nexus 1000V virtual switch for VMware

Sadly, I have the unfortunate situation of being tagged as an insider (work in the partner community). So I have to play nice, and cannot reveal any juicy tidbits. Suffice it to say, that Jashree Ullal and Doug Gourlay weren’t pulling anyones leg in the past two years when the DataCenter 3.0 vision was established.

Stay Tuned

–ColinSimilar Posts:

• Me and the Nexus 7000 last week at the Data Center VT
• Thanks and farewell to Jayshree Ullal
• Usability features in Cisco’s Nexus 7000
• CCIE Party 2008 Recap – Cisco Live Networkers 2008
• Sun Project Backbox
• Cisco releases Nexus 1000V virtual switch for VMware

--Colin McNamara

BIG Cisco – VMware announcement – 1:30 Pacific time

He writes about “the VLAN leaking myth” and how it encourages clients to utilize physically separate network infrastructure in the DMZ’s. Now first things first, I wouldn’t call VLAN leaking a myth. At one time it was a very real and serious vulnerability that was exploited by overflowing the capacity of the switch you were attacking, and causing it to “downgrade” from switch to a hub. Once this happened you now had access to previously protected devices, as well as having the ability to sniff data as it passed through the shared hub backplane.

As he mentions though, this is 8 years ago. Most switches have evolved to the point where backplanes far exceed the traffic that could ever be injected into their switchports. Even beyond backplane enhancements there are many ways to further firm up your security stance – Virtual Device Contexts, not using Layer 3 SVI’s on a DMZ VLAN, utilizing PVLANs, using port security, virtual routing instances, and many more. Of course, there are still many other attack vectors that still remain, but can be mitigated by utilizing features built into the majority of enterprise switches available today.

I think the real question is not “are VLANs safe in a DMZ”. The important question is have you mitigated the probability of compromise (the actual threat) to levels that are acceptable to your business. This question remains whether you have a standalone switch or not. So many times we hear about risk risk and more risk. But risk alone is meaningless in a business context. What is important is combining risk with likelihood. For that I like to use a simple table to come up with the true threat.

For example, as I drive to Fry’s there is the risk of me dying due to a car crash. The impact of me dying is very high (risk) however the likelihood of an accident is low, and furthermore I reduce (mitigate) the latent risk (threat) by wearing my seat belt. So all in all the threat of me dying on my way to Fry’s is pretty darn low.

In a business context this may be that I have public facing web servers and network devices in my DMZ. The impact of them being compromised is that my public image may be tarnished for a short time, and my end users may lose productivity if they are not able to VPN into work, or access the Internet while on premise. I mitigate this risk by using firewalls and both host and network based Intrusion Prevention Systems as well as implementing best security practices on my network and systems devices. The latent risk (threat) remaining is at a level that is acceptable to the business leaders, so the system is allowed.

One question that I have seen coming up more often as we move towards fully virtualized data centers is centered around commingling of virtual infrastructure. There are some hard questions which challenge some practices that we have held true over the years.

• Should you allow sharing of physical memory on a host virtual machine between an internal and DMZ server?
• Should you allow virtual infrastructure from multiple security zones to share a storage array or cluster of arrays?
• Should you allow multiple virtual switches in different security zones commingling on the same ESX or Hyper-V cluster?
• Should you allow virtual firewall and load balancing instances protecting internal and external zones to reside on the same hardware?
• Should you allow virtual routing instances from multiple zones to share a physical infrastructure?

In the past world of standalone systems, the additional cost of providing a wholly separate infrastructure for DMZ environments was relatively low. Each system generally had internal disk, or at most direct attached storage. Network devices themselves were scaled down to support one chassis one function. This fit quite neatly into the Enterprise Composite Network model that was quite common from 1999-2003.

Now, many data centers have moved to the Service Oriented Network Architecture (SONA). In this model the cost of a virtualized data center is primarily focused on foundation elements such as the virtual storage and virtual fabrics, virtualized network, and virtual systems elements. The cost of providing additional virtualized services off these elements is low, however the cost of duplicating the physical infrastructure is quite high on both the capital and operational levels. This is forcing the technical and executive leadership at many companies to take a long hard look at the true threats they are facing in previously physically separate security zones such as DMZ’s, Financial and other secure zones. In the end, they are having to decide whether the threat remaining after their security controls is worth duplicating hundreds of thousands of dollars worth of infrastructure or not.

These are hard questions, with really no single good answer. My gut feel is that over the next few years we will continue the move towards the fully virtualized data center where components such as memory, PCI-X buses, storage and network devices are even further decentralized. This will make the cost of duplicating the infrastructure more and more significant, causing consolidated data center (or compute) fabrics to be the norm. At this point the discussion will move away from securing zones by creating separate infrastructure, to providing end to end security, starting integrated application level security, maybe with TrustSec or a dirivative, all the way down to securing the data at rest on disk. For the time being however, the best we can do is sit down and do an honest appraisel of our security stances, mitigate what we can, and do our best to design data center architectures that provide the flexibility of implementing whatever choice the technical and business leaders agree on.Similar Posts:

• Moving towards a Green Data Center – Truth behind the hype
• Cisco’s Cloud Computing Offering
• About Colin McNamara
• Simplifying remote site security with Cisco’s new video surveillance modules on the ISR
• Interesting TechWise TV episode on virtualization
• Cisco releases Nexus 1000V virtual switch for VMware

--Colin McNamara

Measuring and mitigating risk involved with sharing virtual infrastructure between DMZ and Internal environments

This switch answers a fundamental problem that has been presented by blade centers and VMware. The problem is increasing density of 10 Gig Ethernet, as well as the creation of SAN islands to provide storage access to VMware ESX clusters.  The nexus 5020 provides a solution that address both of these challenges, as well as supporting Fibre Channel Over Ethernet (FCOE) for the eventual move to a consolidated data center fabric in the years to come.

Want to learn more ?

Mastering VMware Infrastructure

Nexus 5020 Video Data Sheet

Unified Data Center Fabric whitepaperSimilar Posts:

• Cisco Nexus 7000 DataCenter switch released – Welcome to DataCenter 3.0
• Cisco Nexus 4000 Blade Switch
• Simplifying your Data Center with Cisco’s Nexus 2000 Fabric Extender (FEX)
• Fibre Channel over Ethernet is taking off
• Is your network ready for Cloud Computing with Virtual Infrastructure 4?
• Cisco releases Nexus 1000V virtual switch for VMware

--Colin McNamara

Nexus 5020 – Consolidated 10 Gig Ethernet and 4 Gig Fibre Channel

In the past couple years, VMware has changed from a product hidden in development and testing environments to a full fledged enterprise computing platform. It brings many benefits to the companies that implement it, however with those benefits come changes to the access layer of your data center. Your access layer is no longer a top of rack Cisco switch, or end of row aggregation chassis. It is now a virtual bridge that exists logically within your VMware ESX server.

This causes an interesting question to come up in many customers – Who is responsible for the configuration and maintenance of this Vswitch? At first glance most groups reference the port on the last Cisco switch as the division of responsibility between network operations and systems operations. This has worked well in the past for a three main reasons.

First, it divided responsibilities based on technical skillset. For example a network engineer understands spanning tree, trunking, routing protocols, firewalling. While a systems engineer understands file systems, databases and Linux and Windows operating systems.

Second, it provided for a interconnection point where standardized configurations could be applied by an operational group, versus complicated configurations that could impact overall network designs and require an architectural board review.

Third it provided for a clean hand off for troubleshooting. Both network and systems operations could agree on layer 2-4 functionality in an area that provided for detailed debugging on both sides.

Lack of a defined access layer

VMware ESX throws a wrench in this model. We no longer have this well defined edge at the access layer. The access layer now exists virtually inside a server. More specifically, it is a logical devices running in a Linux server. This presents a challenge because it requires cross over knowledge. Whoever is responsible for this integration has to be fluent in Linux systems administration , and also fluent in network design and operations. Frankly this is a rare skill set to come across, as it requires and engineer who has attained high proficiency in both systems and network engineering.

I see this fuzzy line of demarcation often as a failing point for many VMware integrations. Many times I see network operations teams not involved in ESX cluster design because its a “server” , and systems operations teams generally don’t have the networking skills necessary to design and implement an fully functional system.. The solution to this problem is education and collaboration.

The need for collaborative design sessions

The single most powerful element in a successful VMware integration is the creation of strong design documents. These are created by holding planning sessions where both your systems and networking leads hash out a strong design that takes both short and long term virtualization and network goals into account. Also, many times when people hear the word design, they think it is a high level Visio and a bill of materials. That is a just a fraction of the effort required. A proper design should cover everything from a 10,000 foot overview Visio down to protocol flow diagrams and configuration examples. By created a detailed design like this it is likely to bring up common issues such as 10 gig aggregation, trunking, VMotion security, layer two adjacency and layer 7 network service delivery on a white board instead of a production environment.

To create this detailed design, both your Network and Systems leads have to understand this product. VMware recognizes this is critical to successful implementation (and to further sales of their product) an offers the VMware Certified Professional certification. If you have the resources, I would recommend sending both your network and systems leads to this training at the same time. Having them attend training together allows them to leverage each others strengths and bring up questions specific to their network and their goals.

A real world example of this is the company I work for, Eplus. Last April forty of us, all senior engineers attended VMware Certified Professional training at the same time. The class was mixed up so there was an even distribution of CCIE’s, Systems Experts, and Storage Experts. Needless to say this presented our instructors with some extremely challenging questions, but more importantly it set the stage and created a venue for collaboration between these different practices within our own company.

Real world benefits

A great example of this model’s success this occurred last month. Rick and I were sitting in the engineering side of our Sunnyvale office, catching up on email after giving presentations at Cisco that morning and afternoon. In the bullpen behind us, one of the Microsoft architects was engrossed in a troubleshooting call with a large customer on the other line. It turns out a large systems vendor (who shall remain nameless) had been trying for a week to integrate the first ESX cluster into this network and just could not get the networking portion to work correctly. Our account manager received the call from a the customer, and asked the technical teams to step in to see if we could help out in any way.

The systems engineers were able to isolate the problem down to the network interconnections, but needed to bring in networking resources to resolve the problem. Rick and I were waved over and were given an overview of the problem and introduced us to the customer the far side of the call. We asked a few questions about the physical and logical architecture of their network and created a diagram of their network on the whiteboard. With this we were able to ask them to execute commands continuously isolating the problem domain until we found and resolved the issue.

Seven minutes had passed from the point Rick and I were waved over to the point the customer had a working installation. This allowed the customer to focus on moving their business forward instead of fixing a failed implementation. Three of us on the call had attended VMware Certified Professional training together. We had spent at a minimum 50 hours each creating a baseline of understanding in class, as well as many discussions in engineering meetings. The solution came in seven minutes not because of any one teams individual strengths, but because of collaboration. The systems engineers were able to isolate the problem domain very specifically. And as network engineers trained on VMware were able to quickly understand and digest the issues, and tie it together with our larger understanding of networks as a whole. Only at that point, when the team was able to leverage each others strengths were we able to address the problem so quickly.

There will come a point in the next few years where this fuzzy boundary between the “network” and the “server” is established again. My call is that this will coincide with Cisco finishing development of their Vswitch that will reside inside the ESX server. This switch will require both Cisco and VMware improve their design and integration guides for ESX which are both frankly lacking substance. Until those detailed architecture, integration and troubleshooting guides exist the key to successful ESX cluster implementation will be a strong cross trained systems and network teams that are collaborating on the next level of virtual network design in your enterprise.

Want to learn more?

Cisco – Integrating Virtual Machines Into Cisco Data Center Architecture

This is Cisco’s main design guide regarding the integration of virtual machines. You can use it as a decent high level overview if you are a network engineer who is curious how VMware ESX, or Xen servers for that matter will fit into your network.

VMware – Virtual networking Concepts

This VMware document goes between high level overviews and detailed descriptions. It is a decent resource for a network engineer, and provides an overview of ESX network features, however it misses the target for providing configuration examples.

Blog of Scott Lowe – Technical Lead for Virtualization at Eplus Technology

Scott is an engineer that works with me at Eplus Technology. He is based out of the east coast and covers servers, storage and virtualization. His blog is chock full of good of information. A recent post of interest was how to enable Cisco Discovery Protocol (CDP) on VMware ESX server network interface cards.Similar Posts:

• Cisco releases Nexus 1000V virtual switch for VMware
• Cisco Certified Design Expert – CCDE – officially released by Cisco
• Arista Networks – Their approach to cloud networking
• Resume – Colin McNamara, CCIE #18233
• Cisco NX-OS 4.0 | Next Generation Internet Operating System
• Cisco EMC and VMware partneship VCE VBlocks Acadia and the Partner Ecosystem

--Colin McNamara

Challenges integrating VMware into Cisco networks

I was wrong, the Green Data Center is not about saving baby seals, it is about saving cold hard cash. Saving the world is just a nice side benefit.

That being said, saving cold hard cash is a very important discussion item in any IT Operations group as they are normally seen as a cost center. For them, a penny saved is literally a penny earned. Not only can you save money by not paying for power, but PG&E will actually has a budget to pay you NOT to use their power. Most people here this and get a puzzled look on their face. “why would the power company, who makes money on power, not want me to buy it from them?” The answer is that Californians use more power then PG&E can produce at peak times. When they have to buy it from another state it can cost them 10 times or more then they charge us. This is the reason why PG&E will pay you to use less. Each penny they give to the consumer for saving a watt, saves them 4 pennies (80% return on investment).

Great, PG&E saves money by giving it to me. How do I get this cash? Well there are a couple ways to get this.

1. Incentives for new buying new energy efficient servers
2. Rebates for moving to virtualized servers
3. Rebates and incentives for moving to thin client desktop systems
4. Audit teams for cooling and power if your Data Center is 10,000 square feet or more
5. Incentives for airflow control systems
6. Incentives for high efficiency UPS and power distribution systems
7. Technical services for cooling system evaluation (PG&E funded)

That is a pretty comprehensive list of how to get money from the power company, but you can save even more money buy not using the power in the first place. Not unsurprisingly this starts with the server.

First thing you can do, is virtualize, virtualize, and virtualize some more. For most people this means VMware. For others this may mean Xen, or Microsofts virtualization product. Whatever flavor you chose, the key message is to consolidate from many servers to few. A server sitting “idle” still pulls 50% of its max current. Now, howe many servers do you have that are just sitting there? My guess is a large amount. By virtualizing these servers, you allow them to be stacked onto high performance server that can be run at a higher utilization. This lowers the over all power utilization for your DataCenter. Another side benefit is that ever watt that you remove from a server, you get another watt removed from your cooling.

These same virtualization techniques can also be applied to your network devices, which account for 6 to 12 percent of your datacenters power draw.

Ask yourself a few questions

• ” Do I need 4 different firewall clusters?”. It is likely that these are leftovers from organic growth, and that you could consolidate them into virtual firewalls on a more efficient chassis (ASA comes to mind).
• ” Do I need to maintain physically separate infrastructure?”. There are technologies like MPLS, VFR-Lite, Virtual Switching and more that allow you to consolidate onto a shared network infrastructure, taking a service provider approach to providing transport in your network.
• ” Am I running old inefficient gear?”. Power supplies have increased in efficiency over the last few years. There may be a good return on investment for you to upgrade.
• ” Can I consolidate into larger chassis?”. Ask the question, which is more efficient – a closet full of 3560’s or a 4507? There is efficiency in scaling out.

I hope that reading this has caused you to ask some questions, and maybe look at the larger impact of your network operations on both the ecosystem and your operational expenses. With these questions in hand, you might want to talk to PG&E and your Cisco / HP parter about going “Green” in the data center.Similar Posts:

• Is your network ready for Cloud Computing with Virtual Infrastructure 4?
• Usability features in Cisco’s Nexus 7000
• Cisco’s Cloud Computing Offering
• Cisco introduces the C-Series Rack Servers
• New features in VMware 3.1
• Simplifying remote site security with Cisco’s new video surveillance modules on the ISR

--Colin McNamara

Moving towards a Green Data Center – Truth behind the hype

CERTIFICATIONS / ACCREDITATIONS HELD

CCIE – Cisco Systems Internetwork Expert #18233

VCP – VMware Certified Professional

CDCUCSS – Cisco Data Center Unified Computing Support Specialist

VSP – VMware Sales Professional

VTSP – VMware Technical Sales Professional

TSS – Cisco Technical Solutions Specialist, Data Center

GCIH – GIAC Certified Incident Handler

CCVP – Cisco Certified Voice Professional

CSNSSS – Cisco Storage Networking Solutions Support Specialist

CSNSDS – Cisco Storage Network Solutions Design Specialist

CADCNSS – Cisco Advanced Data Center Networking Infrastructure Support Specialist

CCIE Storage Networking

RHCE – Redhat Certified Engineer #804006368822511

RHCT – Redhat Certified Technician #804006368822511

EMCPA – EMC Proven Professional Associate – Information Storage and Management

NSCA – Netscaler Certified Administrator #2005072

NACE – Network Appliance Certified Expert #12912

NACP – Network Appliance Certified Professional #12017 – Data Protection

NACP – Network Appliance Certified Professional #11985 – Storage Area Network

NACP – Network Appliance Certified Professional #12911 – High Availability

Retired Certifications -

Cisco Qualified Specialist – IP Telephony Support

Cisco Qualified Specialist – IP Telephony Design

Cisco Qualified Specialist – IP Telephony Operations

Cisco Wireless LAN Design Specialist

Cisco Wireless LAN Support Specialist

TECHNICAL PROFICIENCY

PROTOCOL PROFICIENCY

EIGRP, OSPF, RIP, BGP, MPLS,  Spanning Tree, Rapid Spanning Tree, ATM, RTP, SIP, H.323, LWAPP, RADIUS, TACACS+, Ethernet, Fibre Channel, ISCSI, FCIP, FCP, FSPF, NDMP 802.11a, 802.11b, 802.11g, RBE, ISDN, SNMP

Virtualization Platforms

VMware ESX, Kernel Virtual Machine, Xen

VOICE and VOICE OVER IP

CallManager, Unity, ICS7750, PBX Trunking, SRST, Active Directory Integration, Extended Services, Call Detail Recording, Automated Attendant, Extension, Mobility, Asterisk, Callware and VSR VM.

HARDWARE

Cisco Unified Computing System (UCS) 6100, 2100, 5100, Nexus 7000, Nexus 5000, Nexus 2000 and Nexus 1000v switches, Catalyst 1900-6509 switches, 1600-7500 series routers, Cisco PIX firewalls, Cisco Load Balancers, Cisco MDS , F5 Load Balancers, Netscreen / Juniper Firewalls, Cisco VPN3000 VPN concentrators, Cisco ASA Adaptive Security Appliances, Nortel Contivity VPN Concentrators, Aironet Access Points and Bridges, Airespace LWAPP concentrators. 3com TotalConnect racks, Ascend dial concentrators, Netscaler Load balancers, SSL accelerators, SSL VPN concentrators. Brocade Silkworm, HP Eva Storage

NETWORK MANAGEMENT

Nagios, Cacti, NTOP, IPswitch What’s Up Gold, BIG Brother, Spectrum Network Management, Kiwi Syslog,, MRTG , HP OpenView, Cisco Secure Intrusion Detection system, Cisco Network Based Application Recognition, Snort IDS, Netscreen Firewall Manager, Unified Compute System Manager

OPERATING SYSTEMS

Redhat, Suse and Ubuntu Linux, Windows 2000, Windows 2003, Windows 2008, Windows XP, NT4.0, BSD, Solaris, OSX

BUSINESS ENVIRONMENTS

Consulting, Valued Added Reseller, Large Enterprise, Startup, Banking, Service Provider, Software Development, Manufacturing, Military

EMPLOYMENT

1/07 – Present, ePlus Technology

Consulting Systems Engineer – Data Center

Accelerate Data Center sales, design and implement network, storage, and systems solutions for ePlus west coast customers.

Accomplishments

• Developed and deployed go to market strategy for Cisco’s Unified Computing System resulting in significant competitive advantage in the western united states.

• Increased Data Center revenues year over year in a the worst economy in a century.

• Changed regional sales focus from technology silo’s to solutions based selling covering network, systems, storage and applications under one umbrella.

• Established a trend of Advanced Technology account wins.

• Accelerated ePlus’s southern California sales by providing high end engineering support.

• Increased sales for ePlus’s northern California office by overlaying and training field sales.

• Integrated MPLS service provider designs into cutting edge Enterprise Solutions.

• Filled PM and lead network engineer roles for large publicly traded company data center migrations.

• Created modular Cisco design / quote format and menu based hardware and services options to address rapidly changing customer needs.

9/05 – 1/07 ID Analytics

Lead Network Engineer

Lead team of four engineers, Define network and application integration architecture for large SaaS analytics deployment, Leverage networking technology to increase security and availability, and decrease development and product deployment timelines

Accomplishments

• Led team of engineers responsible for all Production and Back Office systems in 2 offices and 3 datacenters

• Designed and Implemented ID Analytics Phase2 datacenter, processing 1.2-1.8 million financial transactions daily.

• Designed and Implemented Contents Switching and SSL offloading solution, enabled non-disruptive scaling of core products

• Integrated ID Analytics product with the largest card processors in the world – Equifax, Visa, TransUnion, etc.

• Designed and integrated centralized Fiber Channel and ISCSI SAN solution, increasing application speed and decreasing production database refresh times from 4 weeks to 1 week.

• Managed and maintained over 130 terabytes of storage

• Created lights out server imaging and deployment solution for remote datacenters

• Deployed and integrated monitoring solutions utilizing open source technology

• Created user emulation probes for real time application monitoring and trending of production systems

• Worked with development and Analytics to create structured Development and QA environments

• Spearheaded project to change Analytics / Informatics environment from “unix for workgroups” to high performance computing environment (HPC)

• Provide structured documentation to US Government and Corporate auditors

• Utilized project management skills for international rollouts

2/04 – 8/2005 Openwave Systems
Senior Network Engineer, Strategic Design and Integration Group
Provide technical leadership, Define network architecture, Establish standards and technical vision. Responsible for researching, developing, and architecting technical solutions to business needs.

Accomplishments

• Designed Openwave’s new Pacific Datacenter Networks, with 900 production, and 2000 development servers.

• Designed Openwave’s Pacific Shores Campus Networks, and Showcase Datacenter.

• Responsible for hardware acquisition budget of 1.7 million dollars

• Established ISCSI IP based SAN infrastructure with DR components in 4 major datacenters worldwide

• Promoted from the ranks, moving from running our VOIP phone systems, to Network team lead, to Senior Network Engineer in the Strategic Design and Integration team.

• Active and engaged member of multiple boards covering design review, change control, and security

• Negotiated with Cisco and SBC regarding datacenter purchases saving $906,000 off list price.

• Renegotiated Cisco support saving Openwave nearly $600,000 over our three year term

• Established improved data center controls, allowing Openwave to pass Sarbanes Oxley (SOX) audits

• Wrote and ran multiple RFP, RFQ, and RFI’s

• Utilized project management skills for international rollouts

• Managed, Piloted, and Installed new wireless systems for our Customer Briefing Center

• Responsible for 6 VOIP clusters around the world

• Recipient of multiple awards recognizing dedication and quality work.

• Attended continuing training for security management (CISSP)

2/03 – 1/04 USMC Reservist activated in support of Operation Enduring Freedom
Information Services Coordinator
Implement and maintain Tactical Data Networks, Provide consulting services to hosting units. Maintain Microsoft Exchange servers in both tactical and garrison environments. Perform security audits and remediation. Train support personnel.

Accomplishments

• Performed Disaster recovery of routed ATM LANE environment for Marine Corps Air Station Yuma enabling over 3000 users to resume work (awarded the Navy and Marine Corps Achievement Medal for that event)

• Performed security audit and created a security and performance remediation plan for MCAS Yuma

• Provided project management and security audit skills to 3^rd Marine Air Wing Yuma server support teams, managed server security audit, security remediation, and SMS rollout.

• Designed and implemented Nagios network monitoring system at Marine Corps Air Station Yuma.

• Implemented Norton Antivirus server for MWSS 473

• Provided training on to data teams from MWSS 473, MCAS Yuma Station IT, and 3^rd Marine Air Wing Yuma server teams.

12/02 – 2/04 2 Cups Solutions, Pleasanton , Ca
Principal Consultant
Founded 2 Cups Solutions to provide cutting edge Voice, Data, Wireless and Security services to clients in the San Francisco bay and Fresno areas.

Accomplishments

• Implemented WAN failover solution at two City of Hayward fire stations.

• Implemented email and web solution for Express Mobile Notary.

• Developed and implemented business plan focusing on State and Local Government contracts.

2/02 – 12/02 ExtraTeam, Pleasanton , Ca
Senior Systems Engineer
Design, Installation, Configuration and Maintenance of network systems consisting of Cisco CallManager, Unity, Cisco Secure ACS, LEAP secured wireless, Aironet, Cisco routers and switches, PIX firewalls, and VPN3000 concentrators. Integrating all systems with Active Directory. Performed VOIP feasibility studies. Managed the entire business cycle including sales, design, installation, training and maintenance.

Accomplishments

• Integrated CallManager voice system with Active Directory

• Recovered a failed CallManager implementation at Phase 2 Strategies (PR firm for Logitech). Implemented CallManager with up to date hardware and software, upgraded Unity up to reasonably current levels. Brought up remote office in Phoenix utilizing SRST.

• Implemented City wide wireless network integrated with active directory for the City of Hayward

• Implemented VPN Concentrators in conjunction with multiple levels of firewalls for City of Hayward and Hayward PD to meet CLETS requirements.

• Implemented network configuration management system responsible for the city of Hayward.

• Implemented new wan for Livermore Pleasanton Fire department moving fire stations from isdn to T1 and Gigabit fiber lines in conjunction with moving the location for the network core.

• Designed and implemented IPSEC based wan for Universal life resources, allowing nationwide secure remote office connectivity while minimizing wan connection costs.

• Designed CallManager based VOIP system for a 27 site school district

• Provided emergency support to Fire and Police agencies across the bay area

• Performed security remediation for a large bay area company

• Participated in large switched network cutover from 7500 to a 6509 with flex-wan modules for Stanislaus County.

• Achieved technical certifications for ExtraTeam to become certified under both the Wireless and IP Telephony revised specifications.

7/01 – 2/02 Infobond Inc. Burlingame , Ca
Network Engineer

Responsible for engineering duties in a leadership role. Integrated legacy PBX’s using VOIP technology. Used Quality of service to ensure VOIP service levels. Support legacy voice over IP and voice over Frame Relay technologies. Upgrade from legacy voice integrations to state of the art VOIP integrations. Create project plans and act on them.

Accomplishments

• Cut over evergreen lines shipping terminal from legacy 3com equipment to VOIP enabled Cisco routers and switches. Accomplished all work during Union stand downs.

• Contracted to Openwave, Inc. to run Remote Access while the engineer was on leave. Ran Remote Access for 5 weeks, resolving DSL RLAN issues and IPSec issues, while reducing trouble ticket backload to manageable levels. Assisted other engineers when needed.

• Implemented Cisco 6509’s to replace aging core network of a Benchmark Capital (bay area investment firm).

• Diagnosed and resolved VOIP issues that were stopping call center rollouts for Embarcadero Systems (a large bay area shipping company).

03/00 – 7/01 Knapp Publishing Corporation, San Ramon, Ca
Network Systems Administrator

Responsible for day-to-day operations of e-commerce data center, and wide area networks Performed DNS changes for both internal and external networks. Designed, piloted, and implemented network changes. Installation configuration and maintenance of NT, and Windows 2k file, print, and web servers

Accomplishments

• Improved service levels from 90% to 99.99%, enhanced security and increased bandwidth were benefits derived from implementing a state-of-the-art web hosting data center

• Implemented a network monitoring system to document, report, and notify of network status.

• Designed and implemented ISDN failover of Frame-Relay Network.

• Designed, piloted, and implemented network changes.

• Replaced NT servers with Linux based servers, integrated with the Windows network

01/98 – 03/00 DKA Computers Inc. Clovis, Ca
Manager Information Services (01/99 – 03/00 )

Ran day to day operations of a central valley ISP. Worked with systems manufacturing to bundle client software with all new PC’s. Partnered with local ISP’s to provide access numbers across the valley.

Accomplishments

• Managed web development, and professional services

• Moved web hosting from IIS to APACHE based servers, drastically increasing site availability

• Produced a forms based web application to configure custom systems online.

• Designed and implemented an IPSec based WAN connecting 3 stores point of sales systems.

• Managed corporate office and data center relocation project.

Senior PC Service Technician (01/98 – 01/99)

Provide on call service. Staff PC help desk. Provide direct customer systems support while maximizing company revenues. Configured all servers ordered from manufacturing.

Accomplishments

• Responsible for all day to day service activities for a 13 million dollar company. Management of 4 team members. Directly responsible for customer satisfaction

• Implemented hard drive imaging system, decreasing both warranty costs and turnaround time

• Installed and configured SCO Unix reservation system for National Park service, Kings Canyon

• Designed, implemented inventory tracking database, reducing required stock on hand by $40,000

MILITARY

1996 – 2004 UNITED STATES MARINE CORPS RESERVE
Have held U.S. Government security clearance – Secret

EDUCATION

Ongoing professional education

Sans CISSP + Track

University of Oklahoma extension – Fire Science

Cisco Networking Academy

Similar Posts:

• What does it take to pass the CCIE exam?
• Cisco Certified Design Expert – CCDE – officially released by Cisco
• About Colin McNamara
• I’ll be at Cisco Live 2008 (networkers) in Orlando all week
• Where is Colin ? Passing the VCP exam (VMware Certified Professional)
• Challenges integrating VMware into Cisco networks

--Colin McNamara

Resume – Colin McNamara, CCIE #18233

* Solid State Drive (SSD) boot support
As initially discovered last month, VMware will make available a special version of ESX Server (mentioned with terms like ESX Lite and Embedded ESX) for OEM vendors, to be installed into bootable Solid State storage devices (flash drives, etc.). This option will allow creation of ESX Server hardware appliances for easy jumpstart, granting smaller form-factors and improved reliability.
Dell, IBM and possibly other vendors will offer this option at announcement time in Q3 2007.
* DMotion
Unofficially introduced with ESX Server 3.0.1, in its first version DMotion is a special VMotion operation only capable of moving running virtual machines from an ESX Server 2.5.x host to a new ESX Server 3.x., without shared SAN LUN mandatory requirement.
In ESX Server 3.1 this capability will be extended, allowing hot migration of running virtual machines between ESX 3.1 hosts through the Ethernet cable.
* Patch management system for host and virtual machines (Update Manager 1.0)
ESX Server 3.1 will finally introduce an automated patch management system called Update Manager. This solution will be able to update both host itself and virtual machines (both Microsoft Windows and Red Hat Enterprise Linux).
Update Manager will look for available updates from Shavlik Technologies website (a possible acquisition after IPO), and will allow VI administrators to decide which patches to deliver to virtual machines.
Before applying them, Update Manager will take a snapshot and will even rollback automatically if something goes wrong.

(this product was originally codenamed VM Integrity and its developement started more than one year ago, when virtualization.info discovered it in June 2006)
* VMware Consolidate Backup (VCB) and VMware Converter 4.0 integration
VirtualCenter 2.1 will now allow restoring VCB images with an integrated version of VMware Converter, which reaches 4.0 release number.
* Server consolidation advisor
VirtualCenter 2.1 will expose a server consolidation assistant able to analyze which physical machines should be converted in virtual ones, and where to move existing VMs among available hosts.
(note that with this feature VMware is further extending competition with PlateSpin, covering both features with PowerRecon and PowerConvert)
* Guest OS disaster recovery capability
VirtualCenter 2.1 will be able to recognize a failure inside a virtual machine and restart it through VMware HA module.
* Support for VMware Server 2.0
VirtualCenter 2.1 will be finally able to seamless manage both ESX Server and VMware Server 2.0 hosts.
* Lockdown Mode
ESX Server 3.1 will expose a new security feature to completely disable local administrative account after a VirtualCenter 2.1 takes remote control.
* Power saving capability (Distributed Power Management)
VirtualCenter 2.1 will introduce a new resources utilization analysis feature, able to verify when a physical host can be powered off, VMotion-ing its virtual machines on other hosts without impacting performances.
* Support for Cisco Discovery Protocol (CDP)
VirtualCenter 2.1 will be able to recognize and use CDP to discover physical and virtual network topologies.
It stays unconfirmed if ESX Server 3.1 will already expose new virtual network architecture, allowing 3rd party virtual switches, as it will be announced by Cisco CEO at VMworld 2007.
* Support for 10Gbit Ethernet network cards
* Support for TCP/IP Offload Engine (TOE) network cards
* Support for network load balancing algorithms
* Support for 200 hosts and 2000 virtual machines
* Support for 128GB RAM per host and for 64GB RAM per virtual machine
* Support for SATA storage devices
* Support for N_Port ID Virtualization (NPIV)
* Support for VCB over iSCSI SANs
* Support for IPv6 in virtual networking
* Support for Para-virtualization guest OSes

Copyright ©2008 | Colin McNamara | CCIE 18233 | All Rights Reserved”

Colin McNamara
CCIE #18233

http://www.2cups.com

“The difficult we do immediately, the impossible just takes a little longer.”Similar Posts:

• Cisco releases Nexus 1000V virtual switch for VMware
• Is your network ready for Cloud Computing with Virtual Infrastructure 4?
• Cisco EMC and VMware partneship VCE VBlocks Acadia and the Partner Ecosystem
• Cool new features in 12.2(33)SXH
• Cisco’s Unified Computing System – It’s not just a blade center
• Interesting TechWise TV episode on virtualization

--Colin McNamara

New features in VMware 3.1

For those who haven’t heard yet, I passed my CCIE Lab on June 14th. Now I can officially put CCIE #18233 after my name.

Anyone who has been down the same path understands how long of a road this is.
I started down this path in the spring of 1999 as the 432nd student ever in Cisco’s Networking Academy (which I promptly dropped out of to move to the bay area). I grew my networking skills all the way to passing my CCIE Written in 2001. I attempted my Route Switch lab in 2002, however I got called away to war for a year. Being away from it all for a year really cramped my style technically. In that time many of my certs expired, and I lost much of the momentum I had built of the past half decade.

Since I got back to the real world I had focused on work to the detriment of my certifications. I really did some great things, however I really neglected my resume.
In July of 2006 I had worked 2038 hours that year (for those not mathematically inclined, that is a full work year, in 1/2 a year) . At that point I decided it was time to stop neglecting my certifications. At that point I dedicated 8 hours each saturday, along with two nights a week to studies. By December of that year I had Certified on a few of the technologies that I had tons of experience in.

I managed to get my RHCE, Cisco Storage Support and Design Specialist, update my old IP Telephony specialist certifications to CCVP, get my Netapp Certified Administrator, and pass my CCIE Written for storage networking all by the end of the year. This spring I finished my Netapp Certified Expert and scheduled my Storage lab for early summer.

Anyone who knows me well knows how closely I track my time. That time tracking extends to my training. I tracked my training (reading, lab practice, testing, etc) just like any other part of my professional life. I spent around 150 hours studying for my Design, Support specialist certs, along with reading the recommended books of the CCIE reading list, and around 300 hours preparing for my lab exam. That is 300 hours configuring every possible combination and permutation of technology that could be setup, and then refining my speed in configuring those technologies until i got to the point where speed as well as brains would be an advantage in the lab.

So now that I have my CCIE, whats next? Well, oddly enough.. I am thinking of getting my second CCIE cert. In my office I will be the Jr guy by only having a single CCIE (on of our guys has all five). I also need to take my VMware certified professional cert, and probably get my HP Master Accredited Storage Engineer. I guess I am just a glutton for punishment.

Copyright ©2008 | Colin McNamara | CCIE 18233 | All Rights Reserved”Similar Posts:

• About Colin McNamara
• Updated CCIE numbers
• Why was Storage Networking my first CCIE? And What did I do to prepare?
• Resume – Colin McNamara, CCIE #18233
• And it begins again – On the road to my CCIE in Storage
• Update on the Cisco / Nuova connection

--Colin McNamara

What does it take to pass the CCIE exam?

Lets just start this out by saying, darn.. this is going to be expensive.
Now that that is out of the way, lets get started. Cisco publishes the hardware that is in the Storage lab.

Here is the hardware summary -

• Cisco Routers
• Cisco Catalyst Switches
• Cisco Secure Access Control System
• MDS 9506*
• MDS 9216*
• Port Analyzer Adapter
• JBOD
• RAID storage
• HBA
• 3rd Party Fibre Channel Switch

My guess is that this equals a basic routed network with a CS-ACS server on the backend.
It looks like there is also at least 1 pc with an HBA connected into one MDS. The one big question I have is on the connected storage.
My guess is that Cisco’s JBOD reference = Fibre Channel connected storage, and the RAID array mentioned is connected to at least one server.
If my guess is right then there is the 9506 and 9216 – (note, no I in the name) and a third party switch.

So lets start the shopping list.

1. Cisco Routers
I have those coming out of the yinyang, no need to purchase anymore for this lab.

2. Cisco Catalyst Switches
Mine are a little old, but I don’t expect a storage exam to have anything challenging in the switching arena. No need to upgrade there.

3. Cisco Secure Access Control System
Thankfully Cisco provides VAR’s with NFR binders. ACS will be loaded on HMB-SERVER1 in a vmware image. No expenditure needed.

4. MDS 9506*
Holy smokes, this is a lot of money. I have seen them on ebay for $8,000. This includes both sup modules. I would need to buy a line card, which I see going for about 1k. so $9000

5. MDS 9216
Still bad, but not horrible. I just saw one on ebay for $5500. Depending on lab requirements it may be smart just to get to 9216’s. so $5500

6. Port Analyzer Adapter
Best I can find is $2000 refurbished. I have a feeling practicing using this, and seeing the ethereal dumps is going to be integral to success. worst case this is 2k, best case beg or borrow $2000

7. JBOD
Normally you are looking at 2-4k for one of these. My strategy is to find an old Netapp shelf, and low level format it. I found one on ebay that ends in 22 hours for $89. Sounds good to me.

8. RAID storage
I am going with my guess that this is just to facilitate data transfers between storage and host. My tactic is to use the existing storage inside one of my servers. $0

9. HBA
Interesting – Only one HBA .This can be up to $2000 to buy new. Luckily ebay is my friend. I found a qlogic 2340 card for $50. My kind of deal

10. 3rd party Fibre Channel Switch
Luckily Brocade resells to everyone and their mother. IBM, Dell, HP, Compaq, ETC. I have found some Silkworm 2800’s for as low as $50 on ebay.
I do have my eye on a 3800 that is going for $24 right now (I hope it stays low).

So how much is the damage?

$16,700

Holy smokes I could sell my truck just to buy the lab gear.

–Colin
Copyright ©2008 | Colin McNamara | CCIE 18233 | All Rights Reserved”

Colin McNamara
CCIE #18233

http://www.2cups.com

“The difficult we do immediately, the impossible just takes a little longer.”Similar Posts:

• Update on the Cisco / Nuova connection
• Why was Storage Networking my first CCIE? And What did I do to prepare?
• Cisco Nexus 5020 and 5010 FCOE video ordering guide
• CCIE Party 2008 Recap – Cisco Live Networkers 2008
• Cisco Nexus 4000 Blade Switch
• Fibre Channel over Ethernet is taking off

--Colin McNamara

My CCIE Storage Shopping List

2. Update the Real Time System config generator

Existing Features-
Generates Content Switching configs from application data
Has a web interface for development access
Notifies help desk
New Features -
Create firewall definition files
Create nagios probe config
Integrate XML submission probe generation
Thoughts
Nice to have, but 90% of the functionality is already there

3. Update Nagios system config generator (nagiosuploader)

Existing Features-
Grabs system info when run locally
Posts configs to monitoring server for processing
New features
Host auditing to determine services monitored
Clean up error condition handling
Web interface for config generation
Thoughts
Having a web interface for users to fill out would lower my workload

4. Automate web application error reporting

Existing features -
None, well.. manually executed text processing on log files. I wouldn’t call that an application
New features -
Automation of customer / error code matrix grep statements
Output in XML / http format web page and email
Text only output in commented form <– text –> for command line mail clients
Thoughts -
Proves the point that certain people can be replaced by very small shell scripts (Unix humor)
Should be a big with with Client services
Could drive the application “digital dashboard”
Should be a fun to practice using AWK for formatting data in a standard output
Serious danger of scope creep
May be better implemented in a MySQL back-end

5. Do some personal growth items

Finish the Vmware image for the 7206 emulator and post to Vmware Technology Network for general use (delete IOS files before uploading)
Read some more of Long’s storage book
Write a sample chapter for Stay at Home Photography
Get GTK pod to run under my cmcnamar account, not root (I think the IPOD’s file system doesn’t like changing ownership or file attributes)
Redo the 2cups homepage
Clean the Garage……..
Copyright ©2008 | Colin McNamara | CCIE 18233 | All Rights Reserved”

Colin McNamara
CCIE #18233

http://www.2cups.com

“The difficult we do immediately, the impossible just takes a little longer.”Similar Posts:

• User experience testing – enhanced
• Google Translate API and speech recognition
• Usability features in Cisco’s Nexus 7000
• Why GoDaddy Linux Virtual Dedicated Hosting Sucks & How to Fix It
• RSS feeds – an intranet aggregation solution?
• Routers can email you when they go down

--Colin McNamara

What should I do this thanksgiving break?

Now this system work pretty good, except when we have to do usability testing. Its just not the same on a XP image, as it is from your laptop, on wireless, at home.. etc etc. So we decide we need some sort of VPN solution into our Exchange staging environment. After not alot of thought, I decide to set up a linux PPTP server. Its a protocol that pretty much everybody can use, pretty lightweight, and free .

I have set these boxes up before, and its not terribly hard. Until I had to do it on VMware. Let me set the stage for you – Redhat AS 3.3 / VMware Esx server / VMware tools installed / 1 nic . One NIC generally isn’t best for a VPN server, so I used Virtual Center to deploy a 2nd NIC to my PPTP box.
For anyone reasonably familiar with Redhat or Manadrake, we are used to installing well known hardware and seeing Kudzu add it on boot. Not this time. I rebooted, Kudzu came.. Kudzu went. I ran Kudzu manually no dice.

I know I know, auto anything never works… So I moved on to manually defining this network adapter. The first thing to check – is it actually plugged in. LSPCI reports the adapter as plugged in, and recognises it as a pcnet32 adapter. Normally I would take this as a positive sign, but not today. I issue IFCONFIG -a , network adapter is still not found. I was definately feeling a bit frustrated at this point. To be sure it wasn’t me, I bugged a friend and a co-worker (remind you of a game show?). Anson, who runs the VMware enviornment tried removing VMware tools, adding them…. still no dice. Shad tried to help through Yahoo, although to no avail.

By this time, I am frustrated, feeling like a moron, and ready for a break.
I went to get lunch from the Cafe, and settled down to eat at my desk.
Funny thing, how when you aren’t thinking about a problem is when you normally think of the solution. Let me give you a little background. Earlier when we were troubleshooting this problem, I googled this usenet post -
http://content.ix2.net/arc/t-4236.html . This fellow describes his headaches with debian, in which he had a very similar problem.

His problem, along with mine was that the proper modules werent loading for his network devices. He had tried, along with me to add the module listing to /etc/modules.conf. The one thing however that I hadn’t tried was manually loading pcnet32 using modprobe.

needless to say, modprobe pcnet32 now sits in my rc.local file. Its lame, but it works.

–Colin
Copyright ©2008 | Colin McNamara | CCIE 18233 | All Rights Reserved”

Colin McNamara
CCIE #18233

http://www.2cups.com

“The difficult we do immediately, the impossible just takes a little longer.”Similar Posts:

• New features in VMware 3.1
• Dragged to the hospital
• Nexus 5020 – Consolidated 10 Gig Ethernet and 4 Gig Fibre Channel
• Cisco releases Nexus 1000V virtual switch for VMware
• Challenges integrating VMware into Cisco networks
• My CCIE Storage Shopping List

--Colin McNamara

Redhat AS3.3 and VMware ESX network issues