Cisco Live 2013 in Orlando

30 Jun

Andrius |  June 30th,2013 | Cisco, Vblock |  No Comments »

So I had a great opportunity to visit Cisco Live 2013 in Orlando.
This was my first(I hope not last) to Cisco Live and I can say it was really impressive.
Everything was big and american style but that is not important. What is important is the things that you can get from this event.
Seeing new products, getting some hands on in the labs and meeting people in the show and talking to techies was really beneficial. The amount of sessions was just huge and I tried to attend as many as possible. This was intensive brain training for 4 days on steroids.
The amount of information that I was receiving each day was mind blowing and I had problems sleeping(probably jet lag also played here)
Here are some pictures:
20130624_114543

20130624_160716
Geeks gathering 🙂

20130625_140831
VCE booth

20130625_140911
Vblocks

20130626_161238
One of hundred sessions

Configuring NTP and Timezones on Cisco devices(UCS, MDS, Nexus, Catalyst) in Vblock

21 Jun

Andrius |  June 21st,2013 | Cisco, MDS, Nexus, UCS, Vblock |  1 Comment »

Cisco UCS

  1. Open UCS manager.
  2. Select Admin tab and change filter to Timezone Management
  3. Select your timezone and click on green + to add NTP server details
    1
  4. Enter IP address of your NTP server and click OK. You can add FQDN of the server but then make sure that DNS is configured in UCS Manager.
    2

Cisco Nexus 5000 and 7000

  1. Login using CLI to your Nexus switch
  2. To configure your timezone and NTP server details:
    conf t
    clock timezone UTC 0 0        <== Change your name of timezone from UTC. First 0 is for Hours offset and the second is for minutes offset
    ntp server 192.168.101.81 use-vrf management
  3. Verify that the configuration was set and packet are being received:sh ntp statistics peer ipaddr 192.168.101.81
    7
    sh clock

Cisco Nexus 1000v and MDS switchesLogin to CLI to your Nexus switch

  1. Login using CLI to your MDS or 1000v switch
  2. Configure timezone and NTP server details:
    conf t
    clock timezone UTC 0 0        <== Change your name of timezone from UTC. First 0 is for Hours offset and the second is for minutes offset
    ntp server 192.168.101.81
  3. Verify that the configuration was set and packet are being received:sh ntp statistics peer ipaddr 192.168.101.81
    5
    sh clock

Cisco Catalyst switches

  1. Login using CLI to your Catalyst switch
  2. Configure timezone and NTP server details:
    conf t
    clock timezone UTC 0 0        <== Change your name of timezone from UTC. First 0 is for Hours offset and the second is for minutes offset
    ntp server 192.168.101.81
  3. Verify that the configuration was set and packet are being received:
    sh ntp status
    4
    sh ntp associations detail
    6
    sh clock

Beware that it may take some time for clock to synchronize on all devices.
If you are using Microsoft Windows w32tm service for NTP then on your NTP server you need to change LocalClockDispersion to 0 seconds or Cisco devices will not sync.
To check the current setting:

  1. open command prompt on NTP server
  2. type:w32tm /query /status
    8
    By default Dispersion is set to 10 seconds. It cannot be more than 1 second for Cisco devices to sync
  3. Open registry and find the following key
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Config
  4. Change the value of LocalClockDispersion from a to 0
  5. Restart Windows Time service
  6. The devices should start syncing.

MDS: How to identify what is connected to MDS on the other side of the cable

21 Jun

Andrius |  June 21st,2013 | Cisco, MDS |  No Comments »

In ideal world each port configured on any device would have  description on it stating what it is connected to, but that it is not always the case and sometime the cables migh have been moved but descriptions left the same.
To identify what is at the other side of the cable of Cisco MDS switch you can run the following command:

show fcns database detail vsan <vsan id>
This will show all the ports for the vsan. Also you can put a range of vsans. Here are couple examples of the output.

------------------------
 VSAN:11 FCID:0x020001
 ------------------------
 port-wwn (vendor) :20:43:00:0d:ec:b4:dc:80 (Cisco)
 node-wwn :20:0b:00:0d:ec:b4:dc:81
 class :3
 node-ip-addr :192.168.104.32
 ipa :ff ff ff ff ff ff ff ff
 fc4-types:fc4_features :npv
 symbolic-port-name :fi6120-B:fc2/3   <== connected to UCS Fabric interconnect port fc2/3
 symbolic-node-name :fi6120-B
 port-type :N
 port-ip-addr :0.0.0.0
 fabric-port-wwn :20:0b:00:0d:ec:c2:62:c0
 hard-addr :0x000000
 permanent-port-wwn (vendor) :20:43:00:0d:ec:b4:dc:80 (Cisco)
 Connected Interface :fc1/11 <==MDS fc port
 Switch Name (IP address) :mds9509B (192.168.101.21)
------------------------
 VSAN:11 FCID:0x020006
 ------------------------
 port-wwn (vendor) :21:00:00:24:ff:32:bd:5f
 node-wwn :20:00:00:24:ff:32:bd:5f
 class :3
 node-ip-addr :0.0.0.0
 ipa :ff ff ff ff ff ff ff ff
 fc4-types:fc4_features :scsi-fcp:init
 symbolic-port-name :
 symbolic-node-name :QLE2462 FW:v5.06.02 DVR:v911.k1.1-19vmw  <== connected directly to Qlogic HBA that is running VMware drivers v911.k1.1-19vmw
 port-type :N
 port-ip-addr :0.0.0.0
 fabric-port-wwn :20:4d:00:0d:ec:c2:62:c0
 hard-addr :0x000000
 permanent-port-wwn (vendor) :21:00:00:24:ff:32:bd:5f
 Connected Interface :fc2/13 <==MDS fc port
 Switch Name (IP address) :mds9509B (192.168.101.21)
------------------------
 VSAN:11 FCID:0x02000b
 ------------------------
 port-wwn (vendor) :50:00:09:74:08:0e:79:5c (EMC)
 node-wwn :50:00:09:74:08:0e:78:00
 class :3
 node-ip-addr :0.0.0.0
 ipa :ff ff ff ff ff ff ff ff
 fc4-types:fc4_features :scsi-fcp:target 253
 symbolic-port-name :SYMMETRIX::000292600926::SAF- 8fA::FC::5876_159+::EMUL B80F0000 3F89624E 914B24 02.28.13 13:42 <==Connected to EMC VMax array(code level 5876_159) port 8fA  
 symbolic-node-name :SYMMETRIX::000292600926::FC::5876_159+
 port-type :N
 port-ip-addr :0.0.0.0
 fabric-port-wwn :20:42:00:0d:ec:c2:62:c0
 hard-addr :0x000000
 permanent-port-wwn (vendor) :50:00:09:74:08:0e:79:5c (EMC)
 Connected Interface :fc2/2  <==MDS fc port
 Switch Name (IP address) :mds9509B (192.168.101.21)

If you wan to look at specific port only then first you need to get FCID for this port:
show interface fc2/2

mds9509B# sh interface fc2/2
 fc2/2 is up
 Port description is Vmax_D9/F0
 Hardware is Fibre Channel, SFP is short wave laser w/o OFC (SN)
 Port WWN is 20:42:00:0d:ec:c2:62:c0
 Admin port mode is F, trunk mode is off
 snmp link state traps are enabled
 Port mode is F, FCID is 0x02000b <== FCID
 Port vsan is 11
 Speed is 4 Gbps
 Rate mode is shared
 Transmit B2B Credit is 20
 Receive B2B Credit is 16
 Receive data field Size is 2112
 Beacon is turned off
 5 minutes input rate 0 bits/sec, 0 bytes/sec, 0 frames/sec
 5 minutes output rate 0 bits/sec, 0 bytes/sec, 0 frames/sec
 77 frames input, 5008 bytes
 0 discards, 0 errors
 0 CRC, 0 unknown class
 0 too long, 0 too short
 61 frames output, 3828 bytes
 0 discards, 0 errors
 9 input OLS, 9 LRR, 0 NOS, 4 loop inits
 9 output OLS, 9 LRR, 8 NOS, 7 loop inits
 16 receive B2B credit remaining
 20 transmit B2B credit remaining
 20 low priority transmit B2B credit remaining
 Interface last changed at Wed May 1 19:10:57 2013

Now type:
sh fcns database fcid <fcid> detail vsan <vsan id>

This will give output for this specific port.

UCS: LDAP nested groups are not working with UCS Manager

19 Jun

Andrius |  June 19th,2013 | Cisco, UCS, Vblock |  1 Comment »

So you have your LDAP autentication configured in Cisco UCS manager.
You map group in UCS to LDAP group and add user to this LDAP group
2
Try to login with this user account to UCSM. Everything is working as expected.
You remove the user from LDAP group add it to another LDAP group and add this Group to LDAP group that is mapped to UCS group(in other words you nest groups).
1
When trying to login again, authentication fails.

This is a known behaviour of UCS and is explained in more detail under bug id CSCtt44185. With UCS, nested groups should not be used, each group in LDAP must be mapped to a group in UCS.

VMware: Cannot create Resource Pool, the option is greyed out

14 Jun

Andrius |  June 14th,2013 | Vblock, Virtualization, VMware |  No Comments »

OK this is a now brainer but still get asked sometimes.

In the vCenter you right click on Cluster and New Resource Pool option is grey out.
1

To create resource pool you need to have Distributed Resources Scheduler (DRS) enabled on the Cluster.

  1. Right Click on the Cluster and select Edit Settings…
  2. Tick Turn On vSphere DRS click OK.
    2
  3. Now you can create Resource Pools for this Cluster
    3

UCS: UCS Manager not accessible, (SWITCHOVER IN PROGRESS) (mgmt services state: INVALID) (HA NOT READY)

14 Jun

Andrius |  June 14th,2013 | Cisco, UCS, Vblock |  2 comments

UCSM is not accessible when login into UCS cli and running show cluster extended-state command you receive the following:

ucs01-B# show cluster extended-state
Cluster Id: 0xe123456789123456-0xac12345678987456

Start time: Mon Apr 8 00:00:16 2013
Last election time: Tue Apr 22 18:50:00 2013

B: UP, SUBORDINATE, (Management services: SWITCHOVER IN PROGRESS)
A: UP, PRIMARY, (Management services: SWITCHOVER IN PROGRESS)

B: memb state UP, lead state SUBORDINATE, mgmt services state: INVALID
A: memb state UP, lead state PRIMARY, mgmt services state: INVALID
heartbeat state PRIMARY_OK

INTERNAL NETWORK INTERFACES:
eth1, UP
eth2, UP

HA NOT READY
Management services: switchover in progress on local Fabric Interconnect
Detailed state of the device selected for HA storage:
Chassis 1, serial: FOX12345678, state: active
Chassis 2, serial: FOX12345678, state: active

As we can see from the error the switchover is in progress but management services are not running on any of the FI’s so switchover cannot complete and this is the reason why you cannot access UCS Manager.
The blades running on this UCS infrastructure are not affected and should be running fine.

To fix the problem you need to reboot both Fabric Interconnects, one Fabric Interconnect at a time.

  1. SSH to one of the Fabric Interconnects and type:
    connect local-mgmt
    reboot
  2. Wait until the fabric interconnect reboots it can take 20-30 minutes.
  3. Once it rebooted you should be able to open UCSM
  4. In UCSM verify that the fabric that was rebooted has fully came up
  5. SSH to the second Fabric Interconnect and reboot it
  6. After Fabric Interconnect is up, SSH to UCSM IP and run:
    show cluster extended-state
  7. Verify that the cluster is in good state.

UCS: How to change ring buffer size and queues for adapters in UCS

14 Jun

Andrius |  June 14th,2013 | Cisco, UCS, Vblock |  No Comments »

Here is the thing that you’ll probably never do but just in case you need to change ring buffer size you’ll know how to do this in Cisco UCS. 🙂
Before you make changes you should really know what and why you doing this as this is the last thing I would change as the default setting should work fine.

  1. Login to UCSM
  2. Select Servers tab an change Filter to Policies
  3. Expand Adapter Policies you should see all the default adapter policies for Fibre, Ethernet and iSCSI
    1
  4. Do not change these as they might be used by multiple servers. Create new policy.
  5. To create new policy right click on Adapter Policies and select the policy type Fibre, Ethernet or iSCSI
    2
  6. Enter policy Name and if you need you can also enter Description.
    Enter the required Queue and Ring Size values and click OK.
    3
  7. To apply the new policy to the adapter change the Filter to Service Profiles.
  8. Select service profile and the adapter the you want this policy to apply to.
    4
  9. On the right side change the Adapter Policy to a new one.
    5
  10. Click Save Changes

UCS: Renaming service profile in Cisco UCS 2.1

13 Jun

Andrius |  June 13th,2013 | Cisco, UCS, Vblock |  1 Comment »

Starting from UCS version 2.1 there is an option to rename service-profiles and templates in UCS. If you’re running 2.0 or lower then the only way to rename is to clone service profile make some changes and delete the original, you can read about this here.

Rename service profile in UCSM GUI

  1. Start UCSM and select Servers tab.
  2. Change filter to Service Profiles or All so that service profiles are visible
  3. Right click on the service profile you want to rename ans choose Rename Service Profile
    spr1
  4. Enter new name and click OK
    spr2
  5. You’ll get a dialog box that the profile was renamed. Click OK
    spr3

Rename service profile in CLI

  1. Use SSH client to connect to UCS CLI
  2. You have to know where the service profile you want to rename is located. In my case it is in the root. Type:
    scope org /
    ‘/’ is a location of service profile. If it is in sub-organization then you have to provide then name for it
  3. To select service profile type:
    scope service-profile name
    ‘name’ is a name of the service profile you selecting
  4. to rename type:
    rename-to newname
    ‘newname’ is the name you renaming profile to
  5. you will be asked to confirm. Type ‘yes’
  6. to commit changes type
    commit-buffer
    spr4

UCS: How to move or rename service profile in Cisco UCS

13 Jun

Andrius |  June 13th,2013 | Cisco, UCS, Vblock |  1 Comment »

So UCS version 2.1 has added feature to rename service profile but what to do if you are running 2.0 or if you need to move service profile to different sub-organization?
Here are the steps you need to perform.
Before performing rename/move you’ll need to schedule maintenance window as during the procedure the blade will go down.

  1. Open UCSM GUI and select Servers tab
  2. Change Filter to Service Profiles or All so that service profiles are visible
    From this point all actions are performed on the original service profile(the one you want to rename/move)
  3. Right click on the service profile you want to rename/move and select Create a Clone
    1
  4. Enter the new name that you want to rename service profile to or if you are moving then enter the same name and change organization. Click OK. A clone should be created.
    2

Read the rest of this entry »

Nexus: Upgrading Cisco Nexus 5000

06 Mar

Andrius |  March 6th,2013 | Cisco, Nexus, Vblock |  No Comments »

So here is how to upgrade Nexus 5000 series switch. In this instance I have 2 Nexus 5010 switches in vPC configuration as they are part of the Vblock. I will be upgrading them from 5.1(3)N1(1a) to 5.2(1)N1(1)
First of all, although upgrade procedure is pretty much the same, please always check with Cisco for latest upgrade guides:
http://www.cisco.com/en/US/products/ps9670/prod_installation_guides_list.html

For the upgrade to be done as quick as possible it is important to do some work before it, like downloading the files from Cisco, uploading them to switches and running checks.

  1. Download Kickstart and System files from Cisco.com
  2. Verify that you have enough space on the switch
    dir bootflash:
    030613_2025_NexusUpgrad1.png
  3. Upload both files to the switch. In this case I used TFTP server:
    copy tftp://x.x.x.x/kickstart_or_system.bin bootflash:            <=== replace x.x.x.x with TFTP server IP, kickstart_or_system.bin with your Kickstart or System file name.
    type management when asked to Enter vrf
    030613_2025_NexusUpgrad2.png
    Note: In Vblock upload files to both switches. Copy operation might take some time.
  4. Once both Kickstart and System files are uploaded verify that the file size of both files is correct.
    dir bootflash:
    030613_2025_NexusUpgrad3.png
  5. Now we need to run some pre upgrade checks which will show if there any problem that should be fixed before the upgrade can be started
    show compatibility system bootflash:system.bin            <=== replace system.bin with your System file name.
    You should get No incompatible configurations message
    030613_2025_NexusUpgrad4.png
  6. Next we to see the impact of the upgrade:
    show install all impact kickstart kickstart.bin system system.bin        <=== replace kickstart.bin and system.bin with your Kickstart and System file names.
    This procedure might look like a real upgrade but it only does all the checking
    030613_2025_NexusUpgrad5.png
    It will take some time to complete. It must succeed at all steps and should show that upgrade is non-disruptive
    030613_2025_NexusUpgrad6.png
  7. Now check spanning-tree impact. Everything should pass
    show spanning-tree issu-impact
    030613_2025_NexusUpgrad7.png
  8. Check lacp impact
    show lacp issue-impact
    030613_2025_NexusUpgrad8.png
  9. There is also show fex to verify that all fabric extenders are reachable but in the Vblock there are no extenders connected to the switches so this can be skipped.
  10. Once steps 1 – 9 are completed and all are OK you can proceed to upgrade.
  11. Because this is Vblock and 2 switches are in vPC config you need to identify the primary one as the upgrade should be started from primary
    show vpc role
    030613_2025_NexusUpgrad9.png
  12. Start upgrade
    install all kickstart kickstart.bin system system.bin        <=== replace kickstart.bin and system.bin with your Kickstart and System file names.
    030613_2025_NexusUpgrad10.png
  13. Once prompted verify to continue by pressing y
    030613_2025_NexusUpgrad11.png
  14. The upgrade will begin.
    If you connected to switch remotely over SSH, you will lose connectivity after seeing Saving supervisor runtime state
    message as the switch is rebooting. This should take about 5 minutes. Ping it to find out when it is back online.
    030613_2025_NexusUpgrad12.png
  15. Login to the switch and check upgrade status. If upgrade went ok you should see that it was successful.
    show install all status
    030613_2025_NexusUpgrad13.png
  16. Verify version
    show version
    030613_2025_NexusUpgrad14.png
  17. Verify that everything is working as expected.
    Upgrade is complete
  18. In Vblock once you’ve verified that primary switch is working fine, upgrade the secondary switch.
« Older Entries
Newer Entries »

IT Blog

Just another blog on Kozeniauskas.com Network