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
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 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 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
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 syslog.example.com 6 facility local5 use-vrf management
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 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
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 = 10.1.12.6
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 is a service to notify configurations/alert by email. First step is define a snmp contact:
snmp-server contact email@example.com
Then callhome can be configured. First step is define who is the maintainer of the switch:
callhome switch-priority 3 site-id Padova email-contact firstname.lastname@example.org phone-contact +391234567890 streetaddress st. example, 7
Then a profile can be configured. A profile defines who and how receive email notifications:
callhome destination-profile Example destination-profile Example format full-txt destination-profile Example email-addr email@example.com destination-profile Example alert-group all
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 firstname.lastname@example.org enable
Finally test the callhome configuration:
callhome test inventory
SNMP configuration is very easy:
snmp-server contact email@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 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 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 an unique vpc ID, in the above example the port-channel ID is used for vpc ID also.
- Introduction to NX-OS – Basic system setup
- Virtual PortChannel Quick Configuration Guide
- Configuring RADIUS
- Configuring Smart Call Home
- Configuration of Jumbo MTU on Nexus 5000 and 7000 Series
- Spanning Tree Design Guidelines for Cisco NX-OS Software and Virtual PortChannels
- RADIUS Vendor-Specific Attributes and RADIUS Disconnect-Cause Attribute Values