Showing posts with label cisco. Show all posts
Showing posts with label cisco. Show all posts

Wednesday, April 15, 2015

Still Undecided About Cisco Live? Take a Sneak Peek!

If you still aren't convinced to go to Cisco Live! this year in San Diego, perhaps a sneak peek at two of the courses will help.

BRKRST-2311P - IPv6 Planning, Deployment and Troubleshooting
(1 Hour)  Presented by Jim Bailey - Technical Leader, Cisco

April 21st
10:00am PDT / 12:00pm CDT/1:00pm EDT

This session covers IPv6 deployment and operational considerations. It begins with how network administrators can plan, design and implement an IPv6 solution, using a network readiness approach and holistic Network Architecture Strategy.

For more information and how to view the session, click here.

BRKRST-2311P - IPv6 Planning, Deployment and Troubleshooting
(1 Hour)  Presented by  Amanda Whaley - Cisco DevNet Developer Experience Lead and Community Manager, Cisco and Ashley Roach - API Architect, Cisco 

April 29th
10:00am PDT / 12:00pm CDT/1:00pm EDT

Are you new to coding ? This session will get you started using REST APIs and Python. We will cover coding basics and create some simple examples that retrieve, parse and display JSON data using the Cisco APIC-EM REST API’s.

For more information and how to view the session, click here.


Still not convinced???

If you register before June 5th, you can save $200 on registration.  It's going to be a great conference full of human networking as well as computer networking.  Here are some highlights:
Once you sign up, be sure to also sign up with the Official Unofficial Twitter List maintained by +Tom Hollingsworth aka @networkingnerd

Friday, February 13, 2015

It's Dirty Work, But Somebody's Gotta Do It

Network Engineers are known to have to work in dirty places like under desks, janitors closets (err I mean network closets), and those weird spaces in mechanical rooms in which someone decided to hide a switch or two.  Nothing though in networking compares with some of the jobs that this year's Cisco Live! keynote speaker has done.  He's cleaned poo, made snakes vomit and even greased the crawler for the US Space Shuttle.  

That's right, this year's keynote speaker is none other than the host of Dirty Jobs and Somebody's Gotta Do It, Mike Rowe!  If you haven't followed Mike recently, he's also started his own foundation Mike Rowe Works.  His goal is to bring back the notion that hard work can achieve greatness without the need for a formal higher education.  

His foundation is working to revitalize vocational training in the United States and train people for the over three million jobs that are open because of a lack of skilled labor.  Take Mike's S.W.E.A.T. Pledge today that Skill and Work Ethic Aren't Taboo.

Mike's speech should be humorous, yet poignant and very educational.  If you haven't already registered for Cisco Live!, what are you waiting for? I mean really, a week of awesome training, new and old friends, Mike Rowe and Aerosmith, can you really beat it?

Friday, February 6, 2015

Cisco Livin' On the Edge!

Cisco Live! is always a great week of training, networking and socializing, but this year is going to put us on the edge. The Customer Appreciation Event band is always one of the things most anticipated in the lead up to the event. This year Cisco has done a wonderful job of bringing us a band that has managed to span decades and still keep going. Without further adieu... the band this year will be ...



So if you haven't already registered for Cisco Live! do it this weekend and get a grip on early bird pricing before it expires!  It's going be a blast and you don't wanna miss a thing.

Wednesday, January 28, 2015

Cisco ONE, Panacea or Another Headache?

Cisco formally announced Cisco ONE today/yesterday at Cisco Live! Milan.  At face value Cisco ONE will allow customers to buy Cisco's software and related licenses separate from hardware.  It seems to me that this could be very beneficial to customers.

One major benefit that I see is that it would appear that licenses will be easily portable between old and new hardware.  This means no more purchasing a new set of ASA licenses just because you're upgrading from a 5512-X to a 5525-X for capacity.  All of the licenses will just move to the new box.  Same would apply to a wireless controller or even switches.  

The other major benefit that I see is that purchasing software might be easier.  One of the goals of this program is to simplify by not needing 100 part numbers just to get the right software for a device.

My only concern is that this could become a similar nightmare to maintaining Cisco SmartNet or Microsoft Enterprise Agreements.  Hopefully Cisco quickly provides tools to help with inventory and transitioning to both partners and customers.

Saturday, January 26, 2013

Cisco Live! 2013 Notable Keys to Know!

Cisco Live! is Cisco's annual customer conference.  I try to go as often as possible simply because it's the best training bang for the buck that I've found when it comes to Cisco's technologies.  Each day of the conference is started off with a keynote speech and this year Cisco is going with the following speakers.

First on Monday evening before the conference officially begins will be the Solutions Keynotes.  These keynotes will feature senior Cisco engineering experts speaking about the various product lines and their futures.  




Cisco Chief Executive Officer John Chambers
On Tuesday morning the conference officially begins with Cisco CEO John Chambers giving his annual keynote.  Mr. Chambers is always an engaging speaker and lays out where things have been and where they are going.  This year he will be joined with Cisco CTO Padmasree Warrior.  Traditionally Mr. Chambers' key note tends to be heavy with facts and figures in complicated power point slides, but what he says is generally inspiring and interesting in my opinion.  I'm hoping that this year will be less about pandering to the news media and stockholders and more about the customers which make up the majority of the audience.

Cisco Chief Technology Officer Padmasree Warrior
Padmasree usually gets the technology keynote on Tuesday so it will be interesting to see what she will be presenting this year.  She is definitely a visionary when it comes to looking at new technologies.  Unfortunately compared to the Cisco Chief Demonstration Officer Jim Grubb she comes across as rather boring at times.  I'm really hoping that a Jim Grubb demo with Mr. Chambers is still in the works for Monday.










Wednesday has often been my favorite of the Cisco given keynotes.  This keynote is generally the demo of some new technology or a way of integrating existing Cisco technologies in a particular vertical.  This is generally where any big announcements of new products are made.  This year Robert Lloyd, Cisco's President of Development and Sales, will be making his Cisco Live! keynote debut.  To be honest his name wasn't on my radar until I got the information on this keynote so I look forward to seeing what he's like as a speaker.  Especially with the blogosphere buzz about him being a potential successor to long time Cisco CEO John Chambers.

Ok, so finally here is the keynote that everyone is really wondering about.  The Thursday celebrity keynote.  In the past we have been graced by the likes of John Cleese, William Shatner, and last year the Mythbusters Jamie Hyneman and Adam Savage.  And this year the celebrity keynote speaker is...

Sir Richard Branson
Sir Richard Branson.  He is the founder and chairman of the Virgin Group which includes Virgin Records, Virgin Airlines, and my personal favorite Virgin Galactic.  Virgin Galactic competed in and won the Asari X-Prize to build a craft to ferry three people into space and be able to be returned to space again within 2 weeks.  I am expecting a very good keynote from Sir Richard.

Finally Carlos Dominguez will once again be the host leading us through the conference and the various keynotes.  He has a great stage presence to fire up the crowd every time he gets out there.  Last year I was lucky enough to meet him after one of the keynotes and found him as personable in person as he was on stage.  Keep an eye on his Facebook and Twitter posts as he'll probably be touring Orlando and giving away things prior to Cisco Live!

My Cisco Live! plans for this year are barely in shifting sands, but I'm really hoping to be there again.

Friday, January 25, 2013

$3,000 for Obsolete Paper!

My current project is to replace an older Comdial PBX with a Cisco CallManager Express.  The goal is to expand capacity and features for one of our busier doctor's offices.

When I started unpacking all of the boxes from Cisco I found that my CUCME phone licenses were shipped individually in the typical Cisco licensing cardboard envelope.  At that point my thought was, "crap that's a lot of PAKs to register".  The good news is that none of the envelopes contained PAKs, but the ones for the phones didn't even contain unique licenses.  The paperwork inside those envelopes was generic and included a phone guide for the 7940 and 7960 phones with CUCME 3.0.  Considering that I ordered CUCME 8.6 I would think that these envelopes have been sitting somewhere for a very very long time.

What really irks me about this is that these envelopes have nothing to prove that I purchased the licenses so I really just spent $3,000 on shipping paper from Cisco to me so that I can put it in the trash for them.  Perhaps it's inefficiencies like this that Cisco's leadership could eliminate to make their product pricing more palatable... or at least send me current documentation.

Tuesday, October 16, 2012

Neuron: Generating a CSR for Cisco ISE and Windows 2003 CA

If you have a Windows 2003 based Certificate Authority (CA) in your enterprise, you need to keep one thing in mind when generating a Certificate Signing Request (CSR) from Cisco ISE.  By default Cisco ISE uses SHA-256 for the CSR.  Windows 2003 only supports SHA-1.  So when you generate the request, make sure to select SHA-1.  This will save you countless headaches and hours of frustration.


Tuesday, August 14, 2012

Hello? ¿Hola? No, Bonjour!

Last fall I helped a local school district install a Cisco wireless network consisting of 1142n APs and a 5508 controller.  All was working well until recently when one of their techs received the district's first AppleTV.

Of course my first question was what VLAN(s) the AppleTV and the iOS device were connected.  That was the first problem which was easily fixed by placing them on the same VLAN.  The next problem is how Apple's devices find other devices on the same layer 2 network.  Apple uses Multicast DNS (mDNS), which they call Bonjour, to locate devices.  Every device on a subnet advertises its capabilities to the multicast address 224.0.0.251.  By default these advertisements are set to have a Time To Live (TTL) of 1 which prevents them from crossing routed boundaries even if multicast routing is configured on the network.

It was easy enough to put the AppleTV onto the same wireless VLAN as the user devices so we didn't have to come up with a solution for that.  To get the two devices talking is actually quite simple.  By default Cisco WLCs have multicast disabled.  This of course prevents Bonjour's discovery process from functioning.  Enabling multicast is done under the Controller tab of the WLC web page.  There are three options, disabled, unicast and multicast.

You might wonder how you can have unicast multicast, but it's not a contradiction in terms.  Because of the way traffic is tunneled from the APs to the controller, the multicast traffic is actually sent to the APs using CAPWAP unicast packets.  If you switch to multicast multicast mode and the switches are properly configured, the CAPWAP packets containing the wireless multicast traffic is only sent to APs that have joined the multicast CAPWAP group.  In a larger environment this can cut down on the amount of traffic sent as well as eliminate traffic going to APs that don't need the packets.

Most of the major networking vendors have released or are planning to release solutions to the problems Bonjour faces in the enterprise network.  In addition there have been petitions online to Apple  for them to make their products work better in enterprise networks.  Hopefully soon these challenges will be a thing of the past and Apple products will "just work" at home and in the office.

Friday, June 29, 2012

Case of the Missing Switch -- Solved

A month or so ago I posted a plea for help in reference to a strange problem I was having with a customer's switches.  The basic problem was that the network worked fine except that the management interfaces on the IDF switches could only be pinged or connected to from the MDF switch.

One of my astute readers, Eric Lund, hit the nail on the head with his comment:

Is ip default-gateway x.x.x.x set on the switch? It should be on the same segment as your management SVI.
This lead me to look again at the IDF configurations.  Sure enough the ip default-gateway was set to the default gateway of the old network.  We had been using the management ports on the switches to access and configure them from the old HP Procurve production network.  When I cut over, I forgot to change those default gateway statements.  Thankfully it didn't impact production, but it was one of those head scratchers when it came to managing the network.

Tuesday, June 5, 2012

Not your Father's CiscoWorks...

It's budget time and as such I've been playing with several demos of Cisco products trying to figure out what is worth fighting for and what isn't.  While budgeting for SmartNet renewals I discovered that my Wireless Control System (WCS) software was EoS next February.  WCS has been one of those applications that "just works", so I haven't really worried about replacing it before.

Knowing now that WCS needed replaced I went out to Cisco to figure out what the replacement was.  Cisco is migrating WCS customers to Cisco Prime Network Control System (Prime is their overall branding for all things network management).  The number one difference with NCS is that it has the ability to show both wired and wireless clients on the network in one tool.  For the most part the interface is the same as WCS, but it has been polished a bit with fancy new graphics.

The real surprise for me was that Cisco Prime NCS is bundled with Cisco Prime Lan Management Solution (LMS).  My first thought was that Cisco has had too much trouble selling CiscoWorks LMS so they just renamed it.  I have been pleasantly surprised.  Prime LMS is not your father's CiscoWorks.  The web interface is clean and for the most part easy to use like NCS or WCS.  Every so often you can see that the GUI designers ran back to the mothership as CiscoWorks-esque screens do still pop up in some areas.

Overall I've been impressed with both my demo of Cisco Prime NCS and Cisco Prime LMS.  My one complaint is the size of the VMWare appliance.  I have a relatively small network so I have chosen to use the "small" appliance version of both applications.  If I chose to thick provision both appliances, the combination would have been almost 512GB.  Now I realize that disk is "cheap" on laptops and such, but for Enterprise storage on a SAN, that's quite a chunk of change.  Surely for a network under 50 switches and 200 APs, the applications don't need that much space.  Maybe Cisco needs a ultra small tier too?

Friday, May 25, 2012

The Case of the Missing Switches

One of my clients had me setup a new Cisco network side by side with their existing HP ProCurve network last fall.  The two networks are linked by a gigabit Ethernet link and the Cisco core (4507R+E) is serving as the default gateway for all of the VLANs on the Cisco side and the one legacy VLAN on the HP ProCurve side.  Everything is working fine for normal network clients on the various VLANs.

Recently, the network administrator at the client site got time to connect to the switches to learn more about the config.  In doing so he discovered that the access layer switches (2960S) were not accessible from any device not on the same management VLAN as their management IPs.  The core switch which is on the same VLAN is accessible from any other VLAN.  Right now the only way to contact the access switches is to ssh from the core or to place a workstation on the management VLAN.

So far I have ruled out/checked out the following:


  • Duplicate IPs
  • Network Loops
  • The management VLAN is trunked properly across the 10Gbps uplinks to the access switches.
  • The management VLAN is in the core's routing table.
  • The access switches are listed in both the mac address table and the ARP table of the core switch.
  • The SVI for the management VLAN is UP/UP

I'm looking for ideas of where else to check for the cause of this behavior.  Thanks in advance for any help and I promise to post the solution when it comes.

Friday, March 30, 2012

Backup Your VLAN Database

A junior admin at XYZ corporation was tasked with adding a switch to the XYZ network.  He grabbed a spare switch out of stock that had been previously used.  After he plugged in the switch, most users were complaining that they couldn't connect to company resources over the network.  Your manager has tasked you with determining the cause of the problems and fixing them.

Sounds like a test question doesn't it?  Well unfortunately it happens often enough in real production networks.  A new switch is added with VTP server mode turned on and a higher revision number than the current VLAN database.  This can cause a totally bogus VLAN database to be propagated to the network via VTP if it is enabled on the production switches.  While there are plenty of ways to prevent this from happening, even the best network team can occasionally have a bad day.

Cisco's EEM provides a handy way of backing up your vlan.dat file so that you can quickly and relatively easily restore your VLAN database.

event manager session cli username "user" ! Determines the user that the script runs as.  If you use TACACS+ command authentication this is important.
event manager applet backup-vlan
 event timer cron cron-entry "0 23 * * *" maxrun 60000 ! Schedules the script to run at 23:00 every day.
 action 1 cli command "enable"
 action 2 cli command "configure terminal"
 action 3 cli command "file prompt quiet" ! Eliminates the "Are you sure?" prompts.
 action 4 cli command "end"
 action 5 cli command "copy const_nvram:/vlan.dat scp://user:password@FQDN/vlan.dat" ! Copies vlan.dat to a SCP server.
 action 6 cli command "configure terminal"
 action 7 cli command "no file prompt quiet" ! Restores the "Are you sure?" prompts.
 action 8 cli command "end"

Sunday, March 11, 2012

Automatic Recovery for Err-disabled Interfaces

There are four primary states for interfaces on Cisco switches: up, down, administratively disabled and err-disabled.  Up and down are fairly self explanatory.  Administratively disabled means that the port is configured to be shutdown by the administrator using the CLI.  Err-disabled though can be a bit baffling to a new network engineer.

The err-disabled interface state can be caused by many situations including:

  • Bad cabling
  • Duplex mismatch
  • BPDU guard violation
  • Port-Security violation
  • Link-flap detection
The complete list is on Cisco's site.

An engineer can recover an interface by entering configuration mode for the interface and issuing the shutdown and then no shutdown commands.  By default the interface will remain err-disabled until a human intervenes because auto recovery is disabled as is shown by the following show command.

SWITCH#show errdisable recovery
ErrDisable Reason            Timer Status
-----------------            --------------
arp-inspection               Disabled
bpduguard                    Disabled
channel-misconfig (STP)      Disabled
dhcp-rate-limit              Disabled
dtp-flap                     Disabled
gbic-invalid                 Disabled
inline-power                 Disabled
l2ptguard                    Disabled
link-flap                    Disabled
mac-limit                    Disabled
loopback                     Disabled
pagp-flap                    Disabled
port-mode-failure            Disabled
pppoe-ia-rate-limit          Disabled
psecure-violation            Disabled
security-violation           Disabled
sfp-config-mismatch          Disabled
small-frame                  Disabled
storm-control                Disabled
udld                         Disabled
vmps                         Disabled

Timer interval: 300 seconds

Interfaces that will be enabled at the next timeout:

 In some cases, it would be safe to allow the switch to auto recover the interface to up if the condition that caused the err-disabled state has cleared.  For this example, let's assume that a port-security violation caused the error (psecure-violation).  This is a relatively benign error to auto recover because if the violation still exists, port security will rapidly trip again putting the interface back into err-disabled.  The default is that the switch will clear the state after 5 minutes.  So to have the switch auto recover the interface the following configuration would need to be added.

SWITCH# configure terminal
SWITCH(conf)#errdisable recovery interval 300 ! Default setting shown for completeness.
SWITCH(conf)#errdisable recovery cause psecure-violation
SWITCH(conf)#end
SWITCH#copy running-config startup-config
 Similar commands can be entered for the other reasons listed above in the show command or you can set all reasons to recover by using the keyword all.  Be careful where you enable the auto recovery, it might not be your friend on all switches.  For example, you wouldn't want a link on a core switch having a problem to start flapping because of auto recovery causing a network convergence every 5 minutes (or whatever you set the timer to).

Tuesday, March 6, 2012

No Port for You! Using Cisco Port Security

Most Cisco switches support a feature known as Port Security.  Port security gives the network engineer the ability to have more granular control as to what device(s) can be plugged into a switch port.  There are a couple of usual use cases for Port Security.

Uses for Port Security

The first use case is to block unauthorized hubs, switches or access points from being used on the network.  In this scenario, Port Security is configured to allow a set number of MAC addresses to come from a certain port.  In most cases it would be set to two, one for the PC and one for the IP phone.  Any MAC addresses past the first two seen would either be denied access to the network or cause the port to be err-disabled (more on the violation modes later).  The allowed MAC addresses can either be statically assigned, dynamically learned, or dynamically learned and made permanent.

The other use case is to ensure that a secure piece of equipment like a credit card reader or biomedical device is the only device able to use the port.  In this case, the port is usually setup for a static MAC address.  Any other hosts are subject to the configured violation mode setup on the port.  If needed, more than one MAC address can be statically assigned to a single port.

Configuring Port Security


Now let's take a look at how Port Security is configured on a switch port.


SWITCH(config)# int Gi3/0/27
SWITCH(config-if)#switchport port-security
SWITCH(config-if)#switchport port-security mac-address 0000.aaaa.bbbb
SWITCH(config-if)#switchport port-security violation restrict
The first command after entering interface configuration turns Port Security on for the port.  Next, the MAC address to be allowed is configured.  Finally the last line sets the violation mode to protect.  There are three modes: protect, restrict and shutdown.
  • Protect - When a violation of the Port Security rules is detected, the port will drop all traffic to the violating MAC addresses and note the violation in the logs.  The port also stops learning MAC addresses even if the violation is only for a VLAN.  As such Cisco does not recommend this mode.
  • Restrict - When a violation of the Port Security rules is detected, the port will drop all traffic to the violating MAC address, note the violation in the logs, and send an SNMP trap. This is the recommended mode from Cisco versus Protect.
  • Shutdown - When a violation of the Port Security rules is detected, the port is put into err-disabled state until either the engineer clears the port or the timer expires if errdiable recovery is configured.
Sticky MAC Addresses

SWITCH(config)# int Gi3/0/27
SWITCH(config-if)#switchport port-security
SWITCH(config-if)#switchport port-security mac-address sticky
SWITCH(config-if)#switchport port-security violation restrict
This example is very similar to the first, but you will notice that instead of a MAC address, the keyword sticky is substituted. This configures the port such that the first MAC address it learns will become the secure MAC address for the port until changed by the network engineer.  All other MAC addresses learned will be considered in violation.  There is an implied default configuration of "switchport port-security maximum 1" in this configuration that limits the port to one mac address learned.  If you wanted to let the port have more than one sticky MAC address, enter the command "switchport port-security maximum <number>".

Aging MAC Addresses

Another twist on dynamically learned MAC addresses is to use aging to limit the number of devices on a port, but not necessarily restrict devices based on the MAC address.  In this configuration the port is set to limit the number of MAC addresses allowed, but as MAC addresses are no longer seen for a set type they are aged out allowing new MAC addresses to be added to the port without a violation.  The aging can either be absolute or based on inactivity.


SWITCH(config)# int Gi3/0/27
SWITCH(config-if)#switchport port-security
SWITCH(config-if)#switchport port-security aging time 480 type absolute
SWITCH(config-if)#switchport port-security violation restrict
In the above example, the port is set to age out a MAC address after 480 minutes go by regardless of activity.

SWITCH(config)# int Gi3/0/27
SWITCH(config-if)#switchport port-security
SWITCH(config-if)#switchport port-security aging time 10 type inactivity
SWITCH(config-if)#switchport port-security violation restrict
This example shows the configuration to have the MAC address aged out 10 minutes after the last activity.

Wrap Up


While Port Security is a very powerful tool, I have not seen it as widely deployed as one would think.  I think part of that is lack of awareness and the other part is fear of taking down a production port automatically.  With the right planning and knowledge, both can be overcome. I really suggest people consider adding Port Security to their port activation templates.  Even if it is just to stop unauthorized hubs, switches and access points, there is definite benefit.

Wednesday, January 11, 2012

Neuron: Cisco Switch Firmware Archive Command

First I should introduce this type of post.  For this blog, a neuron will be a short tidbit of information.

Anyone that has upgraded a Cisco switch in the last few years knows that they are usually distributed as a tar archive now.  To install the upgrade you do the following:

#archive download-sw tftp://tftpserver/upgradefile.tar
When you execute the command IOS downloads the file and extracts it onto the flash file system.  All you have to do after that is reboot.

Thanks to Cisco's latest grab for more money, if you don't have SmartNet on a piece of equipment, you can't download IOS code for it.  While this has long been their policy, it is now being enforced.  This isn't too much of a problem unless you have a device that dies and you want to replace it with a replacement that is also not under SmartNet.  The likelihood of the replacement switch coming in with the exact same IOS load is close to nil.  Most admins like to maintain certain revision levels on a certain model which poses the problem of how to get the IOS you want on the replacement.  Well the easiest way that I have found is to use Cisco's archive command again.  Keep in mind that it's best to do this BEFORE you have a switch crash.

#archive upload-sw tftp://tftpserver/firmwarefile.tar
When you execute this command, IOS will combine all of the files on the flash file system related to the IOS code into an tar archive and upload it to your TFTP server.  The resulting tar file can then be used like the stock Cisco firmware tar file.

Monday, August 29, 2011

Cisco Nexus 1000v Roundup

This post is merely an index for the 6 post series I did on the Cisco Nexus 1000v.  I hope that beyond being a good learning experience for myself that it will benefit others. 

Cisco Nexus 1000v - Adding Physical Ports (Part 6)

The previous posts have established a fully configured, but unused Nexus 1000v.  At this point it's like having a physical switch in the rack, powered up and configured, but with no network cables attached.  In VMWare, the "cables" are attached using the vSphere Client.


Attaching Physical Ports to the Nexus 1000v



  1. Connect to vCenter using the vSphere Client
  2. Go to Networking Inventory and select the Nexus distributed virtual switch (dVS).
  3. Right click on the Nexus and choose add host.
  4. Select the host and vmnic(s) to use and change their DVUplink port group to system-uplink (or what you named the system uplinks in your port group on the Nexus) for the system uplink ports and vm-uplink for the VM networking ports.
  5. Click next and choose not to migrate the vmk0 or VMs. (I prefer to verify the Nexus 1000v's operation before migrating anything.)
  6. Click Finish.
  7. Repeat for all hosts in the cluster.
Migrating vmk0 Interfaces to Nexus

Once you have added a few test VMs to the Nexus and are certain that the Nexus 1000v is working properly, it's time to migrate the last physical NIC from the vSwitch to the Nexus 1000v and with it the vmk0 interface used for vMotion and VMWare host management.  Keep in mind that if you don't need this NIC for bandwidth reasons, it is not mandatory to move these services to the Nexus 1000v.
  1. Connect to vCenter using the vSphere Client.
  2. Go to Networking Inventory and select the Nexus dVS.
  3. Right click on the Nexus and choose manage host.
  4. Select the hosts and click next twice.
  5. Click on the destination port group for the vmnic used by vmk0 and choose the Nexus port group.
  6. Click next and then finish without migrating VMs.
You will need to repeat this for each host in the cluster.  Leave the host with the active VSM for last and make sure to migrate it's NICs to the Nexus before disconnecting the vSwitch from the vmnic.  

Friday, August 26, 2011

Cisco Nexus 1000v Software Installation (Part 5)

In this article I will run through installing the Virtual Ethernet Module (VEM) and creating the initial port groups on the Nexus 1000v.

Installing the Virtual Ethernet Module (VEM)

  1. Open the vSphere client and connect to vCenter.
  2. Right click on the host that you are going to install the VEM on and choose Maintenance Mode. (NOTE:  This will vMotion all guests from that host to other hosts if you have vMotion enabled, otherwise those guests will be shutdown.)
  3. Copy the VEM bundle from the Nexus 1000v install zip file to the vMA or to the computer that you are running vCLI on.
  4. Use the vCLI to install the VEM with the following command: vihostupdate -install -bundle <path to VEM Bundle> --server <host IP>
As you can see, installing the VEM software is fairly simple.

Creating the Port Groups on the Nexus 1000v

The Nexus 1000v uses port-profile configurations to define the configuration for each type of interface.  In this part of the install we need to setup profiles for the physical NICs that will uplink to the hardware switch infrastructure for both the system VLANs like VMK0 and the Nexus Control traffic as well as the VM uplinks for normal guest VLAN traffic.  On the Nexus 1000v, physical NICs are all of type Ethernet and virtual NICs are vEthernet.

  1. Connect to the switch management IP address using SSH.
  2. Type config t and enter to enter configuration mode.
  3. Configure a port profile to use for your system uplink ports (VMK0, Nexus Control, Nexus Packet, Nexus Management).  Below is an example:

    port-profile type ethernet vm-uplink
      vmware port-group
      switchport mode trunk
    ! In my lab, 255 is MGMT, 256 is Nexus Packet and Control and 101 is for VMK0
      switchport trunk allowed vlan 101, 255-256
      switchport trunk native vlan 255
    ! This command has Nexus create port-channels automatically
      channel-group auto mode on
      no shutdown
    ! System VLANs come up before the VSM is fully initialized
      system vlan 101,255-256
      description SYSTEM-UPLINK
      state enabled
    
  4. Configure a port profile to use for the VM Guest networks.

    port-profile type ethernet vm-uplink
      vmware port-group
      switchport mode trunk
      switchport trunk allowed vlan 2,102,104-105,259
      switchport trunk native vlan 102
    ! This command has Nexus create port-channels automatically
      channel-group auto mode on
      no shutdown
    ! System VLANs come up before the VSM is fully initialized.
      system vlan 102
      description VM-UPLINK
      state enabled 
  5. Configure port profiles for the guest networking to match the old vSwitch port-groups.

    port-profile type vethernet example-vlan
      vmware port-group example-vlan
      switchport access vlan 
      switchport mode access
      no shutdown
      state enabled
     
  6. Save the new configuration by doing copy running-config startup-config

Now that we have everything configured, the next post will be how to plug the network into the Nexus 1000v.

Cisco Nexus 1000v Software Installation (Part 4)

In the last post, I configured the VMWare stock vSwitch to allow us to start the Nexus 1000v install.  I forgot to mention one thing that I usually do (it's not required) to help with mapping physical ports.  The VMWare vSwitch supports CDP, but is usually set to listen only.  To change it so that it will send out CDP packets you need to do the following:
  1. Using the VMWare vCLI either from a desktop of the vMA appliance run the following command: vicfg-vswitch -server <servername> -B both vSwitch0
  2. Repeate for all of the ESX Hosts in the cluser.
The next step in the Nexus 1000v installation is to install the Virtual Supervisor Module (VSM)  VM appliance(s).

Deploying the Virtual Supervisor Module (VSM)


  1. Download and decompress the Nexus 1000v software from Cisco.
  2. Open up the vSphere Client and connect to vCenter.
  3. Go to File and then Deploy OVF Template.
  4. Select the OVF file under the Nexus 1000v VSM install folder.
  5. Accept the details and the EULA.
  6. Give the VSM a name and choose next.
  7. Choose the ESX data store for the VSM and choose next.
  8. Choose thick provisioned and click next. (NOTE: Thin provisioning is not supported by Cisco for the VSM.)
  9. Map the virtual NICs to the appropriate port groups on the vSwitch.
  10. Power up the VSM and connect to its console using vSphere client.
  11. Once booted, go through the text based administrative setup to configure the following:
    • Administrative user password
    • Role (Standalone/primary/standby)  The first VSM will be primary unless it is to be the only VSM and then it would be standalone.
    • Domain ID.  This number serves to tie VSMs to a VEM and to vCenter.  Each Nexus 1000v instance must have a unique domain ID.
  12. Continue with the basic system configuration including:
    • SNMP Read-Only community string
    • Naming the switch
    • Assigning the management IP address settings
    • Enabling or disabling services.  NOTE: Make sure http and ssh are enabled as they are used later in the process.
  13. Open up a web browser to http://<nexus1000vIPaddress/ and click on "Launch Installer Application" (Requires Java Web Start and doesn't seem to currently work with Chrome).
  14. Give the wizard the credentials for the VSM that you created earlier.
  15. Give the wizard the credentials for accessing vCenter and the vCenter IP Address.
  16. Select the cluster where the VSM is installed.
  17. Assign the proper VLANs to the VSM's virtual NICs by choosing advanced L2 and then chose the proper port groups.
  18. Configure settings for the VSM.
  19. Review the configuration.
  20. Tell the wizard not to migrate any hosts or VMs and let it finish.  It will reboot the VSM multiple times before reporting that it is done.

Friday, August 19, 2011

Cisco Nexus 1000v Software Installation (Part 3)

In this article I will examine the process of configuring the default VMWare vSwitch with the VLANs needed to start the Nexus 1000v Install.


Assumptions: 
·         ESX is already installed
·         vCenter VM is already installed and configured
·         vSphere Client is installed on workstation
·         VLANs for Nexus Packet and Capture interfaces (can be the same VLAN) are created on the network.
·         VLAN for Nexus Management interface is created on the network.
·         The ESXi hosts have their ports configured as trunks with the Nexus Packet, Capture and Management VLANs allowed as well as the VLAN used for the ESX hosts’ IP addresses (VMK0).

The first steps to getting a Nexus 1000v installed are actually to get the basic VMWare vSwitch configured and operating.



Configuring ESXi vSwitch

  1. Open vSphere Client and connect to vCenter.
  2. Click on the host to configure.
  3. Click on the configuration tab.
  4. Click on networking. 
  5. Click on properties.
  6. Click on add.
  7. Click on Virtual Machine and then Next 
  8. Give the network a label and a VLAN ID (0 indicates the native vlan).  NOTE:  This label must be consistent on all hosts for vMotion.
Click finish to complete the process and repeat this on all of the hosts in the cluster being sure to make the network labels identical (case sensitive).  You will need to repeat this for every VLAN that you will need for the Nexus install including the Nexus Packet, Nexus Control and Management VLANs.