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.

Version 1.0.47 – Withstand Bogus Preamble While Parsing Zones

The consistent recommendation in examples and blog posts to collect zone information for nicknames looks like this:

plink.exe -l username -pw password IP.IP.IP.IP zoneshow > IP.IP.IP.IP.zoneshow

For example:

plink.exe -l scott -pw tiger 192.168.1.1 zoneshow > 192.168.1.1.zoneshow

Despite this, users still feel that “grabbing the log from putty is good enough”. That actually costs additional work, and mores, it means that greater-than-zero work is needed, and that seems to be a task that is fairly complex to do onsite with a customer when you’re jet lagged, and grumpy, and got zero sleep because the (m)hotel you slept in at company expense policy was beside a railway track for efficiency. I mean, c’mon, we all know that the best TV remote-control is the one with only one button, why can’t nicknames be that easy? Although it bugs me that directions cannot be followed, it bugs me even more that I need to be so precise. Why can’t I just skip the same stuff I skip manually?

So I did that: fibrechannel-parsers added the ability to skip any preamble that ends in “alishow” or “zoneshow” in order to accept the zoning text commonly offered for nicknames.

In order to confirm that an earlier release is never used if found during discovery, a testcase was added to vitools to confirm that the fcparsers jar includes the new handling of putty-dump-ish preamble that apparently occurs even when directions are perfectly followed and “collect zone or alias information non-interactively and no-never-ever use putty” is the rule that gets missed. vict.jar and vw4tool.bat should both be a bit more tolerant.

Revision 677 – Additional Dupe WWPN Issue When Lacking fcalias

Another issue was discovered in that Cisco “show zones” command is giving results such as:

zone name z23_test44 vsan 300
    pwwn 10:00:00:00:c9:12:34:56 [realalias]
    pwwn 10:00:00:00:c9:12:34:57 [otheralias]

Lacking the fcalias, this confused the Show Zone parser (Revision 657 – Cisco Show Zone), in a way slightly different than in Revision 674 – Dupe Alias in Show Zone. There’s no ambiguity between two nicknames or aliases, but the parser wasn’t picking up all possible pawn lines (i.e. reporting 10:00:00:00:c9:12:34:56,realalias but not reporting 10:00:00:00:c9:12:34:57,otheralias.

This was resolved by creating an additional parser with more code paths in the ShowZone2Parser to collect all subparts of a zone into the zone after the section is complete, and to collect all parts into each fcalias as a new fcalias was found or the zone is completed.

There’s still a few caveats to chase down, as noted on that class’s description.

A test case was added to this project to confirm the problem is resolved going forward.

Revision 1.0 – ShowZoneParser with Postfixed Aliases

This is the first commit shared from the new build of the vitools project. Users should see no difference except the 1.0 version to mark the newer build method. The third digit of the version is still auto-incremented, and that’s the one that counts.

In this revision, fibrechannel-parsers improved ShowZoneParser ability to parse zone content lacking prefixed fcalias values but with postfixed aliases after WWPNs. To ensure we always pick up a repaired version, vitools adds a test to confirm every release continues to fix this issue.

Revision 665 – Handle Brocade Hanging F-ports

The underlying fibrechannel-parsers project added the ability to properly handle H{xxx} markup, which seems to be Brocade marking out Hanging fabric members (disappeared, never rejoined). In vitools, a testcase confirms functionality absorbed into vict.jar “-N” behavior.

In short, the ability to ignore hard-zoning was improved to get the WWPN from a hanging member as well.

Revision 657 – Cisco Show Zone

Added the ability to parse nicknames from a Cisco Show Zone. In short: blindly parse a “show zone” output, and if the text stream isn’t overly butchered, nicknames will be detected and imported to the VICT space for writing using -n file.csv or --nicknameout=file.csv

in fibrechannel-parsers version 0.3.39, a parser was added for the result of a cisco show zone:

zone name SANASVR001_FabA vsan 100
  fcalias name Oracle_123466 vsan 100
    pwwn 10:00:00:00:c9:12:34:66

  fcalias name HDS0123457_CL7F vsan 100
    pwwn 50:06:0e:80:12:34:56:78

This differs from a show device-alias database or a show fcalias in that the zone entries are present, and may contain vsan verbs. Implemented as a stream, it should be a bit more robust and accepting than a pure-scripted variant, so that content provided by (oh, my favorite!) a user cutting a session out to log and submitting that (because it’s just as good… nah, with the ANSI markers and color formatting, it’s better!). This isn’t a substitution for ignoring the very detail when (not) reading directions, but it should give us a fighting chance.

The addition is available in the same array of parsers, so it works without any new user-config. For example, list like the parsing of cisco device-alias database as a simple text stream (from FTP, HTTP, or FILE:// URLs), a simple --nickname= or -N will work:

java -jar vict.jar --nickname=file:///file/name.txt

(or the convenience fallback)
java -jar vict.jar --nickname=/file/name.txt

(or in short-form options)
java -jar vict.jar -N name.txt

(or in Windows)
VICT.BAT -N name.txt

The matching actions in the main toolkit using the fibrechannel-parsers project involves a test case to ensure the code is resident and functioning; by that method, whatever version of fibrechannel-parsers is found during the build will offer at minimum a functioning version of this extension.

Revision 652 – Just a Few More Debug Statements

Built using fibrechannel-parsers v0.3.49 which adds a few debugger options to ZoneParsers — the quick summary on that is when things go sideways, I might be able to get a clue more quickly rather than “pulling teeth” to get screen caps (understanding that our users tend to be in closed-off VLANs and such).

Builds against JDK-1.6 to JDK-1.8.

A certain Texan asked for an alternative query, and even though that thread went a little quiet, a different query statement gets run against a BNA server when using the bna:// or bnapsql:// protocols in a “-N” or “–nickname=” statement to VICT when the java option -Ddebug.carleton=true is used.

Revision 648 – alishow/zoneshow Parser Safely Ignores HardZoning, Multiple cfg:

Hard-zoning records are no longer an issue in the alishow parser.

The external fibrechannel-parsers (fcparser.jar) recently safely ignored multiple cfg: sections, but was still hanging up on hard zoning records.

hard-zoning records — basically “the zone includes blade X, port Y” — not even recommended by Brocade, is occasionally seen in “in the wild”, typically in environments merged into the current one through corporate merger/acquisition of an older SAN. Few support the additional effort and logistical challenge of maintaining hard-zoning of any significant size. It’s those “attritioning out” systems that administrators are nicely letting be until they roll off their life-cycle into recycle.

For now, those hard zoning records would stop the parser immediately. Now, the parser ignores them, still reads the zoning record if available, and carries on.

Revision 602 – Split and Build with external Parsers, Solved a Parse issue

In this revision, the parsing code is now external; it has been split out to “fcparsers.jar” from fcparsers-java rpm visible at github.com/chickenandpork/fibrechannel-parsers/ … this was done to improve code visibility and to allow bug reports to be created more closely to the specific piece of code involved.

In doing so, I also chased down a parsing issue in that the following block would produce a nickname short:

alias: NASMany_654321
                10:00:00:00:c9:44:44:10; 10:00:00:00:c9:44:44:11
                10:00:00:00:c9:44:44:20; 10:00:00:00:c9:44:44:21
                10:00:00:00:c9:44:44:30; 10:00:00:00:c9:44:44:31

Results:

10:00:00:00:c9:44:44:11,"NASMany_654321"
10:00:00:00:c9:44:44:20,"NASMany_654321"
10:00:00:00:c9:44:44:21,"NASMany_654321"
10:00:00:00:c9:44:44:30,"NASMany_654321"
10:00:00:00:c9:44:44:31,"NASMany_654321"

… clearly missing “10:00:00:00:c9:44:44:10” (and yes, per the weak consuming parser to which we send this result, no space can be between the WWN and the alias).

That was resolved by fixing the byacc parser code. All six members now show up.

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” 🙂