As is typical in the world of IT, problems have a way of sneaking up on you when you least expect it, then viciously attacking you with a Billy-club.  Often this happens when you are asleep, on vacation, severely inebriated, or have already worked 40-hours straight with no sleep.  In my case, Super-Bowl Sunday at around 8:30pm was my time to get the stick.  And get it I did.

For reasons too sad to warrant comment, and far too irritating to explain in a family forum like this, our ESX host servers all became disconnected from our SAN array.  The root problem was something else on layer-2, and got resolved quickly, but the virtual world was not so quick to recover.  In retrospect, the problem was not a bad one, but when you’ve been drinking and can’t see the obvious answer you tend to dig the hole you’ve fallen into deeper rather than climb promptly out.

By way of background, we are currently running VSphere 4.0, with a few servers having 32GB or memory and 8-cores, and a few having 512GB of memory and 24-cores. All ESX Hosts are SAN booting using iSCSI initiators on a dedicated layer-2 network.  We use Nexus 1000v soft switches and have our ESX Hosts trunked using 802.1q to our Core (6506-E switches running VS-S720-10G supervisors).  Everything is redundant (duplicate trunks to each Core switch) and using ether-channel with mac-pinning).  So there you have that, for what it’s worth.  Now back to the crashed servers.

We rebooted all of the ESX host servers, and with the exception of some FSCK-complaining they all came up quite nicely.  The problem was that none of the virtual machines came up.  Let me add that we have the domain controllers, DHCP, DNS, etc. on these hosts.  Crap.

So the first thing I did in my addled state was to add DHCP scopes to the DHCP servers at another office across the country, and point the VLANs off “that-a-way” by changing the ip helper-address on each VLAN on the Core.  That got DHCP and DNS back online.  As you can probably guess by now, I was MacGyver-ing the situation nicely, but really didn’t need to.  That’s one of the problems when you’re in the trenches: you tend to think in terms of right-now instead of root cause.

The next thing I did was to start bringing up the virtual machines one-by-one using the command line on the ESX hosts.  Why?  Because I had no domain authentication and the VSphere Client uses domain authentication.  Here is where someone in a live talk would be interrupting me to point out that the VSphere Client can always be logged into using the root user of the hosts, even when domain authentication is set up for all users.  Yes, that is true and it would have been handy to know at the time.

In order to bring up the virtual machines, I had to first find the proper name by issuing:

vmware-cmd –l

from the command line.  This command can take a while to run, especially if you have a lot of VMs sitting around, so go get a cup of coffee.

Once I had that list I prioritized the machines I wanted up first, and issued the:

vmware-cmd //server-name.vmx start

command on each one.  That should have been the end of the boot-up drama, but it wasn’t.  As it turns out, a message popped up (and I don’t remember the exact phrasing) to the effect of “you need to interact with the virtual machine” before it would finish booting.  So, now I issued the:

vmware-cmd //servername.vmx answer

command and got something that looked about like this:

Virtual machine message 0:

msg.uuid.altered:This virtual machine may have been moved
or copied.

In order to configure certain management and networking
features VMware ESX needs to know which.

Did you move this virtual machine, or did you copy it?

If you don't know, answer "I copied it".

0. Cancel (Cancel)

1. I _moved it (I _moved it)

2. I _copied it (I _copied it) [default]

Well, I didn’t know so I selected the default option (I copied it) and went on my way.  That is fine in almost every circumstance and got all of my servers booted up.  It did not, however, entirely fix the problem.  In fact, even though all of my servers were booted, none could talk or be reached on the network.

This is where a little familiarity with the Nexus 1000v soft switches comes in handy.  Very briefly, the architecture is made up of two parts: the VSM or Virtual Supervisor Module and the VEM or Virtual Ethernet Module.  The VSM corresponds roughly to the supervisor module in a physical chassis switch, and the VEMs are the line cards.  The interesting bit to remember for our discussion is that the VSMs (at least two for redundancy) are also Virtual Machines.

Some of you may have guessed already what the problem turned out to be, and are probably chortling self-righteously to yourself right about now.  For the rest of us, here’s what happened:

I figured out the log-in-using-root thing and got the VSphere client back up and running (oh, not before having to restart a few services on the Virtual Center Server, which is not a virtual machine, by the way.  I’m not totally crazy!).  Once I got that far I could log in to the Nexus VSM, and look at the DVS to see what was going on.  All of my uplink ports (except for ones having to do with control, packet, vmkernel, etc.) were in an “UP Blocked” state.

The short-term fix (again, the MacGyver job) was to create a standard switch on all hosts and migrate all critical VMs to that switch.  That didn’t, however, fix the problem permanently and besides, we like the Nexus switches and wanted to use them.  With that in mind, and a day or two to normalize the old sleep patterns, I set up call with VMware support.  This actually took longer than I expected since I had to wait for a call-back from a Nexus Engineer, and they are apparently as rare as honest sales-people or Unicorns.  That said, I did get a call back and we proceeded to troubleshoot the problem.

One thing that surprised me was that it took the Nexus Engineer a bit longer than I would have thought to find the problem, but even once he did it took longer to get resolution because we had to get Cisco involved.  The problem, as it turns out was licensing.

When you license the Nexus, you receive a PAK and you use that to install the VSM.  Once you do that, you have to request your license using the Host UID of the now installed VSM.  Cisco then sends you a license key that you install from the command-line of the VSM.  This is all somewhat standard and not surprising.  What was surprising was that we would have to do this at all considering we had been licensed at the highest level (Enterprise, superdy-duperty cool or something) for years.

What happened was that the copy VSphere made in order to get each Virtual Machine back up after our crash changed the Host UID of the VSM virtual machine(s).  Thus, the license keys were no longer valid and all host uplink ports went into a blocked state.  (I’ll save you the obvious gripe I have with the Nexus not offering any kind of command-line message about our licensing being hosed.)  This is where we had to get Cisco Licensing involved, as we had to send them the old license key files and the new Host-UID information so that they could generate new keys.  Considering I was only on the phone with them for only 15 minutes, it was as pleasant an experience as I’ve ever had dealing with Cisco’s Licensing department.  At least that’s something.

After fixing the licensing, the ports unblocked and I went through the tedium of adding back adapters to the Nexus, moving servers, etc.  At the end of the day, however, it is all back to normal and working.  There are a lot of lessons learned here, and you’ll no doubt pull your own, but the one overriding thing to be on the lookout for is that, under certain circumstances, if your Nexus VSMs are part of a crash and come back up, look to licensing first before troubleshooting anything else.  Oh, and try to schedule your major system crashes for a more convenient time… when you’re sober.  Just saying.

Incoming search terms for the article:

• Reset triggered due to HA policy of Reset
• Reason: Reset triggered due to HA policy of Reset
• nexus Reset triggered due to HA policy of Reset
• is 1000v worth it?
• 1000v cisco crash
• cdp hap reset
• reset triggered due to ha policy of reset n7k
• service: cdp hap reset
• reason reset triggered due to ha policy of reset
• virtual machine packet altering

Back from China

After roughly one week in Shanghai, China to set up a new site on our corporate network, it is painfully apparent that I need to get back into this writing business.  The dates on my posts belie my weak attempts at covering up my laziness.  That said, there were at least a couple of things of note worth using up a few words on.

Note One (where it really is someone else’s fault)

Due to an unfortunate series of poor decisions, poor project management, and a quite sudden and unreasonable expectation of delivery dates, we [IT] were forced to poach some bandwidth from a sister company of ours who had a slight excess in the manufacturing facility where our new office was to be set up.  By slight, I mean exactly 256kb.  For those of you not accustomed to seeing the abbreviation for kilo, well, you’re too young.  More on that in a moment.

All of that aside, we engineered the circuit all the way from the provider’s edge in Shanghai, back to our facilities on the West Coast and verified traffic was flowing.  Once we got to Shanghai and hooked up our router and started building out the network behind it, we noticed that we couldn’t move any traffic at all.  With a quick extended ping using the inside network interface as the source, as well as some trace-routes from other places, we verified that the provider had neglected to put a route in the BGP tables for the new network.  Thank God for 24-hour NOC support, and within 30 minutes that problem was resolved.

Note Two (where the author tries to check the turn-signal fluid)

As we moved on to creating and joining up a shiny new R2 Read-only Domain Controller (RODC) everything went off the rails.  Timeouts galore.  DNS wouldn’t resolve quickly enough to allow the new DC to join the forest.  Off I go on a jolly search for default timeout settings, registry tweaks, offline methods to install a DC (ugly at best) and generally going further down the rabbit hole of complexity, even going so far as to direct another engineer working for me to prep for a call to Microsoft (never fun.)

Having already racked a lot of gear, we decided to call it a night and come back fresh in the morning.  I always find it helpful to contemplate problems like this over a good single-malt Scotch.  So I did, a few times, and that led to morning and a face-palm moment.  To wit:

In the cab on the way to the office the next day it occurred to me that I should check the security on the firewalls back home.  I knew I didn’t put any ACLs on that new link, knowing I’d be testing and I prefer to test in the absence of artificial problems, then crank down the screws once I’m confident of the design.  I thought, however, that I had overlooked a NAT exemption or something else and decided to spend some quality time checking that portion of the infrastructure.

So, I got my coffee at the office (thankfully the office manager is a Kiwi who favors Starbucks) and started to look over the configuration of the firewalls.  Right there was my face-palm moment: an ACL which, in some security-conscious delusion I had put on the link in question, allowing ICMP traffic and denying everything else.  *GAAAAAH*  Long story short, I changed the ACL and everything “magically” started working.

All I can say here is that it doesn’t matter who you are, or how much experience with troubleshooting you have, always start with the simple stuff first.  Some of the best advice I ever got was from an instructor of mine who was fond of saying “be the packet.”  By that he just meant that you have to start from the packet’s point of view and slowly work through everything that happens to said packet from beginning to end.  Wiring, arping, routing, etc. whatever.  Be the packet.

Also, don’t be afraid to admit mistakes.  They will happen and hopefully other people around you can learn from them.  At least after they’re done laughing.  Which sometimes takes a while.

Note Three (hey you kids, get off my @#$ lawn)

I just wanted to take a quick moment to address the inevitable questions about our link at 256kb, and the musings that I obviously must have meant mb instead.  Bandwidth is always seen as one of those more is better kind of things, and ignoring the temptation to toss out the standard bandwidth/delay screed here, let me just tell you that you can get by with less than you think. By the way, those of us who can remember when a 2400 baud modem was blow-your-hair-back fast (multiple lines of text at once!) tend to be more pragmatic about these things.

On that link we currently have a domain controller running, several workstations with email and our main corporate ERP software.  We also, and this is what I really like, have two 7900-series IP phones running.  These are both homed to our main CUCM, Unity and IPCC servers back in the U.S. and have excellent call quality.  In fact, we tested a phone call (no local calling for these phones in China) from those phones in Shanghai, through the CUCM in the U.S., and back to a U.S. homed cell phone in Shanghai and got no discernable jitter.

Moral of the story?  You can get by with less bandwidth than you think.  Would I choose to?  Hell no! 

Incoming search terms for the article:

• cisco mifs linux driver

One of the nice things about working with Cisco equipment, as opposed to many other brands, is that you truly do get a smorgasbord of features and capabilities.  On the flip side of that coin, however, the bad thing about working with Cisco equipment is that you can really paint yourself into a corner with features, even when you know what you’re doing.  Many features and capabilities that you have access to on a multilayer switch (or bridge, layer-2 router, forwarder, other nom-de-jour) conflict with one another, are just not nearly as useful as they might seem at first glance, or bring a number of gotchas to the proverbial ball-game, often far outweighing any benefits inherent therein.  Dynamic VLAN assignment with 802.1x is one of those features.

If you’ve read the first part in this series on dot1x, or are generally familiar with the technology, you know that dot1x on a wired network allows a supplicant (software on your PC) to communicate with an intermediary (the switch) in order to facilitate hardware level authentication of assets on the corporate network.  In other words, the switch acts as a traffic-cop and only allows known systems to gain even layer-2 access to the network.  This happens in many cases prior to other types of authentication and authorization and can be part of an overall security strategy on your network.

When you try to do more with wired dot1x is where things get a little more fun.  And by fun I mean gouging your eyes out with dull implements, or randomly beating the nearest co-worker with the weighted end of a console cable.  Doing more in this case referring to assigning computers on your network to specific VLANs based on whatever policies you use to do these things.

For argument’s sake, and because we’ve already established that you’re probably a masochist for doing things this way, let’s just assume that you are using VTP (VLAN Trunking Protocol) to keep your VLANs consistent across all switches in a given campus or building.  Let’s also assume that you have  a couple of VTP Servers, and all other switches are in client mode.  This would also be a good time to mention VTP Passwords, domains, and careful planning, but I think we’ve established that you might be a bit of a renegade.  So we’ll move on.

If you’ve already gotten through the first part of this series, then you already have your switches talking to a backend access and authorization server; most likely this is NPS on Windows 2008 Server or some other RADIUS server tied into your user database.  The main thing you have to do on the RADIUS side that is different for this configuration is to determine what user groups, or computer groups, etc. are going to be assigned to what VLAN.

So your main switch configuration, assuming NPS, could look something like this and would be defined under the Radius Clients section of Network Policy and Access Services:

All this does is establish a connection profile which allows your switch (or whatever device) to speak to the NPS server.  For network policies we’ll have two defined for our example:

One of these is for the IT group, as you might have guessed.  The other is for a Guest access group that we’ll talk about soon.  These policies, by the way, are very flexible and can be written in a myriad of different ways.  The examples here are just one particular way of implementing this type of control.

If we break open one of our policies to look at it, you’ll see something like so:

We actually have a lot more in this section that we’re not showing, including many dialog boxes and configuration tabs.  The summary above, however, is enough to give you a general sense of what’s going on.  While the whole breakdown is beyond the scope of what I’m writing here, a couple of the key things you’ll want to take note of are:

1. Tunnel-Pvt-Group-ID: This is the VLAN you want to assign to this group.  This had better match what exists in your VTP domain, on the switch or switches in question.
2. Tunnel-Type: This is pretty self-explanatory, but I’ve seen it overlooked.
3. Tunnel-Medium-Type: The 802 here refers to, you guessed it, 802.1x

This is all fairly standard server-side NPS or IAS configuration for Windows.  Other systems will, of course different and have their own idiosyncrasies to deal with.  I assume that you or someone you work with is familiar with this on some level, as almost all major enterprise networks these days use a central database like Active Directory to not only control user access to the network generally, but also to authenticate and authorize all manner of connections from wireless dot1x to SSL VPN.

On the Cisco side, things are actually considerably cleaner as you might expect.  Since you should already have dot1x working from our first part in this series, only a few changes are necessary:

1. Define a guest VLAN (in our example we’re using this but it is far from necessary)
2. Define a quarantine, or authentication failure VLAN (again, our example, etc.)
3. Define configuration for individual switch ports, or more likely for ranges.

Steps one and two above shouldn’t need explaining if you’ve come this far: just make the VLANs and be done with it.  For step three, we’re going to use the following configuration:

dot1x pae authenticator

dot1x port-control auto

dot1x timeout quiet-period 5

dot1x timeout server-timeout 10

dot1x max-reauth-req 1

dot1x guest-vlan 405

dot1x auth-fail vlan 404

dot1x auth-fail max-attempts 1

Note that we are using a few extra options here that aren’t, strictly speaking, needed (the timeouts, quiet periods, etc.)  Don’t let those distract you from the core elements.  The dot1x guest-vlan and auth-fail vlan statements in particular are interesting.  What we’re basically doing here are a couple of things:

1. When the switch port receives an EAPoL from the supplicant (PC) indicating dot1x capability, the credentials are tested.  If they are good, the device is automatically put into the appropriate VLAN as prescribed by our RADIUS server.
2. If failure occurs during authentication (ie; EAPoL capable, but wrong credentials, etc.) then the device is put into the auth-fail VLAN (404 in this case.)
3. If the device in question has no dot1x capability or the capability is turned off (no EAPoL seen) then the device is put into the guest VLAN (405 in this case.)

Note that if you have voice VLANs set up, these are unaffected by the dot1x configuration.  Also, you have options to force a port into a permanent authorized or unauthorized state (using the dot1x port-control force-authorized or force-unauthorized command) if you need this functionality.

So when all put together, what does this configuration get you besides a headache?  Seamless and dynamic control of clients, as well as some pretty good security.  You have the clients you know being put into their assigned VLANs regardless of where in the network they are.  This can be good if you rely heavily on VLAN access control lists (VACLs) for security.  Clients who fail authorization are immediately dumped into what can be set up as a black-hole VLAN and then dealt with as needed.  Everyone else—those we don’t know or are older clients—can be put into a guest VLAN where maybe we just give them access out to the Internet at large and possibly a printer.  This is a handy feature for auditors or customers who may set up in a conference room and need some access, but very limited.  Another use for this might be in conjunction with a Network Access Control (NAC) system.  In this case you could test for appropriate patch levels of clients, appropriate firewall settings, unauthorized software or whatever, then dump the client into a quarantine VLAN for remediation.

In the next part of this series I’ll explore some switch port security features that are arguably more useful than dot1x, but conflict in some way forcing you to make a choice.  We’ll also talk about the things that can break in some way when running dot1x.  Ultimately security policy will be determined by business needs—in my case we have a pretty heavy security burden due to the business we’re in.  You, however, may find the headache of dot1x is too much to deal with when compared with the administrative overhead to manage it.  You may also decide that the things you give up to run it just aren’t worth the cost.  Hopefully, when we’re all done you’ll have enough information to make that choice intelligently.

Incoming search terms for the article:

• dot1x
• nps dynamic vlan assignment
• cisco dot1 x nps dynamic vlan
• nps dynamic Vlan
• flash:/c2960s-universalk9-mz uncompressed and installed entry point: 0x3000
• networking terms dot1x
• wired dot1x mac linux cisco 2011
• nexus radius host
• nps 802 1x vlan assignment
• microsoft nap cisco 802 1 x

For all of you paying any attention at all, I owe you an apology on the complete lack of writing the last week or so.  Last week, however, a large pile of backordered Cisco gear showed up at the office and needed to be staged *immediately* or as close to that as could reasonably be expected.  We’re in the throes of a complete infrastructure upgrade and everything sort of backed up unexpectedly with the recent delivery problems from Cisco.  I would question how that becomes my problem, but after 16+ years doing this professionally, I already know the answer to that question.  At any rate, look for a new post in my series on 802.1x in the next day or so.

Most of you are probably familiar with the IEEE 802.1x specification, at least in general terms, but are more than likely used to seeing it applied in the context of wireless networks and services.  In this multi-part series, I’m going to explore the use of 802.1x as it applies to wired networks.  In part I we’ll begin with what 802.1x is and what it isn’t, followed by some basic configuration adhering to Cisco’s current best practices recommendations.  Then, in part II we’ll follow-up with a more complex configuration that you really, really don’t want to use but I put out as an academic example of what can be done if you like the kind of complexity that will guarantee you or your support staff never sleep again.  We’ll also talk about what happens when you mix other security features with 802.1x.

Dot1x, as I’ll be referring to it from now on, is at its most fundamental level simply a method for verifying that a device connected to your network is who it appears to be.  If a company-owned computer connects to the network, we let them have access to certain resources.  If someone connects an unauthorized computer (personal laptop, etc.) to the network, they have no access to anything.  This is the basic idea behind dot1x when we’re talking about wired networks.

Dot1x is not encryption, and doesn’t provide any kind of privacy or anti-replay protection like IPsec.  It isn’t intended for that.  Think of dot1x as login security for your switch ports.  If your switch ports are connected through to wall jacks, with no authentication, then rogue machines have at least limited (layer 1 and 2) access to, at minimum, the VLAN or network that switch port is a part of.  Is that enough to cause damage to your network?  You’ll have to decide for yourself based on your own appetite for risk and internal security policies.

So, what do we do to make it all work?  I’m glad you asked.  You’ll need to do four things, of which I’ll cover the two that happen on the Cisco side:

(1)    Configure your switch to act as an authenticator

(2)    Configure individual switch ports to use dot1x

(3)    Configure your Radius Server to provide authentication and authorization to clients

(4)    Turn on dot1x authentication on your clients (Windows, Mac, Linux, etc.)

The first step is fairly straight forward, and that is to tell your switch you want to do dot1x authentication.  In order for this to work you have to have AAA enabled which is going to change your entire login method, so definitely play around with in a lab if you’re not familiar with it already.  So, the commands we want look like this, entered from Global Config mode:

! Turn on aaa authentication

aaa new-model

! Define our Radius server, port, and shared secret (must match

! with our server setup)

radius-server host 10.0.0.1 auth-port 1812 key abc123

! Here we tell the switch that our default authentication method is to

! use the Radius host we defined above

aaa authentication dot1x default group radius

! Enable dot1x on the switch

dot1x system-auth-control

Now that we have the switch set to authenticate clients to our Radius (Remote Authentication Dial-in User Server) Server, we have to make sure the Radius server has some policies defined.  This is beyond the scope of what I’m going to cover in this post, though if I get enough comments requesting it I can cover that portion in another post.  Basically you’re just telling your Radius server (typically IAS or NPS on some version of Windows Server) that the switch will be contacting it for client authentication, and what that client can and can’t do once authenticated (the authorization piece.)

The next step is to configure your clients to use dot1x authentication, and this is different for each client OS you use.  Windows clients need to have a service turned on which is not on by default, whereas Macintosh has the service turned on but not configured.  For Linux and all manner of mobile devices, there are as many options as there are devices, so I’ll leave that as an exercise for the reader.  As above with the Server section, if I get enough comments I can cover the Windows and Macintosh configuration piece in another post.  Mobile devices and Linux I have limited experience with as pertains to dot1x setup.

The last step in this whole business is to turn on dot1x authentication on a per port or port-range basis.  Keep in mind that you’ll want to test this before turning on carte-blanche as I’ve seen a lot of misconfiguration in the initial setup and the last thing you want is a horde of screaming users looking for your head on a stick.  Therefore, to turn on one port, presumably for testing, we do like so from interface configuration mode:

dot1x port-control auto

! kind of anti-climactic isn’t it

That is the basic configuration of dot1x on a Cisco switch.  In part II of this series, I’ll explore some more complex configurations, as well as some less-than-ideal ramifications of combining other security features with dot1x.  As with anything you configure in the realm of security in particular, it is always a trade-off between security and usability and dot1x is no exception.  Test, test, and test some more.

Incoming search terms for the article:

• 802 1x for wired networks (part 1)
• 802 1x for wired networks part 1
• blog packetqueue net dot1x part 1
• cisco dot1x best practices

Just noticing some differences in this 2960-S model switch; things I haven’t seen before in this product line. One thing is the console port is now two ports: traditional and a small mini-USB. Also, there is a classic USB plug onboard these now too, presumably for IOS updates and whatnot. These are also stackable, which makes sense given Cisco’s new direction in their SWITCH course training material eschewing Spanning-Tree and trying to push Layer-3 everywhere.

1st boot-up below, more impressions later.

Using driver version 1 for media type 1
Base ethernet MAC Address: a8:b1:d4:64:8f:00
Xmodem file system is available.
The password-recovery mechanism is enabled.
Initializing Flash…
mifs[2]: 0 files, 1 directories
mifs[2]: Total bytes : 1806336
mifs[2]: Bytes used : 1024
mifs[2]: Bytes available : 1805312
mifs[2]: mifs fsck took 1 seconds.
mifs[3]: 0 files, 1 directories
mifs[3]: Total bytes : 3870720
mifs[3]: Bytes used : 1024
mifs[3]: Bytes available : 3869696
mifs[3]: mifs fsck took 0 seconds.
mifs[4]: 5 files, 1 directories
mifs[4]: Total bytes : 258048
mifs[4]: Bytes used : 9216
mifs[4]: Bytes available : 248832
mifs[4]: mifs fsck took 0 seconds.
mifs[5]: 5 files, 1 directories
mifs[5]: Total bytes : 258048
mifs[5]: Bytes used : 9216
mifs[5]: Bytes available : 248832
mifs[5]: mifs fsck took 1 seconds.
mifs[6]: 559 files, 19 directories
mifs[6]: Total bytes : 57931776
mifs[6]: Bytes used : 14971392
mifs[6]: Bytes available : 42960384
mifs[6]: mifs fsck took 14 seconds.
…done Initializing Flash.
done.
Loading “flash:/c2960s-universalk9-mz.122-53.SE2/c2960s-universalk9-mz.122-53.SE2.bin”…@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
File “flash:/c2960s-universalk9-mz.122-53.SE2/c2960s-universalk9-mz.122-53.SE2.bin” uncompressed and installed, entry point: 0×3000
executing…

Restricted Rights Legend

Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software – Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.

cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134-1706

Cisco IOS Software, C2960S Software (C2960S-UNIVERSALK9-M), Version 12.2(53)SE2, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Wed 21-Apr-10 06:08 by prod_rel_team
Image text-base: 0×00003000, data-base: 0x01B00000

Initializing flashfs…
Using driver version 1 for media type 1
mifs[3]: 0 files, 1 directories
mifs[3]: Total bytes : 1806336
mifs[3]: Bytes used : 1024
mifs[3]: Bytes available : 1805312
mifs[3]: mifs fsck took 0 seconds.
mifs[3]: Initialization complete.

mifs[4]: 0 files, 1 directories
mifs[4]: Total bytes : 3870720
mifs[4]: Bytes used : 1024
mifs[4]: Bytes available : 3869696
mifs[4]: mifs fsck took 1 seconds.
mifs[4]: Initialization complete.

mifs[5]: 5 files, 1 directories
mifs[5]: Total bytes : 258048
mifs[5]: Bytes used : 9216
mifs[5]: Bytes available : 248832
mifs[5]: mifs fsck took 0 seconds.
mifs[5]: Initialization complete.

mifs[6]: 5 files, 1 directories
mifs[6]: Total bytes : 258048
mifs[6]: Bytes used : 9216
mifs[6]: Bytes available : 248832
mifs[6]: mifs fsck took 0 seconds.
mifs[6]: Initialization complete.

mifs[7]: 559 files, 19 directories
mifs[7]: Total bytes : 57931776
mifs[7]: Bytes used : 14971392
mifs[7]: Bytes available : 42960384
mifs[7]: mifs fsck took 1 seconds.
mifs[7]: Initialization complete.

…done Initializing flashfs.

POST: MA BIST : Begin
FC 1 MBIST Test Passed.
DP Sg1 MBIST Test Passed.
DP Xg1 MBIST Test Passed.
NI 1 MBIST Test Passed.
FC 0 MBIST Test Passed.
DP Sg0 MBIST Test Passed.
DP Xg0 MBIST Test Passed.
NI 0 MBIST Test Passed.
UPB MBIST Test Passed.
POST: MA BIST : End, Status Passed

POST: TCAM BIST : Begin
POST: TCAM BIST : End, Status Passed

front_end/ (directory)
extracting front_end/fe_type_4 (78476 bytes)
extracting front_end/front_end_ucode_info (43 bytes)
extracting ucode_info (77 bytes)
Waiting for Stack Master Election…
POST: Thermal, Fan Tests : Begin
POST: Thermal, Fan Tests : End, Status Passed

POST: PortASIC Stack Port Loopback Tests : Begin
POST: PortASIC Stack Port Loopback Tests : End, Status Passed

POST: PortASIC Port Loopback Tests : Begin
POST: PortASIC Port Loopback Tests : End, Status Passed

POST: EMAC Loopback Tests : Begin
POST: EMAC Loopback Tests : End, Status Passed

Election Complete
Switch 1 booting as Master
Waiting for Port download…Complete

This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:

http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

cisco WS-C2960S-48TS-L (PowerPC) processor (revision A0) with 131072K bytes of memory.
Processor board ID FOC1425W1J7
Last reset from power-on
1 Virtual Ethernet interface
1 FastEthernet interface
52 Gigabit Ethernet interfaces
The password-recovery mechanism is enabled.

512K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address : A8:B1:D4:64:8F:00
Motherboard assembly number : 73-11909-05
Power supply part number : 341-0327-01
Motherboard serial number : FOC14251HQ7
Power supply serial number : DCA1413P1BF
Model revision number : A0
Motherboard revision number : A0
Model number : WS-C2960S-48TS-L
Daughterboard assembly number : 73-11933-04
Daughterboard serial number : FOC14232S4V
System serial number : FOC1425W1J7
Top Assembly Part Number : 800-30950-01
Top Assembly Revision Number : A0
Version ID : V01
CLEI Code Number : COMGF00ARA
Daughterboard revision number : A0
Hardware Board Revision Number : 0×01

Switch Ports Model SW Version SW Image
—— —– —– ———- ———-
* 1 52 WS-C2960S-48TS-L 12.2(53)SE2 C2960S-UNIVERSALK9-M

Incoming search terms for the article:

• C2960S-UNIVERSALK9-M
• 2960S universalk9 image
• mifs[3]: 0 files 1 directories mifs[3]: total bytes : 3870720 mifs[3]: bytes used : 1024 mifs[3]: bytes available : 3869696 mifs[3]: mifs fsck took 1 seconds mifs[3]: initialization complete mifs[4]: 551 files 19 directories mifs[4]: total bytes : 2799820
• C2960S UNIVERSALK9-M qos
• 73-11933-04
• extracting front_end/front_end_ucode_info (43 bytes)
• what is the cisco 2960s ucode
• what about version C2960S-UNIVERSALK9-M
• mifs[3]
• mifs[2]: 0 files

When I think of all of the tools I use on a regular basis to do my job more effectively, there are a handful that stand out as being the most useful of all. As I get the chance, I plan on writing a least a short homage to each one in turn. In my line of work, it is much more common to notice the things that break, or go wrong, or just don’t work as advertised; it is much less common to appreciate the things that just work.

With that in mind, it is only fitting that I start with one of the most useful and reliable programs I have ever used: Putty. Most of you are probably familiar with this little gem, but for those of you who aren’t: a little information is in order.

Putty is a combination SSH, Telnet, and Rlogin client, as well as terminal emulation software. I first discovered this program at some point back when I started hating–with a blind rage–Microsoft’s built-in Hyperterminal application. I soon had switched to Putty full-time, and haven’t ever had the urge to even investigate other options. I don’t know if the writers of Putty are rich, but if they aren’t they damn well deserve to be.

To wit:

I use Putty daily for doing all of my Cisco console work, as well as for all SSH connections to both Cisco and Unix devices. On the Cisco side, it just works nicely allowing for a variety of customizations as well as easy cutting-and-pasting of code to and from Notepad or whatever you use (Complex ACL editing, etc.) On the *nix side, one of the nicest features is the X-11 forwarding which allows you to tunnel back X11 applications, via SSH, to your local client (assuming you are running *nix locally, or have an X11 window manager of some sort running. We happen to use Exceed, but there are free versions available.)

The amount of customization you can do to Putty, from auto-magical window labeling, to key-strokes and shortcuts, to saved session information, etc. is a beautiful thing. At home, for lab work, I have settings saved for all of my console-server connections so that I just have to “point-and-click” to open any of my myriad devices.

I could probably go on and on, but suffice it to say that this little gem of a program should be in your arsenal if it isn’t already. It is one of the first programs I install on any machine from which I plan on doing serious work.

Putty can be found at: Putty Downloads Page and is well worth a look.