Nexus 7000

From Internetworkpro

Jump to: navigation, search
Cone.png This page is currently in progress and is not completed
Please note that the information on this page is pending completion by the author. You can help contribute by using the edit tab above.
See where else you can help at Category:InProgress
Architecture.gif This page or section contains architectural information
Please note that this page or section contains information on the architecture of a product or software and may be inaccurate, confidential or unsupported by the vendor. Any stated capabilities or future roadmap information may be dependent on software and hardware modules.
Nexus 7000
Nexus 7000.jpg
A Nexus 7010 (10 slot chassis)
Manufacturer: Cisco Systems
Design: Modular, chassis based
Positioning: Aggregation, Datacentre
Throughput: 480mpps (1st gen ASIC)
Switch Fabric: 115Gbps per slot (1st gen fabric)
Max Ports: 48x16 (768) 10/100/1000, 32x16 (512) 10GE
The Nexus 7000 is a chassis-based multi-layer high performance, high density switch. Initially designed to be deployed in the datacentre, the Nexus 7k is the natural successor of the Catalyst 6500.

Unlike the Catalyst 6500, the architecture is entirely distributed. Today it is capable of over 480mpps and 1.2Tbps system-wide performance with future scalability of 2000mpps and 4.1Tbps. Furthermore, the system does not run Cisco IOS software, but NX-OS, a linux-based operating system derived from SAN-OS.

Contents

[edit] Overview

The system comprises of the following major components:

As the Nexus 7000 is a fully distributed switching system, all forwarding decisions are made on the I/O modules. This includes traffic such as BPDUs, BFD and so on.

This article will describe the packet flow of the Nexus 7000 and then go through the major system components. Finally, it will cover notable features of the platform.

[edit] Packet Flow

[edit] Forwarding Model

The Nexus 7000 is a fully distributed switch. As with all Cisco routers and Switches, it uses CEF. The routing table will calculate a Routing Information Base (RIB) of all possible routes from all possible routing protocols. It will then apply various rules (such as filters, priorities, etc) and compile the Forwarding Information Base(FIB) which is a list of the best possible routes. Each FIB entry contains a pointer to the adjacency table, which provides information such as egress port or ports, MAC address rewriting and any associated egress access lists or QoS. In the case that a route has more than one egress port (e.g. a multi-path route) then the adjacency table will point to a hash which the switch will run to determine the output port.

The FIB and adjacency table (along with the ACL, QoS and all other forwarding information) will then be propagated throughout the switch and stored in the TCAM memory on each line card. Any routing updates (such as a change in adjacency) will cause the FIB to be rebuilt and propagated back out. This process is done independently on each VDC.

[edit] Forwarding Process

Upon ingress a packet will be buffered by the incoming port ASIC and have ingress QoS and ACLs applied to it. Any ingress policing will also take place. The ASIC will then do a layer 2 or 3 forwarding decision based on the incoming packet by checking the destination MAC address. If the MAC address is its own, a layer 3 operation will take place, otherwise a layer 2 operation will occur.

Having applied ingress ACLs and QoS, the lookup will check the destination port and do the appropriate rewriting. At this stage, all egress activity is performed on the ingress line card. That is to say that once a packet leaves the ingress line card it will not be rewritten, queued or changed. All actions (ingress and egress) are done in the ingress card before hitting the fabric. Once the packet has hit the fabric, it will immediately be sent out of its destination port.

At this stage, the ASIC will check with the central arbiter if it can send and once permitted it will send its data to the egress line card.

[edit] Central Arbiter

The central arbiter resides on the Supervisor and controls which packets are permitted on to the fabric. It works by maintaining a bit bucket of egress buffering for each line card. When a packet wishes to be sent from one port to another, the central arbiter is consulted and if there are enough tokens then the packet is sent. If not, it will be queued until the port is free.

The arbiter handles priority traffic and multicast (see below) and is always run in parallel with the redundant supervisor (e.g. active/active). In the event that the two arbiters give conflicting decisions then the active supervisor takes precedence.

[edit] Multicast

Multicast traffic on the Nexus 7000 works in a similar way to Unicast. Replication however occurs in the fabric, with each line card having an expansion table to direct traffic to the appropriate egress ports.

The Central Arbiter in this case can be configured in two ways. The first is to only send multicast traffic if all destinations have the capacity to receive it. The second is to send multicast traffic to those destinations that are free, when they are free.

[edit] Chassis

Nexus 7010 Chassis
There are currently two chassis available; the 7010 and the 7018.
Chassis Rack Units # Slots Supervisors I/O Modules Fabric Modules Airflow Notes
Nexus 7010 21 RU 10 2 8 5 Front-to-Back Original Chassis
Nexus 7018 25 RU 18 2 16 5 Side-to-Side


[edit] Supervisor

[edit] Components

The Nexus 7000 supervisor is comprised of three major areas.

[edit] Architecture

The Supervisor is responsible for almost all control plane functionality within the switch. This includes (but not limited to):

General layout of the supervisor:

N7ksuplayout.png

[edit] CMP (Connectivity Management Processor)

The CMP resides on each supervisor as a lights-out remote management station. It comprises of

The CMP is capable of accessing major system logs and can power up and down the switch. In addition, it can jump in and out of the console environment providing a reliable connection in to the switch.

[edit] Supervisor Engine 1

Supervisor 1 is the first generation supervisor engine for the Nexus 7000.

[edit] Specifications

[edit] I/O Modules

Incomplete, but a start:

Each linecard embeds one (two in some cases) local forwarding engine. Various models are described here:


[edit] Forwarding Engines

[edit] Linecards

LineCard Forwarding Engine Ports Queues per port Scheduler Port buffers Notes
N7K-M132XP-12 M1 32 SFP+ 10Ge i:8q2t, e:1p7q4t DWRR,SRR i:1+65MB e:80MB
N7K-F132XP-15 F1 32 SFP/SFP+ 1Ge/10Ge i:4q4t,2q4t e:1p3q1t,2p2q1t,3p1q1t,2p6q1t,3p5q1t,1p7q1t DWRR  ? not available on DCT as of 20100912
N7K-M108X2-12L 2x M1-XL 8 X2 10Ge i:8q2t, e:1p7q4t DWRR,SRR i:92MB,e:80MB
N7K-M148GT-11 M 48 RJ45 10/100/1000 i:2q4t, e:1p3q4t DWRR,SRR i:7.56MB,e:6.15MB
N7K-M148GS-11 M 48 SFP 1Ge i:2q4t, e:1p3q4t DWRR,SRR i:7.56MB,e:6.15MB
N7K-M148GS-11L M1-XL 48 SFP 1Ge i:2q4t, e:1p3q4t DWRR,SRR i:7.56MB,e:6.15MB

[edit] Reality check

That's from the various pres and datasheets. Now, let's check what's available on DCT as of 20100912:

No -15 available. sigh.

[edit] Fabric Modules

Horizontal fabric cards (blue) intersect the vertical line cards (orange) in a Nexus 7010

TBD

[edit] Power and Cooling

TBD

[edit] Notable Features

[edit] Virtual Device Contexts

TBD

[edit] Virtual Port Channels

TBD

[edit] Overlay Transport Virtualization

TBD

[edit] Data Center Interconnect

TBD

Cisco Switches
Retrieved from "http://www.inetpro.org/wiki/Nexus_7000"
Personal tools
Namespaces
Variants
Actions
Navigation
Categories
Toolbox