Upload
nguyentuyen
View
257
Download
4
Embed Size (px)
Citation preview
CCIE DATA CENTER V1.0 Lab Preparation Guide
First Edition
ALOK RASTOGI, CCIE NO 42872 ( DC)
Contents
Part 1: CCIE Data-Center Nexus Lab
� Lab 1 Nexus 7000 - 5000 Hardware platform
� Lab 2 Cisco NX-OS License
� Lab 3 Implementing Telnet / Shh
� Lab 4 Configuring Management Interface-- /Control Processor /CMP/
� Lab 5 Configuring SNMP
� Lab 6 Managing File System
� Lab 7 Configuration Checkpoint and Rollback on Nexus 7000 / Nexus 5x00
� Lab 8 IEEE 802.3az (Energy Efficient Ethernet)
� Lab 9 Power on Auto-Provisioning
� Lab 10 LED Locator N7K
� Lab 11 Intrusion Detection System (IDS)
� Lab 12 Onboard Logging N7K
� Lab 13 CPU health Check
� Lab 14 Troubleshooting Memory Utilization —System Memory
� Lab 15 Switch Fabric Load-Sharing, Utilization, Capacity, VOQ
� Lab 16 Configuring CFS and troubleshooting
� Lab 17 Configuring VDC and Resource template and limit-resource configuration
� LAB 18 Configuring Nexus 2000 Using Static Pinning and Via Port-channels
� LAB 19 Configuring Vlans , VTP and Interface Vlans , Port-Channel , Port-channel Load balancing
Configuration
� LAB 20 Configuring Rapid Spanning tree Protocols
� Lab 21 STP Fine Tuning Timers
� LAB 22 Configuring MST and Cost
� LAB 23 Configuring BPDU-Guard , Error-discovery, BPDU-Filter , Root-Guards, UDLD , Bridge-
Assurance
� LAB 24 Configuring Port-Profile
� LAB 25 Configuration VPC
� LAB 26 VPC Consistency Error Check
� LAB 27 VPC Keep-alive Failover Scenarios
� LAB 28 VPC Peer-link Failover Scenarios
� LAB 29 VPC Split Brain Scenarios
� LAB 30 Configurations EVPC with Active-Active and Active –Standby NIC Teaming testing
� LAB 31 VPC Fine Tuning
� LAB 32 Configuration BACK to BACK VPC
� LAB 33 VPC and HSRP Configuration
� LAB 34 Configuring Fabric Path & vPC+
� LAB 35 Configuring EIGRP and its features
� Lab 36 OSPF V2 and its Features
� LAB 37 Configuring BGP, BGP Router ID, Address Families
� LAB 38 Configuring Virtual Router Redundancy Protocol (VRRP)
� LAB 39 Configuring Gateway Load Balancing Protocol (GLBP)
� LAB 40 Configuring RADIUS
� LAB 41 Configuring TACACS+
� LAB 42 Configuring Cisco Trust Sec
� LAB 43 Configuring IP ACLs
� LAB 44 Configuring MAC ACLs
� LAB 45 Configuring VLAN ACLs
� LAB 46 Configuring Port Security
� LAB471 Configuring DHCP Snooping
� LAB 48 Configuring Dynamic ARP Inspection
� LAB 49 Configuring IP Source Guard
� LAB 50 Configuring Traffic Storm Control
� LAB 51 Configuring Unicast RPF
� LAB 52 Configuring Control Plane policing
� LAB 53 Configuring Rate Limits
� LAB 54 Physical redundancy
� LAB 55 Generic online diagnostics
� Lab 56 NX-OS high-availability architecture
� LAB 57 Process modularity
� LAB 58 Process restart
� LAB 59 Stateful switchover
� LAB 60 Nonstop forwarding
� LAB 61 In-Service Software Upgrades (ISSU)
� LAB 62 Configuring SPAN
� LAB 63 Configuring ERSPAN
� LAB 64 Configuring Embedded Analyzer
� LAB 65 Configuring Smart Call Home
� LAB 66 Configuring Net flow
� LAB 67 Configuring NTP
� LAB 68 Configuring OTV
� LAB 69 Basic VRF-Lite Configuration
� Lab 70 Configuration L3 VPN
� LAB 71 Configuring LISP
Lab 1 Nexus 7000 / 5000 Hardware platform
Lab Objectives
• In this Lab main objective is to provide the Hardware details of the Nexus 7000 or 5000 Series
• Lab also explains the software / Image versions and Power utilization used by Nexus Devices
Lab Task
• Connect to the Nexus 7000 series and determine the system software version that is currently
running on the Cisco Nexus
• Connect to the Nexus 7000 series and determine the Cisco Nexus 7010 hardware components.
• Connect to the Nexus 7000 series and determine the active supervisor.
• Connect to the Nexus 7000 series display system environment information
• Connect to the Nexus 7000 series to connect directly to an individual module. And After
attaching to particular Module check how to see the module details
• Connect to the Nexus 7000 series use the Display module system resources utilization
Lab Solution
Step 1: Connect to the Nexus 7000 series and determine the system software version that is currently
running on the Cisco Nexus
NX-OS uses a kickstart image and a system image. Kick start image provides the Linux kernel, basic
drivers, and initial file system. The NX-OS system image boots after the kick start image and provides L2,
L3, infrastructure and feature support such as OTV, multicast, FEX, and so on.
Step 2: Connect to the Nexus 7000 series and determine the Cisco Nexus 7010 hardware components.
This Command will show you how many modules, what types of modules, Supervisor, and other
Hardware components are installed in this Nexus Box.
This Nexus 7010 Box contain following Hardware Installed:
1. One 7010 Slot Chassis ,
2. Slot 1 contains one F1 Module
3. Slot 3 contains M1 Module
4. Slot 5 Contains Supervisor generation 1
5. Slot 11 contain One fabric Module generation 1
6. Slot 12 contain One fabric Module generation 1
7. Slot 13 contain One fabric Module generation 1
8. Slot 33 contain One Power Supply Unit of 6KW
9. Slot 34 contain One Power Supply Unit of 6KW
10. Slot 36 contain One System Fan Module
11. Slot 37 contain One System Fan Module
12. Slot 38 contain One Fabric Fan Module
13. Slot 39 contain One Fabric Fan Module
This Nexus 7010 Box contain following Hardware Installed:
Same for Nexus 5000:
The Above Module can also be found by giving the Show Module Command on the Nexus Box. This
Command provides the Module type / Module number Installed on the particular Slot and also provides
the Status and Physical address.
For 5000 Device Following are the Module Installed.
Step 3: Connect to the Nexus 7000 series and determine the active supervisor.
To know about the active Supervisor, show redundancy status command provides you the details
This Lab Provides information that Active Supervisor is installed on Slot 5 on the Nexus 7010. There is No
redundancy Mode configured with Internal State Active with No standby. Active Supervisor Uptime is 0
days 2 hours.
Step 4: Connect to the Nexus 7000 series display system environment information.
TO know about the Nexus 7010 Platform environment use the command show environment
This Show command is divided in to two parts, Part first describes about the Clock Module and FAN
Installed and about its status.
This Second part defines the Total Power available and Power Consumption used by the each module.
Power supply redundancy mode is currently specified � Power Supply Redundant
Module or modules draw the least amount of power� Fabric Modules
Power Available by N7K-AC-6.0 KW Module is 6000 Watts Per Power Module So total Power available
from all 3 power Unit is 18000W and actual Power output drawn is 2284 W.
Step 5: Connect to the Nexus 7000 series use the attach command to connect directly to an individual
module. And After attaching to particular Module you can use Show Command to see the details
Step 6: Connect to the Nexus 7000 series use the Display module system resources utilization.
Lab 2 Cisco NX-OS License
Lab Objectives
• In this Lab main objective is to provide the information about the
• Lab also explains the software / Image versions and Power utilization used by Nexus Devices
Lab Task
• Check what is installed on the Nexus Devices
• Check what License is used by the system
• How to install any License file to Boot flash:
• How to install any License file in grace Period.
LAB Solution
Nexus 7000:
Step 1: To show what is installed on the Nexus Devices use Show License command
Step 2: To show what License is used by the system is shown by Show License usage command
Step 3: To install any License file to Boot flash: use the following Commands:
N7K-12-S01) # Install license boot flash: license_file.lic
Step 4: To Install any License file in grace Period.
NX-OS offers feature testing for a 120-day grace period. Here is how to enable a 120-day grace period:
N7K-12-S01) # license grace-period
The feature is disabled after the 120-day grace period begins. The license grace period is enabled only
for the default admin VDC- VDC1. Using the grace period enables customers to test, configure, and fully
operate a feature without the need for a license to be purchased. This is particularly helpful for testing a
feature prior to purchasing a license.
Lab 3 Implementing Telnet / SSH
Lab Objectives
• In this Lab main objective is to provide the information about the
• Lab also explains the software / Image versions and Power utilization used by Nexus Devices
Lab Task
• Enable how telnet server is enabled on Nexus
• Enable SSH on the Nexus by enabling the SSH Server and SSH Server keys
• Generate the SSH Key using rsa with 2048 Bits
• Create the local user Account
Lab Solution
Step 1: Enable how telnet server is enabled on Nexus
Step 2: Demonstrates how to enable an SSH server and configure the SSH server keys.
Step 3: To Generate the SSH Key:
N7010-1(config) # ssh key rsa 2048
Generating rsa key (2048 bits).....
Step 4: To check SSH Server and the User account:
N7010-1(config) # username nxos-admin password C1sc0123!
N7010-1(config) # username nxos-admin sshkey ssh-rsa
Lab 4 Configuring Management Interface /CMP
Lab Objectives
• In this Lab main objective is to provide the information about the Management Interface, and
CMP interface.
Lab Task
• Check the Mgmt0 interface by using show command
• Check what the default VRF of the management Interface is
• Check what routes are present in Management VRF
• Connect to CMP Module and check what are the Show commands are available for this module
Lab Solution
Step1: Check the Mgmt0 interface by using show command
MGMT0: Mgmt0 interface provides out-of-band management connection to NXOS device through a
dedicated interface and VRF and it ensure isolation from either control plane or data plane. MGMT0
enables you to manage the devices by the IPv4 or IPv6 address on the MGMT0 interface. The mgmt0
interface is a 10/100/1000 Ethernet interface. When implementing vPC, a best practice is to use the
MGMT0 interface for the vPC keepalive link.
Step2: Check what the default VRF of the management Interface is and Check what routes are present
in Management VRF
Management Interface is in by default “management VRF “and its routing table is also in management
VRF.
Step 3: Connect to CMP Module and check what are the Show commands are available for this module
Shows how to connect to the CMP interface and the available show commands available from the CMP
interface. Also, note the escape sequence of “~,” to get back to the main NX-OS interface. You can also
connect from the CMP back to the CP module.
N7010-1# attach cmp
Connected
Escape character is '~,' [tilde comma]
N7010-1-cmp5 login: admin
Password:
Last login: Tue Aug 11 23:58:12 2009 on ttyS1
N7010-1-cmp5# attach cp
This command will disconnect the front-panel console on this supervisor, and will clear all console
attach sessions on the CP - proceed(y/n)? Y
N7010-1#
N7010-1# attach cmp
Connected Escape character is '~,' [tilda comma]
N7010-1-cmp5 login: admin
Password:
Last login: Wed Aug 12 00:06:12 2009 on ttyS1
N7010-1-cmp5# show?
Lab 5 Configuring SNMP
Lab Objectives
• In this Lab main objective is to provide the information about the SNMP and how to configure
the SNMP on the Nexus devices.
Lab Task
• Create object group for the interface used by SNMP server to poll the device. Use the IP address
of management interface.
• Configure access list to allow snmp communication between server and device. Source will be
SNMP server IP address and destination is management interface address
• For Read Only and Write the SNMP server address is 10.1.1.20/32
• Configure Read only community CISCORO
• Configure Read write community CISCORW
• Configure access list for snmp communities for read and Write only
• Configure the SNMP trap source address. SNMP server will receive traps with source interface
mgm0. SNMP server will convert the traps to alert only if it has the correct MIB in its database.
• Enables the EIGRP traps (Authentication and SIA).
• Enable Link down traps.
• Enable traps when HSRP state changes.
• Enables traps for FAN status change
• Enable traps for module status change.
• Enable traps for unrecognized module
• Device will send the traps to server 10.1.1.20.
Lab Solution
Step1. Create object group for the interface used by SNMP server to poll the device. In this example we
use the IP address of management interface. We have given the name snmp-Interface to management
interface. It is basically a IP to name mapping.
Nexus-switch (config) # object-group ip address snmp-Interface
Nexus-switch (config-ipaddr-ogroup) # host 192.168.1.1
Step2. Configure access list to allow snmp communication between server and device. Source will be
SNMP server IP address and destination is management interface address.
For simplicity, I have used the IP in access list; you can specifically allow the snmp ports between server
and device. If you allow specific ports, please make sure that trap port (UDP 162) must also be opened.
Access list for read only servers:
Nexus-switch (config) # ip access-list Readonly-snmp-traffic
Nexus-switch (config-acl) # permits ip 10.1.1.20/32 addrgroup snmp-Interface
Access list for write servers:
Nexus-switch (config) # ip access-list Readwrite-snmp-traffic
Nexus-switch (config-acl) # permit ip 10.1.1.20/32 addrgroup snmp-Interface
Step3. Configure Read only community
Nexus-switch (config) # snmp-server community CISCORO group network-operator
Step4. Configure Read write community
Nexus-switch (config) #snmp-server community CISCORW group network-admin
Step5. Configure access list for snmp communities.
Nexus-switch (config) #snmp-server community CISCORO use-acl Readonly-snmp-traffic
Nexus-switch (config) #snmp-server community CISCORW use-acl Readwrite-snmp-traffic
Step6. Configure the SNMP trap source address. SNMP server will receive traps with source interface
mgm0. SNMP server will convert the traps to alert only if it has the correct MIB in its database.
Nexus-switch (config) # snmp-server source-interface traps mgmt. 0
Step7. Enables the EIGRP traps (Authentication and SIA).
Nexus-switch (config) # snmp-server enable traps eigrp
Step8. Enable Link down traps.
Nexus-switch (config) # snmp-server enable traps link linkdown
Step9. Enable traps when HSRP state changes.
Nexus-switch (config) # snmp-server enable traps hsrp state-change
Step10. Enables traps for FAN status change.
Nexus-switch (config) # snmp-server enable traps entity entity_fan_status_change
Step11. Enable traps for module status change.
Nexus-switch (config) # snmp-server enable traps entity entity_module_status_change
Step12. Enable traps for unrecognised module
Nexus-switch (config) # snmp-server enable traps entity entity_unrecognised_module
Step13. Device will send the traps to server 10.1.1.20.
Nexus-switch (config) # snmp-server host 10.1.1.20 traps CISCOTRAPS
Lab 6 Managing File System
Lab Objectives
• In this Lab main objective is to Managing File System
Lab Task
• Check the File in the Bootflash:
• Check the File in the Bootflash of the Remote-Sup:
• Copy congo-s1-epld.4.0.4.img from Local Sup to Remote Sup.
Lab Solution
Step1: Check the File in the Bootflash:
N7010-1# dir boot flash:
Step2: Check the File in the Bootflash of the Remote-Sup:
N7010-1# dir bootflash: //sup-remote
Step3: Copy congo-s1-epld.4.0.4.img from Local Sup to Remote Sup.
N7010-1# copy bootflash://sup-local/congo-s1-epld.4.0.4.img bootflash://supremote/congo-s1-
epld.4.0.4.img
Lab 7 Configuration Checkpoint and Rollback on
Nexus 7000 / Nexus 5x00
Lab Objectives
• In this Lab main objective is to Configuration Checkpoint and Rollback on Nexus 7000 / Nexus
5x00
Lab Task
• Create and name the checkpoint for the current configuration.
• Verify the newly created checkpoint.
• Modify the running configuration by changing interface parameters by changing the IP address
from 10.11.1.1/24 to 10.1.1.1/24
• Perform the rollback operation.
• Verify the rollback
Lab Solution
Step 1 View the running configuration.
Step 2 Create and name the checkpoint for the current configuration.
Step 3 Verify the newly created checkpoint.
Step 4 Modify the running configuration by changing interface parameters.
Step 5 Perform the rollback operation.
Step 7 Verify the rollback
Lab 8 IEEE 802.3az (Energy Efficient Ethernet)
Lab Objectives
• In this Lab main objective is to IEEE 802.3az (Energy Efficient Ethernet)
Lab Task
Configure the power efficient-Ethernet auto command to Eth5/45 interface to make it energy efficient
interface and make the interface UP.
Lab Solution
Step1: N7K-1-EEE# show int e5/45
Ethernet5/45 is down (Link not connected)
Step2: N7K-1-EEE# config
Enter configuration commands, one per line. End with CNTL/Z.
N7K-1-EEE (config) # int e5/45
N7K-1-EEE (config-if) # power efficient-ethernet auto
N7K-1-EEE (config-if) # end
N7K-1-EEE# show int e5/45
Ethernet5/45 is up
Lab 9 Power on Auto-Provisioning
Lab Objectives
• In this Lab main objective is to Configure Power on Auto-provisioning
Lab task and Solution
As of NX-OS 6.1(2) on the Nexus 7000 and NX-OS 5.1(3) N2, a feature named Power on Auto
Provisioning has been added to the capabilities of NX-OS. Following are the steps performed during a
switch booting up in a POAP environment.
1. Switch powers on and starts the POAP process.
2. A DHCP request is sent and replied to with attributes such as IP address, default gateway, script
server and script filename via Client Identifier option 61. DHCP option 61 contains the serial number
of the unit, which is used to determine which attributes to provide via the script.
3. Switch downloads the script from the script server using FTP or other supported mechanism, and the
switch begins script execution.
4. Script instructs the device on how to download the configuration, NX-OS files, license files, and other
attributes.
5. The switch reloads if needed and joins the network per the downloaded configuration.
Lab 10 LED Locator N7K
Lab Objectives
• In this Lab main objective is to see the LED Locator
Lab Task
• Check How Locator Led Configured and how to verify the Locator Led
Lab Solution
LED locator (Beacon) New hardware feature
• Makes it easy to locate any hardware component for maintance
• Operated from default vdc only
• Once turned on, stayes on till turned off
N7K-1# locator-led?
N7K-1# show locator-led status
Component Locator LED Status
Chassis off
Module 1 ON
Example:
Lab 11 Intrusion Detection System (IDS)
Lab Objectives
• In this Lab main objective is to configure and see the IDS
Lab Task
• Check and Verify the default setting of IDs in Default VDC
• Check and clear all the IDS counters
• Configure to Drops IP packets if the packet checksum is invalid
• Configure How Nexus Perform IDS Checks on the Ip address
Lab Solution
Use hardware ip verify cli in default vDC to modify settings
To clear IDS counters use cli clear hardware forwarding ip verify all
Step1: N7K-1# hardware ip verify address {destination zero |identical | reserved | source {broadcast |multicast}}
Performs the following IDS checks on the IP address:
• destination zero—Drops IP packets if the destination IP address is 0.0.0.0.
• identical—Drops IP packets if the source IP address is identical to the destination IP address.
• reserved—Drops IP packets if the IP address is in the 127.x.x.x range.
• source—Drops IP packets if the IP source address is either 255.255.255.255 (broadcast) or in the
224. x.x.x range (multicast).
Step2: N7K-1# hardware ip verify checksum: Drops IP packets if the packet checksum is invalid.
Step3: N7K-1# hardware ip verify length {consistent |maximum {max-frag | max-tcp | udp} | minimum} Performs the following IDS checks on the IP address:
• consistent—Drops IP packets where the Ethernet frame size is greater than or equal to the IP
packet length plus the Ethernet header.
• maximum max-frag—Drops IP packets if the maximum fragment offset is greater than 65536.
• maximum max-tcp—Drops IP packets if the TCP length is greater than the IP payload length.
• maximum udp—Drops IP packets if the IP payload length is less than the UDP packet length.
• minimum—Drops IP packets if the Ethernet frame length is less than the IP packet length plus four
octets (the CRC length).
Lab 12 Onboard Logging N7K
Lab Objectives
• In this Lab main objective is to configure and see the IDS
Lab Task
Verify How Onboard Logging is used to verify the Following:
• Boot up time of Module
• Exceptions and asic component crashes, temperature
• Insertion, removal and reset reasons
Lab Solution
Reset Reason: Reset is requested by CLI command Reload.
You can match the Reset time, date and year by following command:
To check logging onboard for any module check with following commands:
Lab 13 CPU health Check
Lab Objectives
• In this Lab main objective is to check and verify the CPU health check
Lab task
• Verify How the Health Check is done on CPU- Supervisor
• Check how much CPU is Utilized and How much is Free
• Check what is the CPU utilization
• Check What Traffic Caused High CPU Utilization and Control-Plane Instability
• Check how to look at the packet rate as well as type of traffic (unicast or multicast) for
CPU−punted traffic from an interface
Lab Solution
Step1: CPU —Supervisor, General Health Check
Step2: CPU — Traffic Caused High CPU Utilization and Control-Plane Instability
Typical datacenter traffic causing high CPU utilization
• arp, nd (ipv6)
• dhcp traffic
• Glean traffic (no arp or nd)
• Malicious traffic to 224.0.0.0/24 subnet
• Fragments or malicious L2 mcast or other traffic
CPU protection via CoPP policers
CPU protection via L2/L3 hardware rate-limiters (RL)
CoPP and RL default settings may need tweaking based on network requirement specifics
• Both are configured/enabled per M1 I/O Module
• Total rp bound traffic allowed is sum across all M1 I/O Modules
Show system resources Command
Use this command in order to display system-related CPU and memory statistics.
Field Description
Load Number of processes that are running. The average reflects the system load over the past 1,
5, and 15 minutes.
Processes Number of processes in the system and how many processes are actually running when the
command is issued.
CPU status CPU usage percentage in user mode, kernel mode, and idle time in the last one second. For a
dual-core Supervisor, CPU is averaged across both cores.
Memory usage
Total memory, used memory, free memory, memory used for buffers, and memory used for cache in kilobytes. Buffers and the cache are included in the used memory statistics.
Show processes cpu Command
Use this command in order to show the CPU usage at the process level:
Field Description
Runtime(ms) CPU time that the process has used in milliseconds
Invoked Number of times the process has been invoked
uSecs Average CPU time for each process invocation in microseconds
1Sec Percentage of CPU usage for the last one second
Show system internal pktmgr interface Ethernet Command
Use this command in order to look at the packet rate as well as type of traffic (unicast or multicast) for
CPU−punted traffic from an interface
Lab 14 Troubleshooting Memory Utilization —
System Memory
Lab Objectives
� In this Lab main objective is to Troubleshooting Memory Utilization —System Memory
Lab Task
• Verify how to check General/High Level Assessment of Platform Memory Utilization
• Verify How to see the System resources
• Verify how to check the Platform Memory Utilization
Lab Solution
Step1: General/High Level Assessment of Platform Memory Utilization
N7K# show system resources
This output is derived from the Linux memory statistics in /proc/meminfo.
total - The amount of physical RAM on the platform
free - The amount of unused or available memory
used - The amount of allocated (permanent) and cached (temporary) memory
The cache and buffers are not relevant to customer monitoring.
N7K# show processes memory
The show process memory command displays the memory allocation per process for the current VDC
(the output will contain non-VDC global processes also).
Step2: Detailed Assessment of Platform Memory Utilization
Use the show system internal kernel command or the show system internal memory-alerts-log
command for a more detailed representation of memory utilization in Cisco NX-OS.
In the output above, the most important fields are as follows:
MemTotal (kB) - Total amount of memory in the system (4 GB in the Cisco Nexus 7000 Series Sup1)
Cached (kB) - Amount of memory used by the page cache (includes files in tmpfs mounts and data
cached from persistent storage /bootflash)
RamCached (kB) - Amount of memory used by the page cache that cannot be released (data not backed
by persistent storage)
Available (Pages) - Amount of free memory in pages (includes the space that could be made available in
the page cache and free lists)
Mapped (Pages) - Memory mapped into page tables (data being used by non kernel processes)
Slab (Pages) - Rough indication of kernel memory consumption
The show system internal kernel memory global command displays the memory usage for the page
cache and kernel/process memory.
In Cisco NX-OS, the Linux kernel monitors the percentage of memory that is used (relative to the total
RAM present) and platform manager generates alerts as utilization passes default or configured
thresholds. If an alert has occurred, it is useful to review the logs captured by the platform manager
against the current utilization. Additional information about this monitoring is included later in this
article.
By reviewing the output of these commands, you can determine if the utilization is high as a result of the
page cache, processes holding memory, or kernel.
Lab 15 Switch Fabric Load-Sharing, Utilization,
Capacity, VOQ
Lab Objectives
� In this Lab main objective is to Troubleshooting Switch Fabric Load-Sharing, Utilization,
Capacity, VOQ
Lab Task
• Verify To see the Ingress and Egress Fabric Module Utilization
• Verify Fabric Unicast Traffic across Fabric, Utilization Details
• Verify the Data Collection (No show tech-support xbar Exists)
Lab Solution
Ingress fabric interface asic knows all active paths through 3-stage xbar to each destination
• Unicast traffic is sprayed (2.5kB super frame broken to small chunks) across all active paths to
egress fabric interface asic
• Multicast traffic selects one of the active paths to egress fabric interface asic based on hash
result calculated based on L2/L3/L4 information (same as EC hash but not configurable)
• First and next fragments may take different path due to missing L4 information in next
fragments
• 4 Virtual Output Queues (VOQ) to every egress port asic (every 12 x 1GE ports or 4 x 10GE ports
in shared mode or 1 x 10GE port in dedicated mode or 2 x 1/10GE ports)
• Unicast traffic access to fabric is arbitrated (arbiter on active supervisor provides grant when
there is enough bandwidth available to destination VoQ)
• Multicast traffic access to fabric is non-arbitrated
Step1: To see the Ingress and Egress Fabric Module Utilization
Here it is 10 Slot Chassis with 3 XBAR Modules. Utilization% is calculated based on 138 GBPS (6*23G)
overall capacity
Step2: Fabric Unicast Traffic across Fabric, Utilization Details
Step3: Data Collection (No show tech-support xbar Exists)
For any packet loss related issues use first show hardware internal error module X and when you see
any potentially related counters moving use show hardware internal statistics module X device
<device> <category> asic-all to filter out unnecessary output (cli may produce very long output difficult
to read)
Lab 16 Configuring CFS and troubleshooting
Lab Objectives
� In this Lab main objective is to Configuring CFS
Lab Instruction
• Verify that CFS is globally enabled on all devices in the network or CFS region.
• Verify that CFS is enabled for the application on all devices in the network or CFS region.
• Verify that CFS distribution is enabled for the application on all devices in the network or
CFS Region.
• If CFS regions configuration is done then, verify that the application is in the same region on
all applicable Devices.
• Verify the set of devices that are registered with CFS for that application.
Lab Solution
Step1: Verify that CFS is globally enabled on all devices in the network or CFS region.
Step2: Verify that CFS is enabled for the application on all devices in the network or CFS region.
Step3: Verify that CFS distribution is enabled for the application on all devices in the network or CFS
Region.
Step4: Verify the set of devices that are registered with CFS for that application.
Lab 17 Configuring VDC, Resource template and
limit resource
Lab Objectives
� In this Lab main objective is to Configuring VDC and allocating Interfaces , Resource Template
etc.
Lab Task
• N7K-1 is the default VDC, where N7K-3 and N7K-4 are non-default VDC
• Nexus 7000with the default VDC N7K-1pre configured
• Configure resource allocations for VDCs N7K-3and N7K-4 at this unit
Device Name Id Ports Type
Device Name Id Ports Type
N7K-1 1 Ethernet 3/1-8, Ethernet 4/1-16 Ethernet
N7K-3 3 Ethernet 3/17-24, Ethernet 4/17-24 Ethernet
N7K-4 4 Ethernet 3/25-32, Ethernet 4/25-32 Ethernet
• Configure resources for the VDC. By using the resource template to perform the task.
• Create and apply VDC resource templates as shown in this table below:
Template Name VDC Name Resource Minimum Maximum
otv-template
N7K-1
VRF 8 16
VLAN 16 32
Port-Channel 0 32
switch-template
N7K-3 & N7K-4
VRF 16 32
VLAN 64 128
Port-Channel 32 64
• In DC2 make sure that these High Availability policies are applied to VDCs
N7K-1: reset
N7K-3: bring down
N7K-4: bring down
Lab Solution
N7K-1) # (From Default VDC)
N7K-1) # vdc resource template otv-template
N7K-1) # limit-resource vrf minimum 8 maximum 16
N7K-1) # limit-resource vlan minimum 16 max 32
N7K-1) # limit-resource port-channel minimum 0 max 32
N7K-1) # vdc resource template switch-template
N7K-1) # limit-resource vrf minimum 16 max 32
N7K-1) # limit-resource vlan minimum 16 max 129
N7K-1) # limit-resource port-channel minimum 32 maximum 64
N7K-1) # vdc N7K-1 id 1
N7K-1) # template otv-template
N7K-1) # ha-policy single-supervisor reset
N7K-1) # system hap-reset
N7K-1) # limit-resource module-type m1 m1x1 f1
N7K-1) # allocate interface e3/1-8
N7K-1) # allocate interface e4/1-16
N7K-1) # vdc N7K-3 id 3
N7K-1) # template switch-template
N7K-1) # ha-policy dual-supervisor bring down
N7K-1) # limit-resource module-type m1 m1x1 f1
N7K-1) # allocate-interface e3/17-24
N7K-1) # allocate-interface e4/17-24
N7K-1) # vdc N7K-4 id 4
N7K-1) # template switch-template
N7K-1) # ha-policy dual-supervisor bring down
N7K-1) # limit-resource module-type m1 m1x1 f1
N7K-1) # allocate-interface e3/25-32
N7K-1) # allocate-interface e4/25-32
show running-config vdc-all
To display the running configurations for all virtual device contexts (VDCs), use the show running-config
vdc-all command.
Show running-config vdc-all [all]
Show vdc
To display virtual context device (VDC) information, use the show vdc command.
Show vdc [vdc-name] [detail]
Show vdc current-vdc
To display the current virtual device context (VDC) identifier information, use the show vdc current-
vdc command.
Show vdc current-vdc
Show vdc membership
To display the interface membership information for the virtual device contexts (VDCs), use the show
vdc membership command.
Show vdc membership [status]
Show vdc resource
To display the virtual device context (VDC) resource information, use the show vdc resource command.
Show vdc resource [monitor-session | port-channel | u4route-mem | vlan | vrf] [detail]
Show vdc resource template
To display the virtual device context (VDC) resource template information, use the show vdc resource
template command.
Show vdc resource template [vdc-template-name]
Switchback
To switch back to the default virtual device context (VDC) from another VDC, use
the switchback command.
Switchback
Switch to vdc
To switch to another virtual device context (VDC) from the default VDC, use the switchto vdc command.
Switchto vdc vdc-name
Vdc combined-hostname
To change the command-line interface (CLI) prompt for the non-default virtual device contexts (VDCs) to
show both the default VDC name and the hostname, use the vdc combined-hostname command. To
change the CLI prompt to show only the non-default VDC name, use the no form of this command.
Vdc combined-hostname
no vdc combined-hostname