Tag Archives: dcnm

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

Posted on by
Reply

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

Posted on by

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 541 – Added Parsing of DCNM Data for Nicknames

Posted on by

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