9 Replies Latest reply on Sep 7, 2015 1:24 AM by cvachovecj

    Looking for help creating first configuration check policy

    mikefryar

      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

      !

        • Re: Looking for help creating first configuration check policy
          Dez

          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

            • Re: Looking for help creating first configuration check policy
              mikefryar

              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?

                • Re: Looking for help creating first configuration check policy
                  Dez

                  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

                    • Re: Looking for help creating first configuration check policy
                      mikefryar

                      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...?

                      1 of 1 people found this helpful
                        • Re: Looking for help creating first configuration check policy
                          cvachovecj

                          I think the following should do what you need:

                           

                          if-then-else.png

                           

                          Jiri

                          2 of 2 people found this helpful
                            • Re: Looking for help creating first configuration check policy
                              mikefryar

                              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.

                                • Re: Looking for help creating first configuration check policy
                                  Craig Norborg

                                  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!!

                                  1 of 1 people found this helpful
                      • Re: Looking for help creating first configuration check policy
                        mrs.alterego

                        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