Cisco Nexus 5k configuration overview

Andrea Dainese
May 24, 2013
Post cover

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 switches 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 10.1.12.6/24
vrf context management
  ip domain-name example.com
  ip name-server 10.1.7.8 10.1.7.9
  ip route 0.0.0.0/0 10.1.12.1

Disabling Telnet Server

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

no feature telnet

Any telnet user will be disconnected.

NTP

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

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

ntp server ntp1.example.com use-vrf management
ntp server ntp2.example.com prefer use-vrf management

Check the configuration with the following command:

show ntp peer-status

Syslog

Cisco Nexus switches can log through a Syslog server. Link and Trunk status change alerts are enabled:

logging event link-status enable
logging event trunk-status enable
logging server syslog.example.com 6 facility local5 use-vrf management

RADIUS Authentication

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

radius-server host radius1.example.com key radiuspsk authentication accounting timeout 5
radius-server host radius2.example.com key radiuspsk authentication accounting timeout 5

aaa group server radius RADIUS-AUTH
    server radius1.example.com
    server radius2.example.com
    deadtime 5
    use-vrf management

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

test aaa group RADIUS-AUTH example\user password

Authentication 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 = 10.1.12.6

Users allowed to log in to NAS-Port-Type Virtual will successfully authenticate 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 login attempts to authenticate the SSH/Telnet user locally.

Adding the second attribute can break the 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 than “=”:

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

Call Home

Call Home is a service to notify configurations/alerts by email. The first step is define an SNMP contact:

snmp-server contact noc@example.com

Then call home can be configured. The first step is define who is the maintainer of the switch:

callhome
  switch-priority 3
  site-id Padova
  email-contact noc@example.com
  phone-contact +391234567890
  streetaddress st. example, 7

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

callhome
  destination-profile Example
  destination-profile Example format full-txt
  destination-profile Example email-addr noc@example.com
  destination-profile Example alert-group all

The last step is define how emails can be sent:

callhome
  transport email smtp-server smtp.example.com port 25 use-vrf management
  transport email from nexus5596-01@example.com
  enable

Finally, test the call-home configuration:

callhome test inventory

SNMP

SNMP configuration is very easy:

snmp-server contact noc@example.com
snmp-server location st. example, 7 - Padova
snmp-server host snmp1.example.com traps version 2c public
snmp-server host snmp1.example.com 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 opinions pros and cons about performance with or without Jumbo frames under iSCSI and NFS protocols. Jumbo frame is a requirement when FCoE is used because an FC frame is about 2k in 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 interfaces using the following command:

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

Fabric Extender pre-provisioning

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

feature fex
slot 100
  provision model N2K-C2232P

In the example the FEX will be connected to a port channel 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 interfaces under slot 100 (Ethernet100/1/1-32).

vPC

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

A vPC keepalive session is established using the management interface:

A vPC domain includes both vPC switches, the vPC peer link,

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

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 a unique VPC ID, in the above example, the port-channel ID is used for VPC ID also.

References