cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 8

Looking for help creating first configuration check policy

Jump to solution

I want to create a policy to check "IP helper addresses", but I am struggling with the logic.

Basically, I am only interested in interfaces that already have "ip helper" configured, so IF "ip helper-address" exists on an interface, I want to check for 2 specific addresses. It is okay if numerous other addresses are configured (for now) as long as these 2 main ones exist. In the example below, how do I create a policy to check for 3.3.3.3 and 4.4.4.4 that would flag in interfaces Vlan200 & 300, but ignore 100 (because it is correct) and 500 (because it does not have ip helper configured at all)?

interface Vlan100

ip address 1.2.3.4 255.255.255.0

ip helper-address 1.1.1.1

ip helper-address 2.2.2.2

ip helper-address 3.3.3.3

ip helper-address 4.4.4.4

!

interface Vlan200

ip address 2.3.4.5 255.255.255.0

ip helper-address 1.1.1.1

!

interface Vlan300

ip address 3.4.5.6 255.255.255.0

ip helper-address 1.1.1.1

ip helper-address 4.4.4.4

!

interface Vlan500

ip address 2.3.4.5 255.255.255.0

!

Labels (1)
Tags (1)
0 Kudos
1 Solution
Level 18

I think the following should do what you need:

if-then-else.png

Jiri

View solution in original post

9 Replies
Level 13

This is a great post by Dez‌ who just happens to be a SolarWinds Rockstar Fairy and all knowing NCM Guru! That should help get you going, and if not, feel free to post back to the thread and we'll try to help some more! 🙂

34060F90-D7D0-448B-99D4-67F570687C7D.png

0 Kudos
Product Manager
Product Manager

So you can search within the config under block sections so you can start say at Vlan 200 to something after your last Vlan implementation.  More on this is a step by step and RegEX guide here 

~Dez

0 Kudos
Level 8

If I understand your reply, it requires that I skip the check for VLAN100, but I do not have that option in my environment. We use a variety of different interfaces (including non-SVI's/non-VLAN's). My goal is to check every device in my environment (i.e. routers or layer-3 switches of varying platform or software) for ANY interface that has "ip helper address" configured. IF "ip helper-address" is configured, are BOTH required addresses present (on separate lines, obviously)? If so, good - do not report an exception. If NOT, please flag a violation and report it. How do I do this without flagging tons of false-positives? I need each interface block checked individually and flagged independently; if I have 3 different VLAN's assigned to different sets of users, and 2 are correct, but one has a missing helper-address, then we have user-impacting a failure scenario waiting to happen. That is the entire use-case I am trying to solve. I guess I am asking if SolarWinds NCM (we just purchased the full license last week) has the capability to perform this type of advanced check for every interface in a configuration?

0 Kudos
Product Manager
Product Manager

You are able to do this within your rules on your compliance using the search all config or blocks.  You can even place strings using and or etc so you can hone down what you need to be alerted to your needs.

Here is where that is at within the rules portion to create:

Rules.png

HTH

~Dez

0 Kudos
Level 8

Unfortunately I don't think this helps me (unless I am just too dense to see it); it seems to be a limitation in the matching logic capabilities for the tool. I am getting 100's of false positives. What I want:

IF "ip helper-address" is configured, then "1.1.1.1" and "2.2.2.2" must be configured. Else, ignore.

Within the confines of only matching on "must contain" or "must not contain", I do not see how I can achieve my desired outcome with NCM. There are multiple valid configs that DO NOT contain "ip helper-address", so those can be safely ignored, but they are being flagged if I use "must contain". I need support for "IF/ELSE" functions unless there is something that I am missing completely...?

Level 18

I think the following should do what you need:

if-then-else.png

Jiri

View solution in original post

Level 8

Thanks! I’ve tried it and I’m letting it run now. I’ll let you know either today by the end of the day or next Tuesday after the holiday.

0 Kudos

Hmm...    The rule Jiri gave might help in some instances, but not others.   Shows off some weaknesses in the NCM engine I believe unless there is a way to fix it that is escaping me.  First I'm going to proselytize a bit on writing secure rules and being careful with regular expressions.  In the string matching rules cvachovecj‌ gives you above, almost everything is a "regular expression" even though he isn't using them as such.  That can be a bit dangerous.   However, I do believe they should be regular expressions, just stronger ones.    For instance, if you put in his rule above and it worked as mikefryar‌ was hoping it would, it would ignore any IP that began with 1.1.1.1 or 2.2.2.2.   That would include IP's like 1.1.1.10 through 1.1.1.19 and 1.1.1.100 through 1.1.1.199.   Just saying if you want things done right, be as complete as possible.  Adjusting his regular expressions to be

ip helper-address 1.1.1.1\r

and

ip helper-address 2.2.2.2\r

should do the job since it terminates the string at the end of line (I still want to use a "$" to do that!!).   However, you can also combine the two rules using reg-ex's and if you want to be a little more nit-picky and bind the beginning of the line too, you could try

^\s\+ip helper-address (1.1.1.1|2.2.2.2)\r

Now, as to why the rule just plain doesn't work.   If you go back to the examples @mikefryar gave, specifically the vlan100 example:

interface Vlan100

ip address 1.2.3.4 255.255.255.0

ip helper-address 1.1.1.1

ip helper-address 2.2.2.2

ip helper-address 3.3.3.3

ip helper-address 4.4.4.4

!

The example compliance rule cvachovecj‌ gave will pass this on without a problem.  Why?   Because it fulfills the rule!    Sure it violates the first part where it says it must not contain "ip helper-address", but it does fulfill the second part of the OR here, where it has both the "1.1.1.1" and "2.2.2.2" helper-addresses.  So, as long as you have those two IP's as helper addresses, this rule will be ok no matter how many other helper-addresses you might have defined there too...

Another thing you should be careful about, and this is in how the config block is bounded.   Yes, it will find all instances of actual "interfaces" in your config, which is great.  But as-is it will also find every other command in your config file that has the keywork "interface" in it.   So, lets say you have commands like "passive-interface" in EIGRP, it will pick that as the start of a config block (for every instance!).  Or, if you have something like "ip tacacs source-interface Loopback0", or other source interfaces like NTP, logging, SNMP, etc. etc...  Every one of those will be treated like the start of a config block in the Compliance engine!   So, you're just about doubling the work the engine does by allowing it to do this.  How are you allowing it?  Once again, by not binding it to a more specific matching clause.   The cure?   Change it to a regular expression and make it more specific.   Something as easy as:

^interface

will do.  Sure, it might still pick up loopback interfaces and such since the word interface is at the start of the line.  If you want to get fancier, you could do something like this instead than:

^interface (Fast|Gig|Vlan)

to only have it pick up those types of interfaces.

More efficient rules means the rules processing will take less of your time and CPU AND you won't get surprise results that you don't want!!

The bad thing is, I'm not exactly sure right now how to fix this using the current engine, at least where you can write a remediation rule that would fix it.   I do know how to find all unwanted "ip helper-address"'s for you, it was discussed just a bit ago on how to kind of hack the compliance engine to do this type of thing.   You can find the discussion here:  Re: Automoted Config clean up

Unfortunately, the remediation part of this solution won't work because the helper-addresses are contained in the "interface" config block (rather than their own "ip-helper" config block).   The only reason the remediation portion of that discussion worked was because the command was a global IOS command that wasn't within a config block.   However, it will help you find which configs have invalid helper-addresses and you can go fix them manually.  cvachovecj‌ example will work in some specific instances, but not all unfortunately...

HTH!!

Level 18

Thanks a lot, cnorborg‌, for providing further guidance. My post was intended rather as a hint/concept than a full solution and I'm glad that you pointed out what user should be aware of.

Jiri