UCS 2.0(1q) Patch Released

[Robert Burns]

Greetings All,

The UCS 2.0 patch 2.0(1q) has been released which addressed a couple major bugs detailed in the thread here.

Release Notes:

http://www.cisco.com/en/US/docs/unified_computing/ucs/release/notes/OL_25363.html#wp232083

Software:

http://www.cisco.com/cisco/software/release.html?mdfid=283612660&flowid=22121&softwareid=283655658&release=2.0%281q%29&relind=AVAILABLE&rellifecycle=&reltype=latest

Highlights of major issues fixed:

-Using the UCSM GUI, you are now able to disassociate a service profile that is currently bound to a template. (CSCts95454)

-When you assign an org to a locale from the GUI, the operation sometimes   fails due to an internal error.  This error is now corrected.   (CSCts60863)-The PCI Device address of a VNIC will not change after an upgrade of UCS   Manager from Release 1.x to Release 2.0(1q). (CSCts96949)-When the DHCP server is using an option 67 (RFC 2132) to report the  bootfile  name to the gPXE client, gPXE will receive the boot parameters  and the  boot will function normally. (CSCts86689)-When the BIOS is upgraded on a B230-M1 blade from Release 1.x to Release 2.0, the PCI address is preserved. (CSCts86890)

-B230-M1 blade discovered while running 1.4 BIOS release image and now   running a UCS 2.0 release BIOS image will associate and disassociate   normally. (CSCtj54470)

-A Blade with a service profile with a 22 character or longer name will   boot as expected from the local disk after upgrading the BIOS from a  1.x  release to the BIOS in the 2.0(1q) release. (CSCtt13313)

Any issues with this release, please let us know.

Regards,

Robert

[KRIS PATE]

Hi Robert,

  I posted a few months back on the apache vulnerabilities in UCS manager.  Can you tell me which apache version is running in this latest firmware?  We are currently running 1.4(3q) and our security guys have flagged us for two vulnerabilities. One is a DoS vuln and the other is a SSL cipher strength where they expect everything to be higher than 112 bit key.

Are these still issues in 2.0(1q)? Are they still planning on making it easier to find out what Open Source software is in each release?

Here is the link for the Apache DoS vuln:

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3192.

[Robert Burns]

Hey Kris - yes I recall your previous post.

I had them post the Open Source details on CCO:

http://www.cisco.com/en/US/products/ps10477/prod_technical_reference_list.html

This is current for 1.4, let me see if there have been any changes in 2.0 and I'll get back to you.

Stay Tune!

Robert

[KRIS PATE]

Thanks Robert,

Staying tuned......

Kris

[KRIS PATE]

Hi Robert,

  Any word on these vulnerabilities?

Kris

[Robert Burns]

Sorry for the delay Kris.  This feel under my radar.

I just bumped the docs team once more to update the doc.  I'll let you know once it's done.

Robert

[Robert Burns]

Here you go!

http://www.cisco.com/en/US/docs/unified_computing/ucs/3rd-party/UCS_2_0_1_Open_Source_Documentation.pdf

Available under:

http://www.cisco.com/en/US/products/ps10477/prod_technical_reference_list.html

Regards,

Robert

[KRIS PATE]

Robert,

  Thanks for the updated document.

Do you know if this vulnerability is fixed in 2.0s? 

cisco-sa-20110830-apache

I can't find a reference to which UCS version it is fixed in or a reference to it being fixed in the 2.0 release notes.

Kris

[Robert Burns]

Kris,

That advisory was first addressed in 2.0(1m) which was superceeded by 2.0(1s).   Running this latest version adresses this vulnerability.

Regards,

Robert

[simon.geary]

I've done a couple of upgrades to 2.0(1q) now. All using vSphere 4.1 and all went without a hitch.

One annoyance though. The new iSCSI IP address pool is empty by default and cannot be deleted, and so gives a spurious warning message that it has no free addresses. The only way around this seems to be to create some dummy iSCSI addresses in the pool to make the warning go away, even if you are not using them.

[Jeremy Waldrop]

I have also done a few upgrades to 2.01q and have had no issues.

The iSCSI address pool is a bit annoying though. I too have been adding a single IP to the pool so that the fault goes away.

One welcomed change to 2.01q is the ability to disassociate or change the server profile association when profiles are deployed from an updating template that is associated with a sever pool. Previously these options were grayed out so I hadn't been associating my service profile templates with server pools. I would deploy the profiles from the template then multi-select the profiles and associate them with a server pool.

[Robert Burns]

Simon & Jeremy,

Thanks for the feedback & please keep it coming if you find anything else you feel could be improved.

As with any resources, MACs, WWNs, UUIDs, any pools which are empty will "bark" an alarm.  Including the new iSCSI IP Pool.  As soon as the IQN pool is added in a future release, that will require population also, or you just ignore the alarm.

Regards,

Robert

[gballard]

Not sure if it's applicable to post here, but since applying 2.01s I've been getting flogi errors. Most of the time they go away, but I have one that has stuck. Supposedly they are cosmetic and there is an open bug on this.

------------------------Example Below---------------------

descr="fc VIF 1 / 7 B-2511 down, reason: waiting for flogi"

dn="sys/chassis-1/blade-7/fabric-B/path-1/vc-2511/fault-F0283"

[chrisb2]

Grant,

You can verify that it's only cosmetic by doing the following:

1) SSH into your FI's

2) Issue the following commands:

connect nxos b

show interface brief

And look for interface 2511 (you could also use show interface brief | grep 2511 to show only that line but then you wouldn't have the headers)

You could also do a "show flogi database" on the upstream switch and look for that vfc's WWPN.

Here's the bug I think you were told you were hitting:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtn89396

[gballard]

Thanks a lot Chris. Very helpful. I confirmed it was cosmetic and coincidentally rebooted that host and the flogi error went away. So, at least I didn't have to reset the upstream switch