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.

How to Collect DCNM and BNA Data via SMI-S Interface

OK, I need to come clean on one thing: this article isn’t about SMI-S per-se, but about connecting via CIM-XML. The thing is, “what is CIM-CML?” When a client connects to, let’s say, BNA, it can talk CIM-over-HTTP, CIM-over-HTTPS, or CIM-over-RMI. In hindsight, maybe I should have focused on RMI, but I had reasons. Had I titled this “…Data via CIM-XML over HTTP”, I would anticipate glazed eyes, and no real up-take on why this matters.

The trick is: it doesn’t matter a whole lot. …but it’s there if you need it, simply because I had it around.

We typically draw information from BNA (and alpha-quality in DCNM) by speaking directly to the underlying database, like this:

wpg_div_wp_graphviz_1

So normally, that’s a command such as:

java -jar vict.jar -N bnapsql://bna.example.com/
java -jar vict.jar -N dcnmsql://dcnm.example.com/ (again, needs QA)

These use the BNADatabase passwords, not the user’s password with which he is more familiar. These are typically hindered by ACL (the evil “pg_hba.conf”, all 4 of them).

The thing is, this method (in BNA) gets the data that isn’t available by SMI-S… err… CIM-XML. This gets the aliases that are not zone aliases. If you don’t recognize the difference, or remember “the McData way”, understand that some data isn’t available.

So there I was working on a DCNM Writer for a customer. It’s been taking way too long, and in order to test, I had added a DCNM CIM-XML client to the parsers. I needed something to bang on the DCNM and see what it had for when I try to push changes into it.

I needed this:

wpg_div_wp_graphviz_2

I decided to complete a functional BNA client (alpha), together with a DCNM client, and make those available to both vict.jar (VW3) and (VW4) vw4tools.jar via underlying FibreChannel-Parsers. They’re used like this:

java -jar vict.jar -N bnacql://bna.example.com/ (this one needs QA)
java -jar vict.jar -N dcnmcql://dcnm.example.com/
java -jar vw4tools.jar -N bnacql://bna.example.com/ (this one needs QA)
java -jar vw4tools.jar -N dcnmcql://dcnm.example.com/

The abbreviation for the protocol is BNA/DCNM, followed by CQL, the CIM Query Language, which is actually similar to SQL92 (Language, not Microsoft product). Microsoft has a variant for the WMI called WQL. If you like, you can be more explicit able the defaults:

java -jar vw4tools.jar -N dcnmcql://scott:T1ger@dcnm.example.com:5988/cimv2

Of course, you’d want a -o or -n to make use of the collected data, and you’ll see collected nicknames show up as NicknameParser counts (these data sources feed a text stream that is parsed by NicknameParser). vw4tools has full capability to –pattern itself into some upper-level entities, or just spit out fcports.

…and that’s the power of what I’ve done: the BNA and DCNM portions are merely small layers over the underlying capability. I could replace the vCenter collector with a CIM-XML client, or use that to interrogate various storage devices, but I assume VirtualWisdom4 Discovery will eventually do that for us in a much more Quality-check and code-reviewed and reliable manner.

As a reminder, the things I build are intended towards the installation timeframe, where a few hiccups are accepted so long as the task is completed. I don’t necessarily feel these tools would be used beyond installation day.

Version 1.0.73 – Collect Nicknames via CIM-XML CQL Client

This edit allows two additional “protocol” values: instead of just http, ftp, bnapsql, dcnmsql, and the formats listed on FibreChannel-Parsers docs, this adds:

  • bnacql://user:pass@server:port/path to query a BNA server using CQL
    • ie bnacql://bna.example.com/
    • ie bnacql://scott:tiger@bna2.example.com:5988/cimv2
  • dcnmcql://user:pass@server:port/path to query a DCNM server using CQL
    • ie dcnmcql://dcnm.example.com/
    • ie dcnmcql://scott:tiger@dcnm.example.com:5988/brocade1
    • ie dcnmcql://customer:pass@dcnm.example.com/

For example, I’ve been hammering away at it using a command like this:

java -jar vict.jar -N dcnmcql://admin:adminpass@192.168.1.130/ -n nick.csv
… and I would see that the collection extracted 3 DeviceAliases.

The DCNM CQL client draws out Device Aliases, but I haven’t found fcaliases yet.

The BNA CQL client will draw out Zone Aliases, but not Aliases of the non-zone-alias sort.

Why? I needed a CIM-XML client for some work I was doing, and I had the code loosely working so that I could use it to test the other real deliverable. Since I had a DCNM client already, I split the Cisco-specific stuff out, and slotted in a BNA client. The DCNM client (via dcnmcql) is working just fine, but I don’t have a test server to beat up with the BNA client. It works in theory?

How is this useful? Not a whole lot, since VW4 will use a protocol like these to collect information, but I’d like to point out something:

this doesn’t need a license

This would actually let a customer check “will VW4 see all of my aliases?” which — as Application Engineers and Deployment Techs know — is actually a fairly long pole in the circus tent of VW4 deployments.

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 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 674 – Dupe Alias in Cisco Show Zones

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

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

This confused the Show Zone parser (Revision 657 – Cisco Show Zone), plus it was ambiguous which name (“testhost” or “real alias”) should be used.

This was resolved in ShowZoneParser to use “realhost” silently; a test case was added to this project to confirm the problem is resolved going forward.

Revision 672 – OnCommand and DCNM Clients Migrated

In this revision, minor changes were done to move the OnCommand and DCNM client code outside of the non-public source base and into the public source base at OSMURLConnection.java and DCNMURLConnection.java. This allows for external audit of the code and may improve trust and reduce concern. This is very similar to the work done in Revision 670 – BNA Client Migrated

As with Revision 670, the project retains all the test cases involving this and other parsers, so functionality is verified retained, there should be very little change in behavior. The DCNM backend-database client remains beta-quality and requires further testing if a user is willing; the OnCommand client has been heavily tested.

The OSM or OCI backend-database client was added 14 months ago (Revision 516 – Added parsing of OnCommand Data for Nicknames); DCNM backend-database client was added 13 months ago Revision 541 – Added parsing of DCNM Data for Nicknames). The OnCommand client was altered to append a fabric name for a specific environment 11 months ago (Revision 578 – NetApp msosmsql Pseudo-Protocol Adds Fabric Suffix) but can be used to show how easily the output can be transformed.

Revision 666 – vw4tools.jar, vw4tool.bat, more parameters, and DeviceAliasParser

This revision was a rollup of a few updates, as follows:

vw4tools.jar and vw4tool.bat allow a basic windows user to locate and run their JRE against the vw4tools.jar file to non-interactively execute a function. This is very similar to the way vict.bat works, except that vw4tools.jar is rolled into vict.jar so both are available in the same package. vw4tool.bat does the right thing.

In order to allow more command line parameters, the convenience BAT files have swapped %# to %* for parameters. If you never ran into this, it’s no problem 🙂

DeviceAliasParser now ignores newlines; this was done in the FibreChannel-Parsers project externally, but testcases were corrected to confirm the behavior.

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.