Cisco
Cisco Nexus 1000V Upgrade to 4.2(1)SV1(4)
0I just recently completed an upgrade of our Cisco Nexus 1000V from 4.0(4)SV1(3) to 4.2(1)SV1(4). Prior to proceeding with the Cisco Nexus 1000V upgrade we had to first upgrade vCenter to 4.1, Update Manager to 4.1 Update 1 and lastly the VMware ESX hosts themselves to 4.1. With all that complete we set out to upgrade the Cisco Nexus 1000V but quickly ran into a few problems.
Pre-Upgrade Script
The Pre-Upgrade Script, a TCL script which checks your Cisco Nexus 1000V configuration for any potential issues, immediately flag our Port Channel configurations in Check 2.
############################################################################### ## COMPANY NAME: Cisco Systems Inc ## ## Copyright © 2011 Cisco Systems, Inc. All rights Reserved. ## ## ## ## SCRIPT NAME: pre-upgrade-check-4.2(1)SV1(4).tcl ## ## VERSION: 1.0 ## ## DESCRIPTION: This script is applicable to all releases prior to ## ## 4.2(1)SV1(4). ## ## ## ... ... ... ========= CHECK 2: ========= Checking for Interface override configurations on Port-channnel Interface ... ############################################################################### ## FAIL ## ## ## ## List of Port-Channel Interface(s) with interface level configuration(s) ## 1: port-channel1 has below overrides. mtu 9000 2: port-channel2 has below overrides. mtu 9000 3: port-channel3 has below overrides. mtu 9000 4: port-channel4 has below overrides. mtu 9000 ... ... ...
While originally testing the Cisco Nexus 1000V prior to going into production some 463 days earlier we had played around with enabling Jumbo Frame support within the VM environment. We had set the MTU on the individual port-channel configurations to 9000. Now the pre-upgrade script was telling us that we needed to clean this up and remove any specific configuration from the port-channel and instead apply it to the port-profile configuration. I added the system mtu 9000 command to the port-profile but got a few surprises when I tried to remove the MTU command. The first surprise when I issued the “inter po1, no mtu 9000″ was loosing connectivity to the VM guests on that host. I had to manually restart the VEM on the ESX host with the “vem restart” command from an CLI prompt. The second surprise was that “mtu 9000″ in the configuration had been replaced by “mtu 1500″. That wasn’t going to work so I had to reach out to Cisco TAC who immediately recognized the issue and provided a workaround;
On the ESX host stop the VEM
vem stop
Then on the Cisco Nexus 1000V delete the port-channels and associated VEM (I’ll use the first server as an example assuming there are two VSMs installed)
config no inter po1 no inter po2 no vem 3
On the ESX host start the VEM
vem start
And sure enough it worked just as promised… recreating the port-channels without the MTU commands. Obviously we had to put each ESX host into maintenance mode before we could just stop and start the VEM.
With that taken care of we started upgrading the VEMs using Update Manager. Unfortunately Update Manager only made it through about 6 ESX hosts before it got stuck. We had to manually install the update VIB on the remaining 12 ESX hosts ourselves. We utilized FileZilla to copy the VIB up to each server and the utilized PuTTY to SSH into each server and manually update the VEM;
[root@esx-srv1-dc1-pa ~]# esxupdate -b ./cross_cisco-vem-v130-4.2.1.1.4.0.0-2.0.1.vib update Unpacking cross_cisco-vem-v130-esx_4.2.1.1.. ############################################################# [100%] Installing cisco-vem-v130-esx ############################################################# [100%] Running [rpm -e cisco-vem-v120-esx]... ok. Running [/usr/sbin/vmkmod-install.sh]... ok.
With all the ESX hosts upgrade we had to physically reboot the vCenter server to get the currently running VUM task to fail so we could complete the upgrade from the Cisco Nexus 1000V.
Next we launched the upgrade application and before long we had the standby VSM upgraded to 4.2(1)SV1(4). Here’s where we ran into another small scare. After the upgrade of the standby VSM the upgraded VEMs are supposed to re-register to the newly upgraded VSM. We waited about 5 minutes an none of the VEMs had discnonected from the primary VSM running 4.0(4)SV1(3) to the standby VSM that was now running 4.2(1)SV1(4). It was only approximately 15-20 minutes later (while searching Google for some hint) that the VEMs just up and started to connect to the newly upgraded standby VSM.
Cheers!
GNS3 – testing configurations without the hardware
10I have an upcoming configuration change that involves a fairly complex BGP implementation. I’ll be setting up BGP between two Avaya ERS 8600s, two Cisco Nexus 7010s and two Cisco 3845 routers. A few months back I started looking at setting up a few physical routers in the lab to work through the actual Cisco configuration. That’s when I stumbled upon GNS3, Dynamips, Dynagen and Qemu.
Needless to say I never made it to the lab. I did have a few issues getting GNS3 going but those could probably be attributed to PICNIC (problem in chair not in computer). I also had some difficulties getting GNS3 to save all the router configurations, again probably a shortcoming of not reading all the documentation.

I’m
really impressed… while it can’t emulate any of the switches it does a great job of emulating the basic router hardware. The image you use in GNS3 is the actual IOS image that you download from Cisco’s website.
I’ll definitely be adding GNS3 to my list of recommended tools!
Cheers!
Cisco Aironet 1200 Series WPA2 Enterprise with AES Encryption
2
I was looking for something to blog about and @fryguy_pa posted about his difficulties with the Cisco Aironet 1200 series and configuring them for WPA2. I had the pleasure of recently reconfiguring 70+ Cisco Aironet 1200 series, mostly AIR-AP1231G-A-K9 running the latest software 12.3(8)JEC, in an effort to deploy a new WLAN with 802.1x WPA2 Enterprise utilizing AES encryption. It took myself and another engineer a few days to come up with a working configuration.
You’ll notice in the example below that I’m using two RADIUS servers, actually two Microsoft Internet Authentication Servers running Windows 2003. I created a SSID (or WLAN) of “love” and bridged it to VLAN 802. I had to utilize bridge group 254 because the bridge groups only go from 1-255. I also only configured the WLAN on the 802.11b/g radio (Dott11Radio0) and not the 802.11a radio (Dott11Radio1). I also utilized a RADIUS secret of “radiuspass” in the example below.
aaa group server radius acme_eap server 10.1.4.21 auth-port 1812 acct-port 1813 server 10.2.4.21 auth-port 1812 acct-port 1813 aaa authentication login acme_methods group acme_eap dot11 ssid love vlan 802 authentication open eap acme_methods authentication network-eap acme_methods authentication key-management wpa interface Dot11Radio0 ssid love encryption vlan 802 mode ciphers aes-ccm interface Dot11Radio0.802 encapsulation dot1Q 802 no ip route-cache bridge-group 254 bridge-group 254 subscriber-loop-control bridge-group 254 block-unknown-source no bridge-group 254 source-learning no bridge-group 254 unicast-flooding bridge-group 254 spanning-disabled interface FastEthernet0.802 encapsulation dot1Q 802 no ip route-cache bridge-group 254 no bridge-group 254 source-learning bridge-group 254 spanning-disabled interface Dot11Radio0 ssid love encryption vlan 802 mode ciphers aes-ccm radius-server host 10.1.4.21 auth-port 1812 acct-port 1813 key radiuspass radius-server host 10.2.4.21 auth-port 1812 acct-port 1813 key radiuspass radius-server deadtime 5
If you need to debug the AAA or RADIUS process here are the commands that can help provide additional detail from the Access Point. It should be noted that some of the commands below are software and version dependent and might throw you an error.
debug dot11 aaa manager keys debug dot11 aaa authenticator state-machine debug dot11 aaa dot1x state-machine debug dot11 aaa authenticator process debug dot11 aaa dot1x process debug radius authentication terminal monitor
While this example won’t translate directly for @fryguy_pa it might help others trying to deploy 802.1x WPA2 Enterprise with AES encryption in an enterprise network.
Cheers!

