Category Archives: Cisco Nexus

Study about nexus devices.

Cisco Nexus Product Family

Cisco Nexus product family is a key component of the Cisco unified data center architecture, which is the unified fabric. The objective of the unified fabric is to build highly available, highly secure network fabrics.

Using Nexus the Cisco Nexus product, you can build end-to-end data center design based on three-tier architecture e or based on spine-leaf architecture. Cisco Nexus Pruduct line offers high-density 10G, 40G, and 100G ports as well.

Modern data center designs need the following properties.
1. Effective use of available bandwidth in design where multiple links exist between the source and destination and one path is active and the other is blocked by STP, or the design is limiting you to use Active/Standby NIC teaming.

This addressed today using layer 2 multi-pathing technologies such as fabric and virtual port channel(vPC).

2. Computing resources must be optimized, which happens by building a computing fabric and dealing with CPU and memory as resources that are utilized when needed.

3. Using the concept of a service profile and booting from a SAN in the Cisco Unified Computing system will reduce the time to instantiate new servers. This makes it easy to build and tear down test and development environments.

4. Power and cooling are key problems in data center today. Ways to address the include using Unified fabric (converged SAN and LAN), Using cisco virtual interface cards, using technologies such as VM-FEX and Adapter-Fex. Rather that using, for example 10G links, you can use two 40G links, and so on. reducing cabling creates efficient airflow, which in turn reduces cooling requirements.

5. The concept of hybrid clouds can benefit your organization. Hybrid clouds extend your existing data center to public clouds as needed, with consistent network and security.

6. Improved reliability during software updates, configuration changes, or adding components to the data center environment, which should happen with minimum disruption.

7. Host, especially virtual host, must move without the need to change the topology or require an address change.

Nexus N5k & N2k Upgrade

Nexus 5k and N2k fabric extender

Current Version: 6.1(2)
Target Version: 6.2(14)

Multistep:
Multihomed vs Singlehomed upgrade

Procedure:

  1. Connect to physical device via console cable.
  2. Pre-installation test
  3. Follow MOP of Dimension Data.
  4. Once all the requirement, image etc. are ready you can proceed to upgrade.

Current Setup:
currentsetup

###DELETE & UPLOAD IMAGE ON NEXUS5K
S1(A)#copy tftp: bootflash:
S1(A)#Name: (Kickstart / System filename.bin)
S1(A)#VRF: Management
S1(A)#TFTPSERVER:10.7.0.21
S1(A)#dir | Include .bin (Select the unused file.)
S1(A)#delete bootflash:name

VERIFY:
Dir bootflash:
Dir | include .bin

SAVE: copy running start

###VERIFYING UPLOAD ED KICKSTART AND SYSYEM
S1(A)#show file bootflash:\\kickstart.bin md5sum

Compare the output command on your md5 document. If there’s a different with the output and the document we need to repeat the upload process.

Verify:
Show Version
Show boot
Dir | I .bin
Show fex
Show vpc role

###pre-installation

###KICKSTART & SYSTEM INSTALLATION (on privilege mode)

S1(A)#install all kickstart bootflash:name system bootflash:name

S1(A)#do you want to continue y/n: Y
upgraded1

After N5k up-gradation process all it’s Fex will be transferred to standby N5k because all fex’s are using the old version.
up2

Also VPC peer link will be in down state because of version mismatch.

On N5k upgrade process the parent send the updated version to all Fex’s.
up3

### Activating FEX new installed version
N5k(S)#show fex
Now we only have 2 fex # 1 and 2
! We need to reload all fex one at a time
N5k(S)#reload fex 1
N5k(S)#(y/N): Y
N5k(S)#reload fex 2
N5k(S)#(y/N): Y
We reload the dex so we can activate the newer version.

After reload all fex will transfer to the active and the updated one.
up4

On N5k Standby lets change the boot and kickstart version on global config
N5k-S(conf)#boot system bootflash:name
N5k-S(conf)#boot kickstart bootflash:name

Save: Copy run start

Verify N5K Active fex if all online.
#show fex
#show vpc role

Now if FEX on active N5k is all online we can now reload the N5k Standby.
N5k-S#reload

After the boot process verify the ff.
#show boot
#Show version
#show fex
#show vpc role
#show port-channel

Now all N5k and its fex has been upgraded. VPC Link also established.
up5

###ENCOUNTERED ISSUES

  1. Installed different version or path on N5k.

A: All current configuration will be affected and worse case will be erase. So that why we need to backup the existing images and configuration so that we can do rollback in-cased we encountered this issue.

https://community.cisco.com/t5/other-data-center-subjects/n5k-n2k-image-upgrade-single-vs-dual-homed/td-p/1669293
http://www.firewall.cx/cisco-technical-knowledgebase/cisco-data-center/1208-nexus-vpc-configuration-design-operation-troubleshooting.html

Nexus Switches Overview

I. Switches
Core Switches
– Nexus 9000 and 7000 / 7700

Aggregation Switches
– Nexus 6000 & 5500 / 5600

Access Switches
– Nexus 5500 / 5600, 3000, 2000

II. System Major parts
1. Chassis – Physical enclosure of the switch.
2. Supervisor – CPU or the brain of the switch.
3. Line Cards – Physical Port.
4. Fans
5. Power
6. Fabric Module

III. Port Grouping
M132XP Module (Ethernet)
F132XP Module (Fibre Channel)

Note: Not all line card support the features.
http://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white_paper_c11-701112.html

Nexus 7000 / 7700
Core Lan & FCoE Switch
– 1/10/40/100 Gbps Ethernet Ports
– Layer 2 & Layer 3 LAN Switching
– FCoE SAN Switching
– No Native FC Ports

Nexus 5500 / 5600
Aggregation and Access LAN/SAN Switch
– 1/10/40 Gbps Ethernet Ports
– Layer 2 & Layer 3 LAN Switching
– FCoE & Native FC SAN Switching

Nexus 2000
Fabric Extender or a FEX

Nexus 7010k Version Upgrade

Upgrade Procedure
DCIM100GOPRO

DCIM100GOPRO

Current Version: 6.1(2)
Target Version: 6.2(14)
 ISSU Multistep: 6.1(2) – 6.2(2a)—6.2(8a)—6.2(14)
In our case we need to first upgrade node2. According to cisco TAC it would be better for NXOS if you are going to upgrade one at a time also to be consistent.
 Procedure:
  1. Connect to physical device via console cable.
  2. Once all the requirement, image etc. are ready you can proceed to upgrade.
Cisco recommend atleast 250MB of space on  per device.
 Upload all image on bootflash using tftp server or your preferred method of uploading.
###DELETE & UPLOAD IMAGE ON NEXUS7K
S1(A)#copy tftp: bootflash:
S1(A)#Name: (Kickstart / System filename.bin)
S1(A)#VRF: Management (Network)
S1(A)#TFTPSERVER:10.7.0.21
 
S1(A)#dir | Include .bin (Select the unused file.)
S1(A)#delete bootflash:name
 
VERIFY:
Dir bootflash:
Dir | include .bin
SAVE: copy running start vdc-all (VDC-ALL to apply to all VDC)
Note: VERIFY THE FILE NAME BEFORE YOU ADD OR DELETE and before pressing enter command.
 ###VERIFYING UPLOAD ED KICKSTART AND SYSYEM
S1(A)#show file bootflash:\\kickstart.bin md5sum
Compare the output command on your md5 document. If there’s a difference with the output and the document we need to repeat the upload process.
 Note: MD5 comes with your downloaded file in cisco.com you can also download md5 for hashing.
 Verify:
Show Module
Show Version
Show boot
Dir | I .bin
###KICKSTART & SYSTEM INSTALLATION (on privilege mode)
S1(A)#install all kickstart bootflash:name system bootflash:name
S1(A)#do you want to continue y/n: Y
Note: By default NO is the default when you press enter. While the device is still on installing process you shouldn’t press the enter command because it will cause interruption also the prompt Q.
Then it will automatically replicate and install the image to the standby supervisor. After that S1 will automatically reload then Supervisor 2 will be the primary sup.
After S2 installation verify the ff.
Show version
Show Module
Show boot
After the installation we need to reload the module. Only the active supervisor can reload the module in this scenario S2 is the active one (show module).
From S2 we need to reload S1 with the command:
S2(A)#Reload module #
After reloading switch S1 as active on S2.
S2(A)#system switchover
After the reload process, Verify the following
Show module, show version, show boot
SAVE S1 and S2 #copy run start vdc-all
VERIFICATION COMMAND: show run | I boot, Show install status.
Note: Best practice to reload the supervisor one at a time.
###ENCOUNTERED ISSUES
  1. Lost of SVI?
A: version issues
  1. Module 4 down after reload due to temperature-sensor exceeded alarm.
A: Verify Air flow if there’s  any obstruction. After that you can manually power on the module.
#no poweroff module no. (TO POWER ON Manually)
Verify: show environment temperature, show log last 50
  1. No Connectivity Management Processor (CMP).
A: Only for old version
  1. After upgrade supervisor 1 turn standby and supervisor 2 goes Active.
A: we can use the #system switchover to change active/standby state.