Best way to block map responses that support 'no' command

Question

question

mbarfiel asked Sep 23, '10 Spirent_Admin edited Mar 5, '13

Best way to block map responses that support 'no' command

I have a general question on how to block map commands that support the 'no' option. My feeling is to treat these commands as states (no x y z | x y z).

Here is an example response:

interface t1 1/10/1:3 description "" no shutdown remote-loopback csu no remote-loopback fdl no remote-loopback feac timeout loopback 10 !

I would like to query the "remote-loopback" states so that the query returns the following information (example csu loopback):

RemoteLoopbackCsuState(1/10/1:3) = remote-loopback csu | no remote-loopback csu

This would work great for us but we are having a tough time response mapping this because it contains two words "remote-loopback" "csu" and block mapping doesn't work well for this.

If I response map "shutdown" using block maps I can return the shutdownState() = shutdown | no shutdown. I saw this example and I like the idea for all commands that support the "no" option.

Any ideas on this? I need a good way to handle the "no" option in block maps and return the state. An example block map would be great if you can attach one.

iTest response map block map

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 1 · 2010-09-23T20:46:25Z

YujieL answered Sep 23, '10 YujieL posted Sep 23, '10

Each token in the block map is mapped using one of our built-in parser. You can provide a custom parser that will parse the two words as one token.

You may need to click on the "reparse block map" button on the top right corner of the block map editor for the new parser to take effect.

7

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

mbarfiel commented · Sep 23, 2010 at 08:49 PM

My team discussed using that option this morning. Do you think the custom parser is the best way to tackle this situation?

0 ·

PaulD mbarfiel commented · Sep 23, 2010 at 09:01 PM

It seems to me that optional "no" tokens are the way to go here. (Actually you'll need an optional "no" token followed by an optional whitespace token.) As long as you make that optional token explicitly "no" (rather than making it a wildcard) I think the block mapping should work out quite nicely. And if you assign that "no" token a name, then you can query to see if that token exists or not.

Two things to be careful with:

1) If you assign a name to a token, I believe the response map editor will automatically change the "variable" setting to true. You'll want to set this back to "false" -- because you don't expect it to be variable, even though you want to assign it a name.

2) When you want to query to see if the "no" is present or not, then you can't ask directly about the value of the token, because it may not be present. Instead, you want to use something like "count(//no_csu)" which will return zero or one depending on whether it is present or not. Probably best to add this kind of thing as a custom query to the map itself.

If you want to send a bunch of examples, we could probably help with a sample map that does this. (I see the example in the posting, but I'm not sure how much variability you're hoping to build into the map.)

0 ·

mbarfiel PaulD commented · Sep 24, 2010 at 09:17 PM

Paul, thanks for the advice and we considered your solution carefully. However, we felt that keying off the no value would not be as intuitive as returning the state - e.g.. (no remote-loopback csu | remote-loopback csu). Testers instinctively know the state of the loopback if these values are returned in the query. The same argument can be made for any command that supports the no option - e.g.. (no shutdown | shutdown). The tester instantly knows the state of the interface.

We choose to use the custom parser to handle these situations. We create queries for the different interface states and return the entire value. The test can use this information directly in the test report to show any of the states. In a test report you may want to publish the actual results of the interface and by making them available in the query. We publish our test reports to customers so we show them the actual results (outputs) of the test inside the reports. Having the interface states available are useful in the test reports.

We found that using the customer parser is useful for this solution and meets our needs.

We think the custom parser would be great if it could inherit parser values from a common map. We will probably recycle these parsers in other maps.

Also, it would be nice if block maps could handle this situation in a user friendly way. This will be a common scenario for us.

I'm attaching a sample maps so you can see how we mapped the response. I'm still open to ideas on this if you think there is a better way to accomplish the same goal.

Thanks.

0 ·

show_running-config_interface_t1_TA5K.ffrm (32.3 KiB)

PaulD mbarfiel commented · Sep 26, 2010 at 07:48 PM

There is already support for centralizing your custom parsers in a single common map in a response map library. I have to check, but I seem to remember that you create a response map called _common.ffrm and put it in the root directory of the library. All of the custom parsers from this map will be used when performing any mapping using that library. (You can also put other common mapping things in there if you want -- such as queries.)

As long as you know what you're doing, this approach of custom parsers sounds very reasonable.

0 ·

mbarfiel PaulD commented · Sep 27, 2010 at 07:17 PM

Thanks for the info, we added the _common.ffrm map to the root directory and the parser definitions worked in other maps. We think this will work OK for what we are trying to accomplish.

We couldn't find any information in the help files regarding the "_common.ffrm" response map. Is this a well supported feature or a back-door option? We need to make sure this is solid before committing to this solution.

As far as knowing what I'm doing...that's a crap shoot. I usually wing it and hope for the best

Thanks.

0 ·

PaulD mbarfiel commented · Sep 28, 2010 at 03:20 PM

The _common.ffrm support is solid. It seems, however, that it may have been overlooked in the documentation. We'll look into that.

0 ·

RoyL PaulD commented · Jan 18, 2011 at 05:29 PM

Added the _common.ffrm info to the doc section on the Parsers page -- thanks for bringing this up.

0 ·

question