DX NetOps

Is it possible to create a GC (or a Locater Search) in Spectrum with a substring from the active config as search criteria?

Why?

I want use NCM to  change the config of some devices only if there is a special entry in the config.

I don't believe you can create a global collection search for devices that have a sub-string in a NCM configuration. What you can do is setup a NCM policy and associate that to devices in a global collection that can generate an alarm if the configuration does/does  not contain a certain sub-string.

Using REST you can see the configs using

http : //<IP>/spectrum/restful/model/0x111d00?attr=0x82002b

This gives you some text which is basically interger numbers with '.' inbetween. if you loop through each number and convert it to an ascii character you get the config (letter by letter). Granted there are some non-printable characters like newline as well.

Now when I look at the vnmshell it displays hex values between full-stops. (why is this different than the REST output? The hex characters are not the equivalent to the REST info - perhaps encoded? if so - how to decode them?)

I've seen this type of thing before where values are sometimes displayed as hex for example and then in other places as integers - e.g. model Handles.

Firstly: please standardise

Secondly: I'm not sure why when I do something like:

<?xml version="1.0" encoding="UTF-8"?>

<rs:model-request throttlesize="1000"
  xmlns:rs="http://www.ca.com/spectrum/restful/schema/request"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.ca.com/spectrum/restful/schema/request ../../../xsd/Request.xsd">


  <rs:target-models>
    <rs:models-search>
      <rs:search-criteria
           xmlns="http://www.ca.com/spectrum/restful/schema/filter">
        <filtered-models>
          <and>
            <has-substring>
              <attribute id="0x82002b">
                <value>110.111.32.105.112.32.100.104.99.112</value>
              </attribute>
            </has-substring>
            <equals>
              <attribute id="0x10000">
                <value>HostConfiguration</value>
              </attribute>
            </equals>
          </and>
        </filtered-models>
      </rs:search-criteria>
    </rs:models-search>
  </rs:target-models>

  <rs:requested-attribute id="0x1006e"/>
  <rs:requested-attribute id="0x10000"/>
  <rs:requested-attribute id="0x129fa"/>

</rs:model-request>

it seems to return all HostConfiguration models matching (note text equates to 'no ip dhcp' which I know is definitely only in the latest config.)

Once we know what to look for we would just need to convert the string you are looking for in the config - into some hex/ascii/etc and in theory it should work - but in my case even though it shows in a certain format using REST, it seems the XML search-criteria needs to be different.

Hi Frank,

I get "NoSuchAttribute" when trying to request attribute 0x82002b.

Is this attribute only available on certain Model Types?

Update:

Nevermind, I understand now.  I was using the Device Model_Handle, whereas this API call needs to use the HostConfiguration Model_Handle.  I have this working now.  Thanks for the great example.

Hi Justin, could you please give me an idea about where or how you found the Model_Handle for a HostConfiguration?

The easiest way to find out the Model_Handle is to use vnmsh:

export CLIMNAMEWIDTH=120

cd /opt/spectrum/vnmsh/

./connect ./show models | grep HostConfiguration

MHandle     MName                                   MTypeHnd    MTypeName

0xc3a291    devicename_datestamp         0x820004      HostConfiguration

In this output the first column is Model Handle.

Model Name would be the model name followed by underscore and the date/timestamp of when the config was captured.

There are other ways to do this (via REST API or OneClick UI) too.

Regards,

Frank

franktonjes wrote:

 

Secondly: I'm not sure why when I do something like:

 

 

it seems to return all HostConfiguration models matching (note text equates to 'no ip dhcp' which I know is definitely only in the latest config.)

 

Once we know what to look for we would just need to convert the string you are looking for in the config - into some hex/ascii/etc and in theory it should work - but in my case even though it shows in a certain format using REST, it seems the XML search-criteria needs to be different.

After getting the first example to work I moved onto looking into this.  I think unfortunately this is "working by design".

All configuration captures are stored as "HostConfiguration" models, and there's nothing in your Filter statement to tell Spectrum not to consider every HostConfiguration in the system.  Unfortunately I don't see any attribute to extend your Filter to only have it consider the "most recent" capture.

This is a complete non-solution since it doesn't scale, but I think the only way forward given the current implementation would be to iterate over the list of HostConfiguration Model_Handle's values your API is returning, and for each one issue a "/spectrum/restful/associations/relation/0x00820008/model/<MODEL_HANDLE>?side=right" lookup to identify which ones have the HAS_LAST_KNOWN_CONFIG (0x00820008) relation.  Again, I think this is a non-solution since it's ridiculous to have to issue potentially thousands of API calls (for a system-wide config search) to achieve what should be a straight-forward use-case of searching configurations...

Hi Frank, all,

I know one should not question the initial task in forums like this, anyway what is your goal/reason to have the devices listed in a global collection?

Maybe you could combine some of the above ideas:

1) use a NCM policy to check for your specific config statement - relevant device model_handles will be listed in the following policy model's list attributes:

NCM_Policy_Device_List

NCM_Policy_Succeeded_List

NCM_Policy_Failed_List

NCM_Policy_Remaining_List

NCM_Policy_Untestable_List

2) use some external logic (based on RESTful, vnmsh, ...) to get the model_handles in question and set some specific attribute value (e.g. "Notes: policy matching device")on these devices

3) create a GC to search for devices matching the specific attribute value

4) carefully check the whole workflow processing time/scheduling intervals to make sure, it fits your needs and the SpectroSERVERs performance

5) open a new idea to have the "list attribute search" and "relational search" functionalities added to the Locator/GC search (my discussion about that with CA several years ago ended in "will not be implemented"); once this would be added to Spectrum, we could easily create GCs like "where model_handle is in <value of NCM_Policy_Succeeded_List>"

regards,
Raphael

Thanks for all answers!

I see, there may be a chance to get the list, I'm interested in.

But I think, this is  not practicable for a user, who has only OneClick.

Regardless of this question, "list attribute search" and "relational search" are functionalities, which would be very useful.

I think it's down to the result being encrypted when using the VNM shell and not encrypted when using REST. It seems there is no way to use the output from the vnmsh equivalent so I'm suspecting it's encrypted. Still not sure why I can't query using REST. Perhaps this is a special case since it's one of those octal strings and when you query the format might still be in it's raw format, before the API component converts it into the more friendly format? I've had no luck with this further but would also like to see a feature where you can find info in configs. Seems like it's being overcomplicated a bit since it is an attribute but you can't search the contents of it.

I think I'll just make spectrum dump the configs in some directory and use it like that. It's a pity this doesn't work. Seems like there shouldn't be too much work for them to make it work so might be a good idea to put this up as an idea. I find it a lot where some things are 99% working but one small thing stops you from 'going all the way'

Open an idea for this. Maybe it's voted and it has a quick implementation. Even better, if it's not a pain for implementing it, it think it will be delivered.