Tag Archives: cisco

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

Posted on by

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

Revision 536 – FixNickNameHistory for Database Back-Edits

Posted on by

In Revision 536, I implemented “–fixnicknamehistory” which applies any loaded nicknames (for example, those gained using OnCommand Extraction, those Parsed from Cisco Zones, or those extracted from BNA) to the underlying Portal Server database retroactively.

So long as the Portal Service is shut down, this can be done on a customer’s live server, but it’s more useful in analysis where nicknames arrived late yet the analyst cannot wait another week or so for nickname-ful summaries to be collected.

Revision 512 – Vict Nickname Now Parses Cisco Device-Alias Database

Posted on by

The vict (VI Client Tool) “nickname” action now understands the output of a “show device-alias database” command on cisco.

In past, customers and users generate these files either by running the command in a plink.exe or ssh session (ie: the simplest way), or by capturing a log from their ssh session and running the command manually (ie the more-work way). Unfortunately, in the awk-based parser, replacing spaces with tabs blows away the parser, so this smarter parser should be able to handle that now.

My commit note was simply “Added basic parser for output of Cisco ‘show device-database alias’ behind VIClientTool’s –nickname= option”, and that says it all to ME, but to expand for others, this is what that means:

Recall that with multi-column CSVs, Brocade “alishow”, and Brocade “zoneshow”, a user can ignore the format of the file and just send it in with a “nickname” long-option or “N” for the short-option aficionados.

Now, if you give VICT a cisco “show device-alias database” output, it’ll make sense of that too.

The logic is the same: throw the content scattered at all the parsers, and see who gets the most results.

Although this and other parsers will get the reformatted output from a BNA ext ration (and soon, NetApp), only the basic parser ever gets results form those, so this new parser shouldn’t affect anything adversely. ..but without much forethought, the user gets another format to use.