I have seen a few questions, but nothing that seems to be a definitive answer, to the question of how to handle bulk changes of interface configurations.
I have what should be a fairly simple task. Add two additional IP helper addresses to any interface that already has an IP helper address configured.
I've found examples that work if there is a particular description, or on a particular interface type, but nothing that looks at the content of the config and does an if/then/else on the existing commands. The helpers I have to change could be on a physical interface, a sub interface, or a VLAN interface depending on the device.
Is NCM capable of this? Has anyone done this or something similar?
I created a Config Change Template, selected the nodes I wanted to remove/add IP Helper to, selected the interfaces on the nodes and executed. See Below
script AddIPHelperAddress (
NCM.Nodes @ContextNode, NCM.Interfaces @Interfaces, string @NewIPHelper, string @OldIPHelper)
foreach (@itf in @Interfaces)
no ip helper-address @OldIPHelper
ip helper-address @NewIPHelper
I have tried to do this with compliance policies and rules to create some type of blocklevel remediation. We classify each interface/port in the description via prefix "desc computer: MYPC" or "desc printer: SOMEPRINTER". Computer ports are configured different than printer ports ect but all computer ports are identical. Right now we can find whole nodes that are out of compliance but remediation is manual. So if you change your "base" config then you have to go through and manually change every port again. Yuk.
We have multiple classification for switches:
desc trunk: REMOTEHOST - REMOTEPORT (MEMBER)
desc vm: REMOTEHOST - REMOTEPORT
desc public: DESC
Routers are different but sometimes have switchports too! 😄
desc lan: COMPUTERS
desc lan: PRINTERS
desc wan: CIRCUITID
desc internet: CIRCUITID
JustinY, trying to get me on my soapbox again? I think we are all similar to the people who started SolarWinds way back when. We have a need, and we see there is nothing that fills that need, so we start trying to either grow our own or try to figure out a way to make what we have do what we need, even if it isn't designed for it. With over 200K interfaces in my network I'd be tagging them for a while, and still end up with a manual solution. Instead, I'd like to purchase a product that does what I need. I'm sure Jiri and the developers can do this. It's a matter of priorities, of convincing them that this is something needed.
Jiri Cvachovec SolarWinds is always looking for the next great feature to add to a product. This is a great feature. It's needed by everyone who purchases NCM, whether they know it at the time of purchase or not, there will be a time. Since I'm not running across many alternative products, you guys would have a pretty good jump on the competition. Is the reason you haven't done it yet because of its difficulty, or because you don't see a market? I think the market's there. If you build it, they will come.
I'm not sure if this helps but I've got a crap ton of interfaces as well. We created a policy report that goes out and looks at interfaces that have regex strings of "ip address" in them, and then looks for "no ip redirects". Same sort of thing you are looking for but you could do it with ip helper. So you could do the search of the config block starting with "interface" and end with ! , do a "Config file must contain" regex string "ip address" (this will find all your layer 3 interfaces in the config) and then you can also add another condition of config file must contain ip helper, if it does then create your remediation script to add in the ip helpers you want.
I really don't see this as an issue you can't tackle with the policy reporter. If you need more help or more details let me know, but again this seems do-able.
I have to agree with extrands and rgward.
This requirement is popular. Having this capability in NCM would be beneficial as rgward stated it would really make NCM command scripts more robust and powerful.
I agree with extrands comment: "..and for non-global configuration changes, I'm not seeing the value in having it"..
I have had numerous times where I needed NCM to be more granular in its capabilities. To be able to apply logic with 'scripting', especially with interfaces.
extrands, if you find a good product could you drop a note? please and thank you.
NCM scripting is not able to take a look at the config. You might be able to achieve what you need with compliance/remediation, but this feature is not primarily meant for such config changes.
Aren't you able to identify the interfaces according to some SNMP/inventory value?
That is disappointing, but not unexpected from the research I've been doing. I don't see any way from a compliance standpoint either. The only possible way I can see to do this is to manually assign a custom property to the interfaces I'm interested in changing- thousands of them- and working up a script off of that. That's not what I bought NCM for, and for non-global configuration changes, I'm not seeing the value in having it. Is there anything in the product roadmap that addresses interface configurations in the manner I'm indicating I need?
I have to disagree this requirement is not popular.
We also would like to see NCM be able to have visibility into the interface configuration. We have the need to detect whether a "bandwidth" statement is configured on WAN/uplink interfaces to be able to apply the appropriate QoS commands to the interface. We are trying to migrate away from Cisco's QoS Policy Manager (QPM) product and if NCM had this feature we would be able decom QPM in a heartbeat and in a matter of days. With NCM only having visibility into the interface description we have resort to having our engineers start inserting a keyword into all the WAN interfaces description that we can have NCM command script detect and apply the right QoS statements. This manual method is unreliable whereas keying off of a required interface command eliminates ensures no interfaces are missed when executing the NCM script.
Another use case would be able to determine whether an interface is a trunk or access port to be able apply switch port security commands. In addition, knowing whether the port is trunk or access, to be able to apply configurations like netflow, ingress/egress ACLs, OSPF cost, and ip helper (as in Steve's case) commands to an interface.
Edit: And, I almost forgot, be able to apply/remove configuration commands based on whether interface is "shutdown" or not.
NCM having this increased functionality would really make NCM command scripts more robust and powerful.
I am going to have to agree with Nux. This is something that NEEDS to be added to NCM - I have also seen a need to the exact thing extrands is asking for. Need a use-case? Ok - deploy a new Acronis or Dell CASE imaging system. or Infoblox - anything that could act as a DHCP server for any reason.
I don't have thousands, but we do have over a few hundred.
I'll start looking for other products that have this functionality then, because its a major issue for us. A "Configuration Manager" should be able to manage all aspects of the configuration, IMO. We do have a Kiwi license, but I've not worked with it yet, hopefully it's a bit more advanced and can do this.
Kiwi CatTools is not so powerful as NCM.
Maybe we could help you with particular use cases. How exactly would you identify the interfaces that you want to change config for?
Each interface on the device would need to be parsed, looking for the existence of the command "ip-helper" if the command was present, two new ip-helpers need to be added to that interface. If the command is not present, the interface is skipped and the next would be examined. I suppose one way to look for it would be any interface that has an IP address assigned would be looked at. If an IP address was there, then check for helpers.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.