This article will introduce some topics regarding the CCNA Data Center certification and more specifically, topics regarding the Nexus platform.

At the end of this article, you will:

* have knowledge about the Nexus hardware

* have knowledge about the NX-OS software

* have knowledge about the virtualization done on Nexus platform

The NEXUS platform was introduced by Cisco in 2008.

First, here is a short description of each of the models of the NEXUS platform:

* NEXUS 7000: modular switch which can come in four versions – with four slots, nine slots, 10 slots and 18 slots. It can provide end-to-end data center architecture by combining the data center core layer, data center aggregation layer and data center access layer.

* NEXUS 6000: comes in two models and can be used in data center aggregation layer.

* NEXUS 5000: comes in four models depending on the number of ports available and can be used in data center access layer.

* NEXUS 4000: comes in only one model and is a blade switch to be used with a 3 rd party vendor for blade servers.

* NEXUS 3000: comes in four models and delivers high density switching at ultra low latencies.

* NEXUS 2000: called fabric extenders and comes in four models. They cannot be used in standalone mode and have to be attached to another NEXUS platform (5000 or 7000) to be seen as a remote line card.

* NEXUS 1000v: is a virtual switch that is integrated in hypervisor virtualized platforms.

Let’s discuss a little bit about what we are going to find at the first contact with a NEXUS platform.

NX-OS Hardware



The NEXUS platform uses SFP for copper, SFP+ for 10G fiber links. Also, TwinAX cables are available to be used. Because the NEXUS platform can use links with speeds of 40G and 100G, one could use optical modules for those speeds as well.

The console port didn’t change and it’s based on the same principles as existed 10 or 20 years ago.

The NEXUS platform has a management port that is used solely for device management. The management port is separated from data ports and has its own IP address and routing table.

On the NEXUS platform, all interface names start with Ethernet, regardless of the speed of that interface. We no longer see FastEthernet, GigabitEthernet or TenGigabitEthernet. Therefore, Ethernet1/0 might have the speed of 1Gbps or 10Gbps, based on the SFP plugged in or the configuration.

Expansion modules are something that adds flexibility to the platform. The user can install modules for Ethernet or for Fibre Channel. The idea was that a single switch was able to handle both types of traffic: Ethernet and Fibre Channel. In the past, two separate switches were needed to handle this traffic.

Unified ports are a step further into the expansion modules. Using unified ports, the user can configure the same port for any of the Ethernet or Fibre Channel traffic. The difference is done by the type of transceiver inserted in the port.

NX-OS software



The operating system that is running on the NEXUS platform is called NX-OS. Cisco has built this operating system for high scalability and availability. NX-OS was designed with modularity, resiliency and serviceability in mind. NX-OS is based on SAN-OS, the Cisco Storage Area Network Operating System that runs on an MDS platform.

Also, the NX-OS is based on Linux kernel, which is a foundation of a reliable operating system.

The goals of NX-OS are to process three different types of information: layer 2 protocols, layer 3 protocols and storage protocols.

As one could have expected with modern networking operating systems, the control plane is separated from data plane to ensure high availability.

The high availability is managed by several system processes:

*System Manager: from a very high level view, this process is responsible for the overall state of the system. The System Manager monitors the health of the system, as well as the starting, stopping, restarting and monitoring of services. In addition to this, the System Manager is responsible for supervising synchronization and switchover if needed. The health of the System Manager is checked by a hardware watchdog timer found on the supervisor. If this timer expires and no keepalive is received from the System Manager, then a supervisor switchover occurs.

* Persistent Storage Service (PSS): this process consists of handling and storing operational information and configuration of various processes. Some processes are saving their current state periodically and in case of a process restart, they glean this information from PSS to restore the service to a pre-failure state.

* Message and transaction services (MTS): the purpose of this service is for the processes to be restarted independently and that in case of a restart; the messages from other processes are received by the restarted process.

Services in NX-OS can be restarted if they experiences errors or failures. The restart can be initiated by the operator or by the System Manager if an error condition is detected. Every process has a set of high-availability policies associated with it. The policies represent the way a system reacts to a failed service. These are the actions that System Manager performs:

* Stateful process restart: while the system is running, periodic checkpoints are saved in PSS. If the service stops responding to System Manager queries then the process is restarted and all the state information is gleaned from PSS.

* Stateless process restart: the service is restarted and PSS is not consulted for saved state information. The runtime information is rebuilt from scratch.

* Supervisor switchover: the active supervisor is rebooted and the standby supervisor takes over as the active supervisor. There are a few variables associated with System Manager course of actions. These are probably the most important two:

* Maximum retries: specifies the number of times the System Manager tries to perform an action before declaring the action as failed. For instance, the system might try three times to perform a stateful process restart, followed by three attempts to stateless restart the process, before initiating a supervisor switchover.

* Minimum lifetime: this is the time interval a process must run before the restart of the process can be declared a success. This interval is configurable, but it has to be at least four minutes.

This is what is happening with a process before and after restart:

* process state is saved in PSS

* the process is restarted automatically in case it is failing

* the restarted process is receiving from PSS the information from a pre-failure state

* in case the process fails to be restarted multiple times, a supervisor switchover occurs

the information about the event is logged and if configured, it can be sent to a remote location

Let’s trigger a restart of a process by using the cli command restart:

N7K-2# show processes | i rip 4460 S 415c4642 2 - rip - NR - 0 - rip - NR - 0 - rip - NR - 0 - rip N7K-2#

As you can see the RIP process has a process ID of 4460 and there is only one instance of RIP running. If we are going to use the restart command, then the running RIP process will have another PID:

N7K-2# restart rip 1 N7K-2# show processes | i rip 7284 S 415c4642 3 - rip - NR - 0 - rip - NR - 0 - rip - NR - 0 - rip N7K-2#

As you can see, the new PID is 7284.

You might wonder why the restart command is using the parameter ‘1’. This comes from the RIP configuration:

N7K-2# show running-config | section router router rip 1 address-family ipv4 unicast N7K-2#

NX-OS is using what is called conditional services. This means that various features of NX-OS are available, but they are not enabled. For instance, RIP is one of them. But as we already have RIP enabled, let’s try to discuss another protocol, OSPF.

With IOS configuration options in mind, one would try to configure in the same way as the NX-OS:

N7K-2(config)# router ospf 1 ^ % Invalid command at '^' marker. N7K-2(config)# router ? rip Routing Information Protocol (RIP) N7K-2(config)#

As you can see, it’s as if OSPF is not available on NX-OS, but actually the service is not enabled. In NX-OS, this is how you can see if a feature is enabled:

N7K-2# show feature | i ospf ospf 1 disabled ospf 2 disabled ospf 3 disabled ospf 4 disabled ospfv3 1 disabled ospfv3 2 disabled ospfv3 3 disabled ospfv3 4 disabled N7K-2#

This is how you enable a feature in NX-OS:

N7K-2# conf t Enter configuration commands, one per line. End with CNTL/Z. N7K-2(config)# feature ospf N7K-2(config)# router ospf rip N7K-2(config)# router ospf 1 N7K-2(config-router)# N7K-2(config-router)# exit N7K-2(config)#

With this in mind, it’s better to use the ‘show feature’ command to check if a feature that you want to use is enabled and to avoid spending time trying to understand why a feature is not configurable although you have seen it in the documentation.

Virtualizing the network



We’ve all heard recently about virtualization, but what is it? While there is no exact definition, in our context of networking, it is something logical that is replacing something physical. This means you can use less and newer hardware with advanced software to replace the bulk of old hardware.

We are all familiar with VLANs. They provide a logical separation within a switch into multiple groups. The hosts from each group are part of the same broadcast domain and they are part of the same subnet. This allows you to deploy only one switch in the network and logical partition the switch based on your needs. You avoid the deployment of a separate switch for each group.

Let’s go a little bit further. Let’s say you have two switches, each with two VLANs and the users from one switch have to communicate with the users from the other switch. You would need two links between the two switches, one for each VLAN. By using only a single link and configuring that link as trunk (tag the packets for each VLAN), you would accomplish the same thing, but would reduce the number of links between the switches.

We all know what a routing table is. Based on its content, the router forwards the packets. There are situations where you want the router to forward traffic differently for particular users than for others. In this case, we would use the Virtual Routing and Forwarding (VRF) notion. Each VRF creates a separate routing table and interfaces are associated to this VRF. Therefore, each time the router receives packets from hosts connected to these interfaces, it will use that particular VRF table to forward packets. The VRFs can become much more complicated than this, but for the moment, keep in mind that you can use the same IP addressing as the VRF if they are completely separated. For instance, the IP 1.1.1.1 from VRF1 is different from IP 1.1.1.1 from VRF2.

By default, the NX-OS has two VRFs: the management and default. All Layer 3 interfaces and routing protocols are in the default VRF. The mgmt0 interface is part of the management VRF and cannot be moved to another VRF.

This feature still has some drawbacks when it comes to the complete separation of administrative control. To achieve this, NX-OS introduced Virtual Device Context (VDC).

The VDC is supported only on NEXUS 7000 and allows the partitioning of a single physical device into multiple logical devices. This separation has the following benefits:

* administrative and management separation

* failure isolation from other VDCs

* addressing, VLAN, VFR separation

The Cisco NEXUS 1000v is a software-based Cisco NX-OS switch with features designed for integration with VMware vSphere environments. The NEXUS 1000v operates inside the VMware hypervisor.

References:

