Skip to content

Archive

Category: Nexus 7000

This exercise has been completed on Nexus 7K titanium emulator. I am running two N7K titanium machines inside vmware workstation and have connected 7 network adapters to emulate the physical interfaces in N7K, i am using titanium emulator version 5.2.1, if you are curious to know about the N7K titanium emulator and how to install inside vmware workstation, i will be writing more stuffs on it, soon.

Titanium

I have connected my network adapters as follows on both machines, we can check which physical Ethernet interface on N7K machine is connected to network interface card on vmware workstation by simply disconnecting and watching ” show interface brief” on N7K console  which interface is going down.

Titanium1

Right now my Ethernet2/1 on both N7K is connected to Vmnet4 on both vmware machines.We need to confirm and recheck else our virtual machines will not talk to each other, they should be on the same Vmnet. Lets start with our configuration.

Step 1:- Lets change the hostname of the device and assign N7K-1 to one machine and assign N7K-2 to other machine, by our old IOS familiar command “hostname N7K-1″.

N7K# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
N7K(config)# hostname N7K-1  –>Same for other machine  as N7K-2.

Step-2:- Assign ip address of N7K-1 Ethernet2/1 as 12.12.12.1/24 and unshut the interface, also assign ip address of N7K-2 Ethernet2/1 as 12.12.12.2/24 and unshut the interface.Verify connectivity by pinging across the interfaces.

N7K-1(config)# ping 12.12.12.2
PING 12.12.12.2 (12.12.12.2): 56 data bytes
64 bytes from 12.12.12.2: icmp_seq=0 ttl=254 time=1.747 ms
64 bytes from 12.12.12.2: icmp_seq=1 ttl=254 time=1.262 ms
64 bytes from 12.12.12.2: icmp_seq=2 ttl=254 time=1.423 ms
64 bytes from 12.12.12.2: icmp_seq=3 ttl=254 time=1.396 ms
64 bytes from 12.12.12.2: icmp_seq=4 ttl=254 time=1.58 ms

— 12.12.12.2 ping statistics —
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 1.262/1.481/1.747 ms

Step-3 Check VRF membership of all interfaces inside N7K by ” show vrf interface”, by default there should be one “management” vrf for interface “mgmt0″and all other interfaces assigned to “default” vrf. Create a Loopback0 interface on N7K-1 and N7K-2 as 10.10.10.10/32 and 20.20.20.20/32. Also Create a VRF instance OSPF-VRF and assign it to interface Eth2/1 and Loopback0. Verify vrf assignment by “sh vrf interface”

Titanium2

We can also verify with “sh run vrf OSPF-VRF” to check the interface vrf assignment.

Titanium3

Step 4 Configure the same on N7K-2 with the loopback0 address of 20.20.20.2/32 and vrf as OSPF-VRF and assign it to interface eth2/1 and loopback0.

Titanium4

Step 5 Next we start our OSPF configuration , this Lab is completed under vrf just to show the vrf functionality along with OSPF, we can also run OSPF without vrf instance  in NXOS like we do in IOS. First we enable the “feature ospf” and configure some basic OSPF commands and assign Area 0 to interface Eth2/1 on both N7K and assign Area 1 and Area 2 to both Loopback0. And in the end we will verify our OSPF neighborship and routes received.

Titanium5

Step 6 :- We will verify our configuration with various show commands. And play around with OSPF.

Titanium6

We can also clear ospf process by “clear ip ospf neighbor 20.20.20.20 vrf OSPF-VRF” and by command”restart ospf 1″ . And watch hellos send and received and other ospf traffic related parameters by “sh ip ospf traffic vrf OSPF-VRF”.

Titanium7

We can also configure OSPF authentication in NXOS same as IOS.

Titanium8

This lab has been completed on Nexus 7010 with following hardware and software installed, it can be seen here in my previous post.

In this task we will configure ACLs using the atomic programming feature of Cisco NX-OS
Software. In addition, we will investigate the method used to modify, validate and re sequence ACLs.

Step 1 On your N7K switch create two object-groups, one named ALLOWSUBNETS and the other BADPORTS.

N7k Object1

N7k Object2

Step 2 Exit global configuration mode and reenter using the configure session command.
Name our session ACL-CHECKER
N7K11-pod3# configure session ACL-CHECKER

Step 3 Create an IP access list named BIG-ACL.
N7K11-pod3(config-s)# ip access-list BIG-ACL

Step 4 Assign the object-groups named ALLOWSUBNETS and BADPORTS created in Step 1 above to the IP access list BIG-ACL.
N7K11-pod3(config-s-acl)# permit ip addrgroup ALLOWNETS any
N7K11-pod3(config-s-acl)# deny tcp any port-group BADPORTS any

Step 5 Add the following deny statements to the access list named BIG-ACL.
N7K11-pod3(config-s-acl)# deny tcp 10.200.10.0/24 any
N7K11-pod3(config-s-acl)# deny tcp 10.200.11.0/24 any
N7K11-pod3(config-s-acl)# deny tcp 10.200.12.0/24 any
N7K11-pod3(config-s-acl)# deny tcp 10.200.13.0/24 any
N7K11-pod3(config-s-acl)# exit

Step 6 Assign the IP access list BIG-ACL to the port channel interface within our pod
VDC in the ingress direction.
N7K11-pod3(config-s)# interface port-channel 1

N7K11-pod3(config-s-if)# ip access-group BIG-ACL in
N7K11-pod3(config-s-if)# exit

Step 7 Step 7 Verify the configuration session ACL-CHECK.
N7K11-pod3(config-s)# verify
Verification Successful

Step 8 If the operation in Step 7 was successful, then commit the session to the running
configuration.
N7K11-pod3(config-s)# commit
Commit Successful

N7k Object3

We can check our access-list just configured by ” show access-list BIG-ACL”. Also we can insert multiple sequence in between our access-list sequence, here we will insert sequence 11 to 19 between 10 and 20.

N7k ACL1

We can resequence the ACL also by using “resequence ip access-list BIG-ACL [start-seq] [end-seq]” and we can verify our new restructured ACL.

N7k ACL2

We can use several Show commands like “show ip access-list”, ” sh access-list”to check our configuration like “, one cool command is “Show running-config aclmgr”

N7k ACL3

 

This exercise has been done on Nexus 7010 chassis with following pieces installed:-

  • Dual supervisor modules, dual power supplies, dual system fans, dual fabric fans, and three fabric modules per chassis.
  • One 48-port 1 Gigabit Ethernet I/O module per chassis.
  • One 32-port 10 Gigabit Ethernet I/O module per chassis with SFP+ SR optical transceivers installed.
  • Cisco NX-OS LAN Enterprise License.
  • Cisco NX-OS LAN Advanced Services License.

First we verify the hardware discussed above.

N7K Module

The above output shows One 48-port 1 Gigabit Ethernet I/O module and One 32-port 10 Gigabit Ethernet I/O module and three fabric modules per chassis installed  in the Nexus 7010. The rest of the hardware can be easily seen by our very old IOS familiar command “Show environment” and NXOS version can be seen by “Show Version” command.

Without AAA, IOS relies on privilege levels.  Privilege levels (0-15) defines locally what level of access a user has when logged into an IOS device, i.e. what commands are permitted.

  • Privilege Level 1 — Normal level on Telnet; includes all user-level commands at the router> prompt.
  • Privilege Level 15 — Includes all enable-level commands at the router# prompt.

NX-OS uses a different concept for the same purpose, known as User Roles. User Roles contain rules that define the operations allowed for a particular user assigned to a role. There are default User Roles:

  • Network-Admin—Complete read-and-write access to the entire NX-OS device (only available in the default VDC).
  • Network-Operator—Complete read access to the entire NX-OS device (Default User Role).
  • VDC-Admin—Read-and-write access limited to a VDC (VDCs are not yet available on Nexus 5000).
  • VDC-Operator—Read access limited to a VDC (Default User Role).

VDC(s) allow the partitioning of a single physical Nexus 7000 device into multiple logical devices. This logical separation provides the following benefits:

  • Administrative and management separation
  • Change and failure domain isolation from other VDCs
  • Address, VLAN, VRF, and vPC isolation

We will discuss VDC in detail in upcoming posts.

When a NX-OS device is setup for the first time, during the first login, a Network-Admin account must be specified and subsequently be used to login. Arguably a bit more secure that IOS. Any additional users created locally after that will by default receive the User Role “Network-Operator“, unless specified implicitly.

Note:-User Roles are local to a switch and only relevant in the absence of AAA being configured.

When logging into a N5K or a N7K system VDC, the default User-Roles assigned is “network-operator”. When logging into a VDC, the default User-Roles is “vdc-operator”.

Apart from above system default roles we can create custom roles as per our requirement.Lets create a new role AFROZ and assign read and write privileges to this role.

In the below figure we have created a new role AFROZ, assigned read and read-write privileges with feature-group L3-ROUTE , feature-group L3-ROUTE has all routing protocol feature.

N7k role

Additionally we can configure our role(AFROZ) to permit or deny a feature. Here we will deny all Vlans except the range 1-100 and deny all VRF instances except for vrf INTERSWITCH and Limit access to all interfaces except the first two 1 Gigabit Ethernet and port channel interface  and verify our configuration.

N7k role deny

Now we will assure that strong passwords are supported and that any roles are distributed
between adjacent Cisco Nexus devices. We will check our password strength by attaching the role AFROZ to a new user. Create a new user named “afroz” and assign the password “afroz123” obviously without quotes. As we have already enabled password strength now NXOS tells us that the current password it weak , so now we will assign a password Rbac@AFROZ, and now the NXOS system excepts it.

Then we will check the status of the configured “roles” and apply the user role configuration changes in the temporary database to the running configuration and distribute the user to role configuration by “role distribute” to adjacent nexus devices.

N7k rbac