4.0(4)SV1(4) status

[cweinhold]

Does anyone know the current ETA on Nexus 1000v 4.0(4)SV1(4) ?

Is there a list of committed features?  ISSU and Queueing?

[Robert Burns]

We're targetting before the end of the year.

Some of the key new features include:

- VMware Binary compatability (can upgrade VMW code [4.0 U2 or later] w/o having to upgrade VEM bits)

- Hitless Upgrade (from SV1.3 and onward)

- Increased limits of VLANs and Port profiles to 2,000 each

- vPath Support (for use with VSG and other service blades)

- Network State Tracking

- LACP Offload (my favorite new feature!)

- Hardware iSCSI support

- SPAN/ERSPAN of Port profiles

- ACLs on SNMP & Management Interface

Regards,

Robert

[dseaman619]

Well it's 1/1/11 and no 4.0(4)SV1(4). Maybe next week! I did see the FAQ was updated with a mention of ISSU for 4.0(4)SV1(4).

[Robert Burns]

There were some last minute refinements decided to be included in SV1.4, so the date as been slightly delayed.  New tentative target is end of Jan.

Regards,

Robert

Updated: Jan. 16, 2011

[cweinhold]

Robert,

Your list of 1.4 fetures did not include queueing (e.g., CBWFQ). What's the status there? We're having a hard time justifying the use of N1Kv for UC virtualization, and have also been leaning towards ESX 4.1's built-in NetIOC for throttling vmknic activity like vMotion. We're really hoping that N1Kv 1.4 would fix this.

BTW, what is LACP offload? Does it require certain NIC's?

Thanks,

-Craig

[Robert Burns]

Craig,

The list I posted were just"some" of the features, saving some for surprise.

In regards to QoS Queing (WFQ), this will be supported on VEM Uplinks (Egress) - and will require vSphere 4.1 or later.  16 traffic queues per VEM can be configured with a queue hard limit or relative "share" of available bandwidth.  This should make your life MUCH easier with pre-defined match protocols for:

- VMotion

- iSCSI

- FT

- HA

- NFS

- Management (vSphere)

- Control (1000v)

- Packet (1000v)

- Management (1000v)

As for LACP offload, we've added an improved option for 1000v LACP negociation..  Previously the VSM was involved in the bring up of LACP port channels. LACP offload will allow the VEM's to negociate LACP themselves in the event the VSM is not communicating with the VEM modules (called headless mode).  When the connection between VSM and VEM is restored this will be seamless, assuming there have been no configuration changes on the uplink port profiles.  The other advantage LACP offloading is the support for LACP channels on a single VEM uplink carrying system VLANs. There are no unique NIC requirements to support this feature as it's software based.   LACP Offload will be disabled by default (for upgrades to 1.4) and will be on by default for fresh 1.4 deployments.

Regards,

Robert

[dseaman619]

Robert, those are great features! In a HP Flex-10 environment will the QoS queuing be fully supported, given the flex-10 module doesn't support QoS packet tagging? Given your description, it sounds like the VEM is not relying on packet tagging and does the rate limiting internally, which should mean it works with any environment even those without hardware QoS support?

[Robert Burns]

Correct.  All the QoS functionality is done within VEM software internally to the host and will be applied up to the egress out the physical NIC.  Beyond that Virtual Connect would not honor the tag and would treat the traffic on a FIFO basis.   If you had an upstream switch that did support QoS/CoS, they could honor the tagging set by the 1000v.

Regards,

Robert

[dseaman619]

Will Cisco publish any recommended WFQ settings? For example, allocate fixed xx Mbps for vSphere management, but use shares for vMotion and FT? Obviously every environment varies widely, but some basic recommendations to start from would be welcomed. 

[cweinhold]

Robert,

Sorry to pound you with questions...

Will "shape" be supported?   (the "queue hard limit" you mention sounds like today's policing)

Will "priority" be supported?

Will "fair-queue" work and, if so, will it work in any class or just class-default?

How is the bandwidth of a port-channel calculated and reported when MAC pinning is used?

Is it safe to assume that any legal combination of ingress/egress service-policies will work, so long as only the egress uplink service-policy has "bandwidth" or "priority" commands? E.g., the various VM port-profiles could use different ingress service-policies that set unique qos-group/COS/DSCP values, and the single system-uplink egress service-policy would act upon these values.

Thanks in advance!

-Craig

[Robert Burns]

I'll address what I can, and allow others to chime in.

WFQ is a new feature to 1000v so there will be a limited subset of QoS features than you might have on physical switches.

Shaping/Priority may be introduced in a later version. The two options for applying QoS will be bandwidth percentage or queue size limit (in packets)

Fair-queue or what will be called Dynamic Fairness will be implemented.

The bandwidth for an uplink in a mac-pinned port channel will be allocated bandwidth according to the individual link.  Though mac pinning provides an aggregate bandwidth, QoS queing will be applied on an individual uplink basis porportional to that uplinks bandwidth (as a percentage).  This will prevent flows (ie VMotion) from monopolizing a percentage of an aggregate Port Channel when only a single uplink will be utilized for that flow. Dynamic Fairness will provide additional bandwidth guarantees in some instances like this assuming queues on other uplinks are provide with their bandwidth gaurantees.

Class of Service tags can be applied at the vEth port profile level, and then acted on their egress Uplink Port Profiles.

Hope this helps.

Robert

[ikescisco]

Four more days...holding breath!

[Robert Burns]

Greetings All,

We appreciate everyone's patience while the finishing touches were put on version 1.4 - which is now available on CCO:

http://www.cisco.com/cisco/software/release.html?mdfid=282646785&flowid=3090&softwareid=282088129&release=4.2%281%29SV1%284%29&rellifecycle=&relind=AVAILABLE&reltype=latest

SV1.4 Release Notes Available here:

http://www.cisco.com/en/US/partner/docs/switches/datacenter/nexus1000/sw/4_2_1_s_v_1_4/release/notes/n1000v_rn.html

See early thread posts for summary of new features.

Note: When searching for the 1000v software, search under:

Products -> Switches -> Data Center Switches -> Cisco Nexus 1000v Series Switches -> Cisco Nexus 1000v Switch -> Software on Chassis

Best of Luck & Enjoy!

Regards,

Robert

[alonzo.garza]

Can somebody PLEASE tell me how to "UNSUBSCRIBE" from these Nexus 1000v e-mail threads?

I've already edited my profile many months ago and created e-mail rules to block these messages but for some reason, I cannot unsubscribe from these threads?

Can someone please let me know how to unsubscribe, I no longer need to receive any e-mails from any of you concerning Nexus 1000v?

Where is Han?  Can he help?

Thank you,

-Mr. Garza

[alonzo.garza]

Can somebody PLEASE tell me how to "UNSUBSCRIBE" from these Nexus 1000v e-mail threads?

I've already edited my profile many months ago and created e-mail rules to block these messages but for some reason, I cannot unsubscribe from these threads?

Can someone please let me know how to unsubscribe, I no longer need to receive any e-mails from any of you concerning Nexus 1000v?

Where is Han?  Can he help?

Thank you,

-Mr. Garza