Version 1.0.87 – Zone-Voting Stage 1 More Versatile

Cisco’s output format changes — this is to be expected, it’s a text stream, not a structured markup, and I’m somewhat surprised it’s been static for this long.

Due to these changes, and the fact that FibreChannel-Parsers currently doesn’t offer zoning information from a cisco “show zones” which would allow it to replace the stage1 of a zone-vote, some quick changes were necessary to the AWK script that plays one of the adapting stage1, the “make it canonical” stage.

Usage remains the same, no changes in output or behavior.

Revision 597 – Zone-Voting Accepts Dupes by Default

Based on some work I was doing with JP “Skwerl” C, I found/remembered/was-embarassed-by Zone-voting ignoring possibilities of duplicate aliases as a default behavior.

This might have been cool before, but it’s out of fashion now. In fact, I find so many customers duping their nicknames, I wonder if there’s some advice on the ‘net suggesting it’s a good practice. Understandably, these are labels being extracted from zone names, so I cannot claim to be the ivory tower of accuracy or best-practice.

Inspection-worthy units have a more difficult time passing combat.

In this revision, I converted ZoneVote to default to allowing dupes; highlights some mismatched assumptions in test cases. see also “Zone Vote is only an approximation” 🙂

Revision 550 – Dupe-Links-NPIVIgnore Script

Where possible, PHC.jar avoids simple things such as forgetting to set the LinkNames-From-Nicknames setting in Views::Setup::FabricManagement.

Not running the PHC.jar both skips the FAE’s Deployment Checklist, and risks the issues that the PHC checks for.

In this case, the FAE didn’t run the PHC, didn’t set the LinkNames-from-Nicknames, and the links don’t reflect the NPIV names. This is a serious problem in Analysis which is why Stuart Bridger asked for this to be added.

The input to this filter is a list of links and names (the script itself includes a viwc.jar sample). The result is a filter which can be used to ignore the NPIV ports in ProbeSW.

Revision 546 – Summarize-Idle Added

A quick Awk script was added to show how to post-process a CSV exported from a trend report. In many cases, reuse of a data export would be nice, but it’s somewhat opaque: there’s a report, or a CSV. CSVs tend to show just the one summary such as a 1-day rollup.

In order to get more meaningful data, a post-process of an export might be useful. This is the sort of thing that can be coupled behind an email sent to a which later asynchronously executes a BAT file to contain this logic.

I may need to create a writeup of how to leverage this, but in the meantime, this example is added.

Revision 541 – Added Parsing of DCNM Data for Nicknames

In revision 541, the basic capability to ask a DCNM service for the Nickname/WWPN mapping has been started. This has the potential to reuse the information entered into DCNM rather than re-entering manually, and avoid pulling zonefiles from each zone for parsing using a –nickname=file:// or –nickname=http:// method. As well, in situations where aliases are not used, we can collect the port labels or private aliases that DCNM may not share down to the switch.

This method is only initially defined, but requires a bit more work.

The same parser logic is used as was added for OnCommand in OnCommand Query and for BNA in BNA Query. Like the BNA and OnCommand work, the DCNM query simply reformats a query and sends it through the array of parsers to vote upon:

java -jar vict.jar --nickname=dcnmsql://user:pass@server:port/ --nicknameout=\VirtualWisdomData\DeviceNickname\nicknames.csv

Default user/pass should be accurate but need additional testing to confirm. Like the BNA parser, this method hits the underlying database directly, so it needs (firewalls/filters) direct access to the server, and is vulnerable to schema changes. Schema is based on 5.2 documentation.

In the meantime, cisco-shows2wwncsv.awk is also provided to build portlabel nicknames as import CSVs; this awk file needs two “show” commands on every switch. NOTE: every switch, not just every fabric, and it needs to see the output of “show flogi database” before it sees “show interface description”.

Revision 526 – Vote02-ZoneSplit2onTargetPrefix.awk

Every customer is different, and their nicknames of zone titles is no exception. There is no clear consistency in zone names which can then lead near-consistently to Attached Device Names. Nearly.

Zone-Vote Algorithm is always an assumption-lead guess. It poses only a slim chance of being 100% accurate.

In cases where the target in a zone title starts with the same prefix, this Stage-2 of the process can help narrow it down. I added Vote02-ZoneSplit2onTargetPrefix.awk to split zone names based on the prefix of the target device (for example if all targets start with STOR*)

Revision 515 – Added Vote02-ZoneSplit2AndOther for Zone-Voting Algorithm

Many customers choose to give each attached device (Server, Tape, Storage) a nickname or alias, and create their zones that way. Some customers choose to nickname the individual connections (FA or HBA ports) uniquely within the individual components of a fabric. These are very simple to pull out of a copy of the zoning information — whether it be via text files from switches dumping their zoning/VSANs, or reading the zone info replicated in BNA. Both of these methods are handled by the “nickname” option to “vict”.

Others choose to store the nicknames or aliases of the various fabric members in the names of the zones themselves; for example, the zone that allows a server “Oracle44”, via Host Bus Adapter “HBA0”, to communicate with “VMAX12” via Front-end Adapter “10aA”, that zone might be called “Oracle44_HBA0_VMAX12_10aA_prod_A” — the additional “prod_A” is a commonly used method of adding text/comments to the data.

In this revision, I added “Vote02-ZoneSplit2andother.awk” for use at companies who nickname zones with additional text, such as Server_HBA and Server_Name_FA_etc_etc