August 10th, 2009
This is a follow-up to my previous post regarding the Nexus 1000v. Now that I help set the stage for what the Nexus 1000v really is, we can start looking at what is needed to get one up and running.
The Cisco install guide for the Nexus 1000v is a great reference, and I’ll help clarify and fill in the gaps the best I can. I won’t regurgitate too much of the steps in the install guide, so you will want to use the install guide for sure.
First let’s talk about the prerequisites ::
vCenter Server — In most cases, we have a data center of some sort with multiple ESX hosts running. Each ESX host has its own Virtual Machines running. So within our data center, it’s a good idea to define a cluster –or grouping of ESX hosts. It’s beneficial to group our ESX servers in a cluster because we can take advantage of some of the bells and whistles with VMware such as vMotion and high availability. vMotion is cool because if we need to take a server down for maintenance, we can drag and drop the VM to another ESX host. vMotion can also be a dynamic process if there is a unforeseen ESX server failure. So we define our data center, put our ESX servers in one or more clusters and have our VM’s running on each ESX server. The hierarchical structure is one of the benefits of vCenter because we now can centrally manage all of our ESX hosts from a single view. Instead of using the vSphere client to connect to each ESX server separately, we connect our vSphere client to the vCenter server which allows us to manage a whole data center of ESX hosts and their associated VM’s. Most importantly, we must be running vCenter server because that’s what the Nexus VSM communicates with directly.
Read the rest of this entry »
August 4th, 2009
I noticed that Cisco has been advertising free evaluations of the Nexus 1000v on their website.
I decided I would give it a go and share my experiences and thoughts. Now I’m by no means an ESX expert, but I have recently started playing more and more with it. I have always been partial to regular VMware Workstation myself.
I’m not going to go into too much detail here, but I wanted to give some background to add some context to the Nexus 1000v.
VMware has come out with this new Distributed Virtual Switching (DVS) term and Cisco has basically latched on with the introduction of the 1000v (as can other 3rd parties). Historically, we are used to using the integrated VMware virtual switch (vswitch) within the hypervisor in our ESX servers. You can basically think of the Nexus 1000v as a way of doing-away with the VMware vswitch and putting a Cisco virtual switch in its place.
So why replace a VMware switch with a Cisco switch? Let’s think about where we typically draw the imaginary line in ownership between our Server and Network teams. If I have an ESX hypervisor hosting 5 different virtual machines, they get connected internally with the vmware soft switch (vswitch). As a server admin, I have to create my port groups (or profiles) and assign them manually to each VM. I could use this to put each VM in its own VLAN for example. So the server guy is definitely forced to know a little bit about networking because he now has to manage the vswitch. As a network guy, I handle the port connecting to the physical ESX host. That’s going to be the “demarc” for me, as that’s pretty standard for how far my responsibility traditionally goes. If the server guy thinks there’s a problem with connectivity, I’ll verify all the way up to the port that connects to the server. At that point, I’ve verified everything on my end. Things are starting to change with virtualization…
Read the rest of this entry »
July 28th, 2009
Now that the CCIE version 3 blueprint is being tested on, I have started working on my second CCIE in Voice. While the new blueprint is focused on CUCM version 7, it turns out this book adds value even if it’s based on version 6.
Read the rest of this entry »
June 24th, 2009
I was looking around in my Nexus boxes today and noticed that my 48 port Rj45 line card was not showing up in the running config. The “show mod” showed it as “ok” but the interfaces were missing from the config. The model number is ‘N7K-M148GT-11’ and you need to have hardware version 1.3. This seems to be a side effect of enabling virtual port channels on the Nexus boxes.
Turns out there is a field notice and I need the latest hardware version of the cards.
Open a TAC SR and get an RMA going. I figured it would be an EPLD upgrade issue, but I guess not.
Notice the version in the output from “show mod”
nexus7000# sho mod
Mod Ports Module-Type Model Status
— —– ——————————– —————— ————
1 32 10 Gbps Ethernet Module N7K-M132XP-12 ok
2 32 10 Gbps Ethernet Module N7K-M132XP-12 ok
3 32 10 Gbps Ethernet Module N7K-M132XP-12 ok
4 48 10/100/1000 Mbps Ethernet Module N7K-M148GT-11 ok
5 0 Supervisor module-1X N7K-SUP1 active *
Mod Sw Hw
— ————– ——
1 4.1(5) 1.3
2 4.1(5) 1.3
3 4.1(5) 1.3
4 4.1(5) 1.0
5 4.1(5) 1.1
May 5th, 2009
Looks like there are some changes with the Lab exam (and written).
Beginning October 18, 2009, the CCIE R&S lab exam will feature a two-hour troubleshooting section. Candidates will be presented with a series of trouble tickets for preconfigured networks and need to diagnose and resolve the network fault or faults. As with the configuration section, the network must be up and running for a candidate to receive credit. Candidates who finish the troubleshooting section early may proceed on to the configuration section, but they will not be allowed to go back to troubleshooting since their equipment will need to be reinitialized for the configuration portion.
As far as the exam topics go, it seems there are some additions ::
– Performance routing (pfr)
– MPLS VPNs
– Optimization (Netflow, EEM)
I think this is all good stuff personally. MPLS VPNs are not really that hard. I have done some articles with config examples on this site for MPLS VPNs. They are quite fun.
The troubleshooting addition is going to be interesting it seems.
Performance routing (pfr) configurations can get really nasty and complex, but other than that not too much to worry about.