Cisco Nexus 5k configuration overview

This article will show a list of activities to basically configure a Cisco Nexus 5000 switch. This is not an advanced configuration article, just an overview of basic configuration. People new to Cisco Nexus switches will be displaced by three features/commands:

  • license (not covered in this article): Nexus Switch features are now licensed, as Fiber-Channel switch always were.
  • feature: specific features must be enabled (loaded). Examples are: lacp, lldp, fex, vtp…
  • vrf: vrfs are used by default. A management vrf exists and must be used for management purposes

Basic connectivity

The first difference between a Catalyst switch and a Nexus switch is that Nexus use VRF by default. A management vrf exists and should be used for all management traffic:

hostname nexus5596-01
interface mgmt0
  ip address
vrf context management
  ip domain-name
  ip name-server
  ip route

Disabling Telnet Server

SSH server is enabled by default. Telnet server can be disabled logign through SSH and removing telnet feature:

no feature telnet

Any telnet user will be disconnected.


NTP is simple enough, just remember to use right VRF:

clock timezone CET 1 0
clock summer-time CEST 5 Sun Mar 02:00 5 Sun Oct 03:00 60

ntp server use-vrf management
ntp server prefer use-vrf management

Check the configuration with the following command:

show ntp peer-status


Logging is through a syslog server. Link and Trunk status change alert are enabled:

logging event link-status enable
logging event trunk-status enable
logging server 6 facility local5 use-vrf management

RADIUS Authentication

A couple of Radius server are configured to allow centralized authentication through Windows Active Directory. First define Radius servers, then define a Radius authentication group method:

radius-server host key radiuspsk authentication accounting timeout 5
radius-server host key radiuspsk authentication accounting timeout 5

aaa group server radius RADIUS-AUTH
    deadtime 5
    use-vrf management

Again, management VRF is used. The Radius authentication can be tested:

test aaa group RADIUS-AUTH example\user password

Now autentication method can be configured to use the group method (Radius) configured above:

aaa authentication login error-enable
aaa authentication login console local
aaa authentication login default group RADIUS-AUTH
aaa accounting default group RADIUS-AUTH
username example\user role network-admin

A Radius request is in the form:

Packet-Type = Access-Request
User-Name = "example\\user"
NAS-Port-Type = Virtual
NAS-Port = 3000
NAS-IP-Address =

User allowed to login to NAS-Port-Type Virtual will successfly authetnicate to the Nexus Switch. By default all authenticated users will have unprivileged access. To raise privileges each user must be configured inside the Nexus switch:

username example\user role network-admin

The same privilege can be set from Radius itself using a Cisco attribute:

Cisco-AVPair = "shell:priv-lvl=15"
Cisco-AVPair = "shell:roles=network-admin"

The first one is used by IOS devices, the last one is used by NX-OS devices.

The NX-OS supported fallback method for authentication is that if all the AAA remote RADIUS or TACACS+ servers are unreachable, then the log in attempts to authenticate the SSH/Telnet user locally.

Adding the second attribute can broke login process on some Catalyst switches. This happens because the second attribute is unknown to Catalyst switches but it is received as mandatory:

000327: May 24 14:52:14.172: AAA/AUTHOR/EXEC: Processing AV service=shell
000328: May 24 14:52:14.172: AAA/AUTHOR/EXEC: Processing AV cmd*
000329: May 24 14:52:14.172: AAA/AUTHOR/EXEC: Processing AV priv-lvl=15
000330: May 24 14:52:14.172: AAA/AUTHOR/EXEC: Processing AV roles=network-admin
000331: May 24 14:52:14.172: AAA/AUTHOR/EXEC: received unknown mandatory AV: roles=network-admin
000332: May 24 14:52:14.176: AAA/AUTHOR/EXEC: Authorization FAILED

To solve this just turn the second attribute from mandatory to optional with “*” rather then “=”:

Cisco-AVPair = "shell:priv-lvl=15"
Cisco-AVPair = "shell:roles*network-admin"

Call Home

Call Home is a service to notify configurations/alert by email. First step is define a snmp contact:

snmp-server contact

Then callhome can be configured. First step is define who is the maintainer of the switch:

  switch-priority 3
  site-id Padova
  phone-contact +391234567890
  streetaddress st. example, 7

Then a profile can be configured. A profile defines who and how receive email notifications:

  destination-profile Example
  destination-profile Example format full-txt
  destination-profile Example email-addr
  destination-profile Example alert-group all

Last step is define how emails can be sent:

  transport email smtp-server port 25 use-vrf management
  transport email from

Finally test the callhome configuration:

callhome test inventory


SNMP configuration is very easy:

snmp-server contact
snmp-server location st. example, 7 - Padova
snmp-server host traps version 2c public
snmp-server host traps version 2c public
snmp-server enable traps config
snmp-server enable trap link
snmp-server enable trap callhome
snmp-server community public ro
snmp-server source-interface traps mgmt 0

Jumbo Frame (MTU 9216)

Jumbo frame is a feature requested when iSCSI/NFS/FCoE protocols are used. There are many opinion pro and cons about performance with or without Jumbo frames under iSCSI and NFS protocols. Jumbo frame is a requirement when FCoE is used, because a FC frame is about 2k length.

Enabling Jumbo frames does not require a reboot:

policy-map type network-qos jumbo
  class type network-qos class-default
    mtu 9216
system qos
  service-policy type network-qos jumbo

Check the current MTU supported on a interfaces using the following command:

show queuing interface Ethernet1/47
    q-size: 470080, HW MTU: 9216 (9216 configured)

Fabric Exnteder pre-provisioning

In a Nexus 5K migration, one or more N2K can be pre-provioned and pre-confgured:

feature fex
slot 100
  provision model N2K-C2232P

In the example the FEX will be connected to a portchannel on Ethernet1/46-47 ports:

interface Ethernet1/46
  channel-group 100
interface Ethernet1/47
  channel-group 100
inrerface port-channel101
  switchport mode fex-fabric
  fex associate 101

Now there will be 32 Ethernet interface under slot 100 (Ethernet100/1/1-32).


A vPC configuration need to define a vPC keepalive link, a vPC peer link, two vPC peer switches to form a vPC domain. A vPC domain include vPC port-channel to the downstream devices.

A vPC keepalive session is esablished using the management interface:

A vPC domain include both vPC switches, the vPC perr link,

feature vpc
vpc domain 96
  role priority 4096
  peer-keepalive destination

A vPC peer link must be configured using a port-channel and two 10GbE interfaces at least:

interface Ethernet1/47 - 48
  switchport mode trunk
  channel-group 1

interface port-channel1
  switchport mode trunk
  spanning-tree port type network
  vpc peer-link

A vPC (downstream) link must be configured using port-channel on both switches, even if only one interface is bounded in each switch:

interface Ethernet1/1
  switchport mode trunk
  channel-group 2 mode active

interface port-channel2
  switchport mode trunk
  vpc 2

The port-channel must configure an unique vpc ID, in the above example the port-channel ID is used for vpc ID also.