CCIE DC LAB Prepration Book Vol 1 - · PDF fileContents Part 1: CCIE Data-Center Nexus Lab Lab 1 Nexus 7000 - 5000 Hardware platform Lab 2 Cisco NX-OS License Lab 3 Implementing Telnet

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



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 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 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



• 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) # allocate-interface e3/17-24


N7K-1) # vdc N7K-4 id 4

N7K-1) # template switch-template

N7K-1) # ha-policy dual-supervisor bring down




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

Documents

CCIE DC LAB Prepration Book Vol 1 - · PDF fileContents Part 1: CCIE Data-Center Nexus Lab Lab 1 Nexus 7000 - 5000 Hardware platform Lab 2 Cisco NX-OS License Lab 3 Implementing Telnet