Highlighted
Trusted Contributor.. Trusted Contributor..
Trusted Contributor..
858 views

variables in policies

Jump to solution

Hi all,

 

I have a question, can i use custom variables in policies? or if exist one way to do something similar, for example:

 

I want to take in a variable an ip from one of my interfaces and compare with some Ip in my configuration of my acl’s.

 

 

Thanks a lot!

0 Likes
1 Solution

Accepted Solutions
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: variables in policies

Jump to solution

Hi,

 

OK, let me go through your list and we can see where we end up.  🙂

 

Let me start with recommedning you look at this:

NA API Users Guide / Appendix A: Installing the NA Perl API

 

If you create an advanced script (Perl) in NA, it'll use certain modules, NA has modules that it needs to use that hook into the system (Connect, Client are the key ones).  

 

These "normally" get installed during the NA install process, but not always - it talks about all this in the doc above.  

 

 

In any case, my script needs to connect to the NA proxy so it can  get the data and do the mod device - this is what will populate the custom data field(s).  

 

You'd need this to be able to use the API commands I use in the scripts. You might be able to  get around it with net::telnet to connect to the NA proxy - I've not tried that, but Connect and Client are meant for this sort of thing.   

 

Hope this helps

Chris

View solution in original post

0 Likes
10 Replies
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: variables in policies

Jump to solution

Hi,

 

There might be a way to do this, but it wouldn't be an easy (or pretty) policy rule.  

 

As far as I know, you can't create your own variable, but there are built in variables - you can see these by going in a rule and in the conditions section, you should see a link that says "Built-in Device Variables can be used".

 

Would your IP that you want to search for change frequently, or is it static (for a given device)?  For example, if you're always looking for Lo0, this might work....

 

You could take that IP, store it in a custom data field and then you'd be able to use it in a rule referencing $tc_device_custom_XXX$.

 

 

You might be able to do something with reg-ex, but that would add some significant overhead to the policy check.  Off the top of my head, I'm drawing a blank.  I can see how this would work in a script, but no so easy in a policy.  

 

Good luck,

Chris

0 Likes
Highlighted
Trusted Contributor.. Trusted Contributor..
Trusted Contributor..

Re: variables in policies

Jump to solution

Hi,

 

The interface is static, you said i can add a custom variable in section Built-in Device_variables can be used.

 

how can i do this, i think maybe is the solution of my problem,

 

thank you very much for answering,

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: variables in policies

Jump to solution

Are you using a scripting language? I use Ruby and I do it in just about every script I write within NA. I'll provide an example ... Like I said, I'm using an advanced script with the language of Ruby. I had a Cisco customer want to make an ACL change and within the ACL called out specific IP addresses on their LAN network, so what I did was I took the default variable in NA of the Device IP and then did a gsub that everytime it saw the device IP in the script to change it.

 

Here are my variables:

device_ip = "$tc_device_ip$"

dvr_ip = device_ip.gsub(/254$/,"130")
network_ip = device_ip.gsub(/254$/,"0")

 

Then a line within my script would look like this.

 

  raise "error command line 5h response" unless cpe.command("permit ip host #{dvr_ip} host 10.100.28.21\n","config")

 

What this would do is say the device IP was 10.10.10.254, when it would see the variable dvr_ip it would change it to 10.10.10.130 and the variable network_ip it would change it to 10.10.10.0 ... so the line in my script would have put this:

 permit ip host 10.10.10.130 host 10.100.28.21

 

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: variables in policies

Jump to solution

OK, 

 

Not sure what version of NA you are on, but it's pretty much the same across them.  

 

I'll reference the doc for NA 10....again, if you have say 9.2x, it'll still work.  🙂

 

Inthe NA User Guide, Chapter 13 is all about Custom Data Setup.  

 

For example, if you wanted to add this as a "device" custom data field, you 'd select Devices from the drop-down box the doc talks about.  Then you can find an unused field and just follow allow with the doc.  

 

Once that is done, the next step is to populate the data.  There are a few options.  

1) Manually add the data in.  Depending on the # of devices and how good you are with scrpts, this may work.  Or this is a good way to test the concept out - quick to do.  

 

2) Script driven.  You'd have a script that would run and pull the data and populate it in the custom data field (this is the mod device -customnames line you see in the doc.  

 

Once this is done, you can just use that custom data filed in your policy rule using the variable  "$tc_device_custom_XXX$."  

 

Let me know if you have questions.

 

Thanks,
Chris

 

0 Likes
Highlighted
Trusted Contributor.. Trusted Contributor..
Trusted Contributor..

Re: variables in policies

Jump to solution

hi,

Yes, this works for my policies, but manually i can populate the variable and when i try to populate the variable with a script it doesn't work.

Can you share me a script where you do something similar?

Thanks a lot, you are of great help

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: variables in policies

Jump to solution

OK, this gets the data from NA as opposed to connecting to the device, but it should get you going.

 

 

The first will show you how to populate the custom data field, the second (and this is a bit of a guess on my end) would show you how you can use show configlet to get the ip address you're interested in - that should work if you're using the same interface (interface Loopback0 for example).  

 

Good luck!

 

-Chris

0 Likes
Highlighted
Trusted Contributor.. Trusted Contributor..
Trusted Contributor..

Re: variables in policies

Jump to solution

Hello Chris,

 

Thanks for  your answers, I just have some doubts regarding the code.

You referenced the module Opsware::NAS, and I'm not sure I understand how this works.

Is this a perl embedded module?
Is this a module I need to install in my perl compiler?

Or does this have to do soley with NA, (I ask this because everything I found regariding it, is on HP forums and is referenced to NA)

 

I've previously worked with perl scripts to access HP devices and the only moduleI we've used was a Net::Telnet module to access the device. Will this module suffice?
FYI: We are using a windows server and when installing the perl compiler we tried to install some modules on it with the Cygwin ¿addon? and we had a lot of trouble with it so decided to go only with the Telnet module, wich sufficed for what we were doing at the time.

 

Thanks a lot,

 

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: variables in policies

Jump to solution

Hi,

 

OK, let me go through your list and we can see where we end up.  🙂

 

Let me start with recommedning you look at this:

NA API Users Guide / Appendix A: Installing the NA Perl API

 

If you create an advanced script (Perl) in NA, it'll use certain modules, NA has modules that it needs to use that hook into the system (Connect, Client are the key ones).  

 

These "normally" get installed during the NA install process, but not always - it talks about all this in the doc above.  

 

 

In any case, my script needs to connect to the NA proxy so it can  get the data and do the mod device - this is what will populate the custom data field(s).  

 

You'd need this to be able to use the API commands I use in the scripts. You might be able to  get around it with net::telnet to connect to the NA proxy - I've not tried that, but Connect and Client are meant for this sort of thing.   

 

Hope this helps

Chris

View solution in original post

0 Likes
Highlighted
Super Contributor.
Super Contributor.

Re: variables in policies

Jump to solution

@Chris_Powers  Hi Chris, Can you please help me with more about this variable usage in the compliance policies. 

My use case is like this. In Cisco switches configuration we don't get details about VLAN name but interfaces are assigned to VLAN IDs. What we have is a standard VLAN name and different VLAN IDs in different switches that are deployed at different locations. We need to identify interfaces that are mapped to this specific standard VLAN name. 

e.g. Location A - VLAN Name - SERVER - VLAN ID - 20 , Location B - VLAN Name - SERVER - VLAN ID - 30 and so on. 

We need to capture the VLAN IDs that are mapped to the standard VLAN Name called SERVER in each switch and exclude the specific interfaces from a check which are mapped to that VLAN. 

With this dynamic variable are we able to achieve this? Can we replicate the same solution if we have multiple standard VLANs to be accounted for? When to run this script and what to be added in the policy to take this into account? 

I would appreciate, if you can throw some more light on possibility of this solution. 

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: variables in policies

Jump to solution

Hi Sanjeev, I'll see what I can do...

Off the top of my head, don't think there is an option that would let you do this without any initial work being done.  Not a way within a policy today to dynamically do this on the fly.  That said, I do have a few ideas, but all would require some work to fully develop.  

The first thing I thought of wouldn't necessarily work today, but might be worth looking at in the future as it would be pretty easy to do:
If you could add this VLAN name to the interface description, then that would make it available within each config interface block and you could say something like block does not contain server and then that interface block would be ignored. But wanted to suggest it - you could use NA to push out the change and I don't think that'd be too difficult to do, just some substitutions. I could see this could be done with a CSV template and the output of a NA report (and then you just add in the VLAN name).  You could even create a policy that checks to make sure people are staying on top of this - say all interfaces that are "up" must have a VLAN name at the end of the description line - VLAN Server, VLAN Client, VLAN ABCD.  

Now, for today, you "could" use data fields a couple different ways, but this might be a bit ugly and not sure how the reg-ex would work off the top of my head (would require more time than I have right now but this is a start) and you may be a reg-ex guru and I start the a thought and you can pick it up and run with it and improve it to fit your needs.  


You'd have a custom data field, let's say we call it "serverVlan_Interface" and we populate it with a script. This script would be an advanced script or perhaps an external script that used some external file for lookup or even external DB and then was able to connect to NA (proxy) and look at the device configs and be able to say for deviceA, we want vlan2, vlan500,vlan501,vlan600 and just loop through getting those config blocks. Each time you have a config change, this gets run and makes sure it is up to date / current. That will one way or another look at the interfaces, see what ones have VLAN IDs, then for those that are "server" Vlans, add that interface name to the custom data field, so at the end, for each device it might look like:

hostname serverVlan_Interface
deviceA vlan2,vlan500,vlan501,vlan600
deviceX vlan2,vlan600,vlan601

So, for the block start pattern, you'd do two things, set it up so you are processing the interface blocks AND also referencing your custom data field, making sure that these interfaces aren't contained in your custom data field value - $tc_device_custom_serverVlan_Interface$
Then your condition would be to look for whatever you wanted - you wouldn't have any "server" interfaces.

Thinking about this a bit more, you may want to flip around what is in the custom data field, instead of storing interfaces to exclude - "server", store what you want to look at and separate with a "|", so you'd have:
hostname serverVlan_Interface
deviceA vlan1|vlan100|vlan101
deviceX vlan1|vlan200|vlan201

and then your block start could be more like:
^interface $tc_device_custom_serverVlan_Interface$
Does this make sense?

Another option, that might be easier, would be to create a diagnostic and within that diagnostic you are doing two things:
1) You are looking for interfaces that you "want" to evaluate within your policy. So, you'd have a script - using similar code / logic to what I referenced above that would figure out what interfaces were "server" vlans and ignore them.
2) You capture the config blocks you want to check within the policy.
This way, you have a diag that you can reference within a policy rule and you don't need to do anything fancy to limit what interfaces are evaluated - the diag did that for you. If it is in the diag, then it needs to be checked.  This diag would again be run when there is a config change and so the diag would be up to date.  

Lastly, and this is something that might not work if the VLAN IDs aren't consistent, but could you just reference (exclude) the VLAN IDs within the policy - not sure how many "server" vlan IDs you have or if say at location A vlan ID 500 is a server, but at location B, vlan ID 500 is not a server - then it wouldn't work, but this might be worth trying initially until you either got a diagnostic script (option 3) or custom data field (option 2).

Hope this helps, others might have some even better options, but hopefully this will give you a few ideas to get you going.  If you have questions on the options, just reply and I'll see it.  


Good luck!

Chris

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.