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

Polling IP on external nodes with dynamic IP not updating

Jump to solution

One of my external nodes with a dynamic IP went down. Only it didn't - its IP address changed, and Solarwinds didn't refresh it despite it being supposedly "dynamic".

Screen Shot 2014-12-01 at 9.06.32 PM.png

Attempts to refresh that IP address manually fail so far. E.g. I unchecked "Dynamic IP Address", clear the "Polling IP Address" field, re-check "Dynamic", try to "submit", and it's asking me to type the "correct" IP address. In kindergarten, they told me that when an IP is dynamic, you're not supposed to type it, it'll magically appear based on a DNS name or URL.

Screen Shot 2014-12-01 at 9.18.41 PM.png

Questions:

  1. Is SAM (NPM) capable of monitoring an external node with a dynamic IP? Based on a discussion from 2011 such as, Why does NPM store the IP rather than use DNS, the answer is seemingly "no", the issue affects not just external nodes, been much complained about, was supposed to be reviewed (in 2011), yet apparently hasn't. Does this sound right?
  2. In the 2nd screenshot above, why isn't is there an option to resolve the IP address? (I.e. what is the logic behind asking for an IP address on a node with a dynamic one?)
  3. Assuming SAM doesn't do it on its own (continuously resolve DNS names like it is supposed to), is there a way to force it to, manually, via UI?
    1. I.e. is there a method simpler / more elegant than change the node to a static IP type, type in the new IP, change back to dynamic?

Thanks!

1 Solution

Solarwinds support is seeing the same issue and "sensing that is the default behavior". In other words:

NPM does NOT support external nodes with dynamic IPs.

Shouldn't this be in big bold letters on NPM and SAM product pages like this one? Otherwise people may be lead into purchasing decisions based on false data (of NPM/SAM supporting hostname-based external nodes). Speaking of which: external nodes should be hostname-based as a rule as they are unlikely to be controlled by the admins.

View solution in original post

27 Replies
Level 8

Following...

We have added several external nodes (that we own and control) and applied the SSL Certificate Expiration Date Monitor to them.  In this case, the problem is that they are hosted with AWS so while the IPs might be the same for a period time, they are subject to change at unknown intervals (as far as I can tell.) So the question is, what is the best way to handle this?  I don't need any other monitoring applied to them, so changing them to an ICMP node is unappealing to me.  I don't want to have to craft alerts to ignore these instances (up/down or packet loss).  I just want to monitor the websites and use DNS resolution to do so.  As of this writing, one of my nodes changed IPs at about 3:30AM and the application monitor was down for roughly four hours.  I had to manually update the IP in order to get the polling back up.  Is SAM supposed to be doing DNS resolution on each poll, and if so is it respecting cache/ttl or doing a fresh resolution each time?

Is this still considered a "bug" and if so, when is it expected to be fixed.  We are on 12.0.1/6.3, getting ready to go up to 12.1/6.4.

Thanks

I see mention of CORE-341.  Is there any place I can track the status of this?  It's been over a year but I can only find two thwack posts mentioning it.

I have the same problem with our SSL Cert Expiration Date monitors.

It seems like the SSL Cert Expiration Date monitors in SolarWinds does not even use an FQDN to begin with.

It looks like it goes straight into polling for SSL cert-related info via "https://NodePollingIP:443".

Maybe people here in Thwack has some inputs about getting SSL Cert expiration dates via some script.

Let me know if you have such a script that does use "https://FQDN:443" or "https://${Node.DNS}:443".

Or if there's already such a script, can you point me where it can be found?

0 Kudos

I am still seeing the failure behavior - checking the Dynamic IP Address checkbox and deleting the static polling address above is not permitted when I submit the node settings.

  • I have tried with the reverse DNS polling option checked and un-checked with no joy.
  • I have valid name resolution to the DHCP assigned host IP address with NSLOOKUP from command-line on the SW polling server.
  • My nodes are not "external"

Are there any updates for this issue?

Level 8

I'm interested in this too as we are monitoring our 3rd party vendors who use S3 or Akamai and the IPs wont be staying the same.

If it is supposed to be dynamic, does SAM do a DNS lookup each time it runs a Application Monitor?

0 Kudos

jamesvalero wrote:

If it is supposed to be dynamic, does SAM do a DNS lookup each time it runs a Application Monitor?

Yes. That is how dynamic IPs are handled.

Level 12

Just as a random silly question, you have the node set to "external", so it does no polling of the node itself.  Could it be because you have it set to "external" it's not picking up the IP address change at the node level because it's not actively trying to find the IP address when it polls?  I'm not sure if the options are mutually exclusive, or how one impacts the other.  Just a random thought that popped into my head.

What's odd, is if I go to a machine and flip it to dynamic IP/DHCP, it grays out the "polling IP" field.  Granted this is flipping a static to dynamic, not editing an existing dynamic.

Jonathan Angliss wrote:

Just as a random silly question, you have the node set to "external", so it does no polling of the node itself.  Could it be because you have it set to "external" it's not picking up the IP address change at the node level because it's not actively trying to find the IP address when it polls?  I'm not sure if the options are mutually exclusive, or how one impacts the other.  Just a random thought that popped into my head.

What's odd, is if I go to a machine and flip it to dynamic IP/DHCP, it grays out the "polling IP" field.  Granted this is flipping a static to dynamic, not editing an existing dynamic.

You da man! Set the node to "ICMP-only", and it refreshed the IP after I polled it a few times. External nodes are forever stuck on whatever IP they were initially set to, even if I change the DNS Hostname.

Just for fun, created an external dynamic node for google.com; it found the IP; I then changed 'DNS Hostname' to yahoo.com; the IP stayed the same. Really, Solarwinds?

0 Kudos

This may in fact be a bug. I've logged this internally for investigation under FB400973. I would suggest however that you open a case with support so we can track it appropriately.

I would suggest however that you open a case with support so we can track it appropriately.

Can't yet: Solarwinds support down?

0 Kudos

You can open a support case online here -> Technical Support Ticket Submission Form | SolarWinds

Thanks. Case 751230.

0 Kudos

Solarwinds support is seeing the same issue and "sensing that is the default behavior". In other words:

NPM does NOT support external nodes with dynamic IPs.

Shouldn't this be in big bold letters on NPM and SAM product pages like this one? Otherwise people may be lead into purchasing decisions based on false data (of NPM/SAM supporting hostname-based external nodes). Speaking of which: external nodes should be hostname-based as a rule as they are unlikely to be controlled by the admins.

View solution in original post

Per aLTeReGo‌ in TCP Port Monitor for FQDNs on external nodes?:

Properly updating the IP address for dynamic external node types is a bug we are tracking internally under CORE-341

So at least this isn't considered an "as designed" behavior by Solarwinds - as it previously was.

0 Kudos

Who is correct? Did I misunderstand something?

akhasheni wrote:

NPM does NOT support external nodes with dynamic IPs.


aLTeReGo wrote:

jamesvalero wrote:

If it is supposed to be dynamic, does SAM do a DNS lookup each time it runs a Application Monitor?

Yes. That is how dynamic IPs are handled.

0 Kudos

If a node is added as "External" we do not update any information regarding it. If we wish to update IP dynamically, we should set as ICMP.


“The External status is reserved for nodes hosting applications that are to be monitored with Orion Application Performance Monitor. Orion will not collect or monitor any data about a node itself, if it is marked as External.” (http://www.solarwinds.com/documentation/en/flarehelp/orionplatform/content/orioncoreagaddingdevicesw...

It's not intuitive and we certainly could adjust this behavior. Will look to do so in future releases.

0 Kudos

If we wish to update IP dynamically, we should set as ICMP.

...Which is just wrong: unlike internal nodes, external ones may not do ICMP at all.

It's not intuitive and we certainly could adjust this behavior. Will look to do so in future releases.

I think it should be a patch to existing releases. My company already paid for this functionality. The very ability to set an external node as "dynamic" in the UI w/o any warning that it's "dead, Jim" is hugely misleading.

Support just closed the ticket with "it does clearly states that there’s no data collection external Nodes therefore, it includes updating the IP address".

Could someone from Solarwinds confirm that this is Solarwinds' official position?

My feeling is that support for hostnames in external nodes has nothing to do with the "no data collection" clause. In fact, it sounds like a poor excuse not to do anything about it given so many factors:

- the problem exists since at least 2009 with no direct indication of no support for hostnames in external nodes.

- the UI clearly indicates support for hostnames in external nodes - see screenshots above

- setting external nodes to ICMP where ICMP is not supported (e.g. firewalled) mark those nodes "down". I.e. not a solution or even a workaround.

Am I the only who thinks this is a very strange way to deal with the issue?

0 Kudos

Alex, I just checked on your case (#751230), and it does not appear to be closed. The last update essentially states that this is not a change in behavior from how External nodes have worked within Orion since they were first introduced in NPM v9.5, more than 5 years ago. While as-implemented, External Nodes may not meet your requirements or expectations, it's difficult for support to say "it's broken" if the behavior has been consistent since inception. I would certainly tend to agree with your sentiment that how External Nodes are updated (or not in this case) could and should be significantly improved to be made more useful. This however may likely not be a trivial change that can easily be provided via a buddy drop, and since it sounds like a product behavioral change it may need to be processed as a feature request rather than a bug. 

0 Kudos

it's difficult for support to say "it's broken" if the behavior has been consistent since inception.

Despite the many threads that report it as a bug - since 2009 - and Solarwinds never acknowledging what the expected or as-implemented behavior is, until today?

Is there a disconnect here or is it just me being cranky?


I appreciate your response aLTeReGo - it's much better in tone and technically than the ones I got from support that basically say, "it's not an issue". The "not an issue" responses trouble me big time - for above reasons, and one more:


Why does an external node accept a hostname at all if it can't support it? The fact that it does but only sticks with the first discovered IP address - with no ability to update it even manually - is against all common sense, especially that the behavior is completely undocumented. Support trying to feed me the "it clearly says, no data collection" story several times not so subtly suggests I am an idiot. Maybe I am, yet at the moment, it's quite hard for me to digest getting this kind of support for a product I am supposed to rely on for our mission critical needs. Not going to fly long term.


I'd be much happier with: "hey, we just discovered this behavior - thanks for helping us zero in on it - we didn't know about it ourselves - yeah, it doesn't look quite right - let us mull it over to see if we can implement a fix some time in the future." It doesn't offer much hope for a quick fix but at least it's an acknowledgement that yes, it is an issue, and yes, Solarwinds ought to look at it.


The "it's not doing it because it's not supposed to" responses from support - even after escalation - look just inappropriate to me. Am I the only one who thinks that way?