EEM script to read and execute actions from a file?

[Justin Kurynny]

I have a need to store a series of EEM script lines within a file on flash instead of keeping them stored in startup/running config (it has to do with the way IOS XE processes escape characters--storing the script in a file on flash will hopefully keep the escape characters intact for when I need them instead of translating them prematurely).

My goal is to start an EEM script at reboot, read from a file that contains several lines of EEM script commands that contain these escape characters, and then close the file and exit.

Is there a way to do this with EEM's action file command or something similar? I know I could use EEM to call a .tcl script file from flash, but I was wondering if the same can be done with something like a flash:/scripts/<my-eem-script-filename>.eem script file so that I can keep the script itself much more administratively easy to read and modify.

Justin

[Joe Clarke]

No, this is not possible, unless you have EEM 4.0 and what you have in your file is just CLI commands.  But I find that IOS (at least) supports ecape characters quite well, provided you use octal notation for them.  What characters will you need?

[Justin Kurynny]

Joseph,

Thanks for the information. I'm running EEM 3.2 on IOS XE 3.02.02, so it looks like I won't be able to take the route I suggested.

My issue is not that EEM can't handle escape characters. It's that when I enter a line of code that contains escape characters, the parser immediately converts the escape sequence to the corresponding value.

For example, in my EEM script, I want to create a WLAN on IOS XE that contains a space in the SSID name. To create a WLAN, you issue the following command:

(config)# wlan

Unfortunately, due to a bug in this release of IOS XE (which is the latest release, and a bug fix is forthcoming), SSIDs with spaces isn't directly supported. If you try to enter an SSID name with a space (using the spacebar), the command errors out.

Cisco TAC has given me a short-term workaround such that if I use the escape sequence "\x20" in the SSID name when I create it on the CLI, the system takes it and it works just fine. A show run actually produces output that shows the space, and not the escape sequence.

So if I enter

(config)# wlan FooGuest 1 Foo\x20Guest

then a show run produces the output

wlan FooGuest 1 Foo Guest

The problem arises across device reloads. When I write mem after creating the WLAN, the running config is copied exactly to startup. So a show start shows the line

wlan FooGuest 1 Foo Guest

On a reload, the parser pulls this line in exactly as written, sees the space, and then errors out. The result is that any SSIDs with spaces are discarded at startup.

My proposed solution is to keep the text containing the escape characters intact in a separate text file (and not part of the startup config) such that on a reload I can call an EEM script, pull the contents of that text file in as commands, regenerate the WLAN and be off and running.

I know this is a lot of effort for a short term bug workaround, but this issue affects thousands of clients and we can't really wait for the fix to release.

If you have any suggestions on how I could make this work, I'd really appreciate it.

Justin

[Joe Clarke]

Have you tried this in your boot-up applet:

action X cli command "wlan FooGuest 1 Foo\x5cx20Guest"

[Justin Kurynny]

I tried a variation on it (using all escape characters for each of the \, x, 2, and 0) and just tried your suggestion. Here's what happens:

After issuing the eem configuration line, I do a show run, and this appears:

action 3.1.0 cli command "wlan FooGuest 1 Foo\x20Guest"

This is great, right? Well, I write mem and reboot the switch to test it. The config parser first loads the startup config (parsing as it goes), and the script fails to create the WLANs. I do a show run to see if the script is still intact, and I see this:

action 3.1.0 cli command "wlan FooGuest 1 Foo Guest"

The problem remains that as long as the escape sequence is in the system configuration, the config parser will find it and convert it.

As you can see, I am trying to evade the config parser's persistent distillation of escape characters. If I could just read it in from a static file out of the reach of the parser... 

Maybe pulling in a .tcl is the best way to do this?

[Joe Clarke]

What about this:

event manager environment slash \

...

action 1.0 set str "FooXXXXGuest"

action 2.0 string replace $str 3 3 $slash

action 2.1 string replace $_string_result 4 6 x20

action 2.2 set str $_string_result

action 3.0 cli command "wlan FooGuest 1 $str"

[Justin Kurynny]

Ah, building the string on the fly at runtime. Clever!

I'm off site now, but I will put this into the script and give it a try when I return to the site next week and then post an update.

Great thinking, thanks Joseph.