No ISSU for you!

The Nexus 5000 series has the capability to do ISSU, an In-Service Software Upgrade. You can upgrade a vPC pair of Nexus 5000s without impacting any hosts (assuming everything is dual connected). Well, that is, unless you are using Windows Server 2012 with LACP. Let’s take a look at some show command output, shall we?

Nexus6# sh lacp issu-impact
For ISSU to Proceed, Check the following:
1. All port-channel member port should be in a steady state.
2. LACP rate fast should not be enabled on satellite member ports.

The following ports are not ISSU ready
Eth1/28     ,

OK, so Eth1/28 is going to prevent an ISSU because of an LACP issue, let’s check out the LACP details.

Nexu6# sh lacp interface e1/28
Interface Ethernet1/28 is up
  Channel group is 28 port channel is Po28
  PDUs sent: 21679
  PDUs rcvd: 750
  Markers sent: 0
  Markers rcvd: 0
  Marker response sent: 0
  Marker response rcvd: 0
  Unknown packets rcvd: 0
  Illegal packets rcvd: 0
Lag Id: [ [(0, 90-e2-ba-23-9e-8c, 0, 0, 100), (7f9b, 0-23-4-ee-be-2,
801c, 8000, 11c)] ]
Operational as aggregated link since Tue Jul 23 15:00:18 2013

Local Port: Eth1/28   MAC Address= 54-7f-ee-ef-cd-ab
  System Identifier=0x8000,54-7f-ee-ef-cd-ab
  Port Identifier=0x8000,0x11c
  Operational key=32796
  LACP_Timeout=Long Timeout (30s)
  Partner information refresh timeout=Short Timeout (3s)
Actor Admin State=(Ac-1:To-1:Ag-1:Sy-0:Co-0:Di-0:De-0:Ex-0)
Actor Oper State=(Ac-1:To-0:Ag-1:Sy-1:Co-1:Di-1:De-0:Ex-0)
Neighbor: 0x100
  MAC Address= 90-e2-ba-23-9e-8c
  System Identifier=0x0,90-e2-ba-23-9e-8c
  Port Identifier=0x0,0x100
  Operational key=0
  LACP_Timeout=short Timeout (1s)
Partner Admin State=(Ac-0:To-1:Ag-0:Sy-0:Co-0:Di-0:De-0:Ex-0)
Partner Oper State=(Ac-1:To-1:Ag-1:Sy-1:Co-1:Di-1:De-0:Ex-0)

You’ll notice that the LACP_Timeout values in bold do not match between the Local Port and the Neighbor. We need both ends set to the long timeout for ISSU to be happy. The LACP neighbor is a Windows Server 2012 box using switch dependent NIC teaming (LACP). We researched and were unable to find a way to tweak this timeout setting. This means you either run your Windows Server 2012 NIC team in switch independent mode (works the same as ESXi without LACP) or you don’t get to do ISSU… Somewhat defeats the whole point, no?

[UPDATE: Microsoft has since released a hotfix that allows you to change the timeout:]

This problem also crops up with Linux hosts, but at least Linux lets you change the timeout. Getting your Linux admins to make the change may be another issue…


Is Windows Rubbish? Is Mac the Solution?

[This is a lightly edited comment I made in response to Greg Ferro’s blog post, Windows Tools Aren’t Worth Selling. In a nutshell, Greg argued that Windows and Microsoft software are known to be defective and you should switch to Mac for security, stability, and cost savings.]

On by Guillermо via flickr

I will not argue that the Mac is not fant­astic, but I will argue with this gen­eral sen­ti­ment that everything Microsoft/​Windows is rub­bish. I won’t bother arguing the qual­ity of pre­vi­ous ver­sions of the soft­ware, but Windows 7 is stable and fast. While Windows may lack some of the eleg­ance of MacOS X, the secur­ity and sta­bil­ity of these two mod­ern oper­at­ing sys­tems is com­par­able. In 2 years I have had 2 crashes across 4 Win7 machines. None have had the need to be rein­stalled (such as seemed neces­sary every 6 months with XP). Both crashes were related to bad drivers, which is the source of most prob­lems on Windows boxes.

Windows 7 does not crash every day. It very rarely crashes. This seems sim­ilar to MacOS.

Windows 7 also has a quite good backup mech­an­ism built in. Totally dif­fer­ent than the garbage in earlier versions.

Win7 certainly does have the limit of not having the full suite of extremely use­ful UNIX tools and a POSIX envir­on­ment. I spend a lot of time in a ter­minal win­dow con­nec­ted to a Linux box or on a Linux VM. I find this preferable to having to run most of my tools in a VM (since most of my tools are written for Windows) as I would have to on a Mac. This, of course, depends on per­sonal taste and how your apps run in a VM as well as how many apps you would need in a VM. Having to run Windows in a VM is going to cost you a lot more RAM than running a Linux box in a VM.

The hard­ware to run Windows is cheaper than equi­val­ent Mac hard­ware. On the other hand, the quality of the Windows hard­ware is not as good and you will occa­sion­ally run into issues with drivers. MacOS should not have that problem.

Use the tool that works best for your needs. Weigh your options and needs, and choose the tool that works best for you. Fear of chan­ging to the unknown is a lousy reason to stick with Windows. If the tool isn’t work­ing for you, try a dif­fer­ent tool. Anti-​​Microsoft/​Windows FUD is an equally lousy reason to switch to Mac. Curiosity is a per­fectly good reason and I’d encour­age that, but expect a learn­ing curve and frus­tra­tion with the Mac Way.

That state­ment regard­ing com­pan­ies stick­ing with known defect­ive products for fear of the unknown and fear of cost when things could be improved by switch­ing to Mac is FUD. That will totally depend on the organ­iz­a­tion and is hardly a valid gen­er­al­iz­a­tion. I’ve seen admins try­ing to man­age thou­sands of Macs. It’s no easier or cheaper than man­aging Windows boxes. You often end up hav­ing to deploy VMs to sup­port Windows applic­a­tions. You have a train­ing night­mare because at this point most people know Windows, but a small (but growing) minor­ity knows the Mac. I can see the poten­tial for a small or highly tech­nical organ­iz­a­tion to save money in the long run with Apple, but I think that’s the exception right now.

I’m not a con­sult­ant or field engin­eer, so I can’t speak to policies regard­ing con­nect­ing the prohibition of connecting Windows laptops to other net­works, but I would say this requirement falls under use the right tool for the job.