New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


Issue with sensor over load balanced network

Votes:

0

Your Vote:

Up

Down

I have a PRTG instance running behind a router which is load balancing two isp's. For some reason in two separate instances where I am monitoring two outside routers, I am getting a failure when it goes out one of the isp's and not the other. I can see in the log on the routers that one of the isp's is fine as I can see the public ip over port 161, but for whatever reason when my prtg machine goes over that other isp, snmp fails for whatever reason. If a site to site vpn tunnel is in place with the remote router and the internal ip address is used in the prtg sensor, everything works fine. Not sure why this is the case. This has been driving me nuts for a while with the one remote device, but I chalked it up to someone block my public ip from using port 161 somewhere along the route. However, after deploying another router yesterday in a different location, I can confirm the same issue is present. Is there something in PRTG causing this issue?

load-balance prtg snmp snmp-failure

Created on Apr 8, 2015 9:04:24 PM by  Bob Boklewski (0) 1



6 Replies

Accepted Answer

Votes:

7

Your Vote:

Up

Down

Hi Bob,

so you have 2 different public IPs that monitor the remote routers?

Are you able to see at least the incoming SNMP packets on the remote routers, when you are using ISP2?

Are both those IPs allowed via an ACL or similar on the remote routers?

What about a ping sensor or maybe SSH/HTTP(S), is this working over both ISPs?

I could imagine issues due to SNMP being a UDP protocol only, though you might face NAT issues or similar.

Created on Apr 9, 2015 9:43:27 AM by  Lars (1,150) 2 1



Votes:

0

Your Vote:

Up

Down

The WANs are using two different public ip's. There are two ACL's in place to allow snmp from both of these public ip addresses. Ping seems to work just fine, snmp is not. It seems that in both remote offices the isp that snmp is not working over is the same one. I can see the connection acceptance for the ACL's in the log and the same ip is listed. The ip for the other WAN is never listed. I have no idea why this is happening.

Created on Apr 29, 2015 2:46:33 PM by  Bob Boklewski (0) 1



Votes:

0

Your Vote:

Up

Down

Yes, we have 2 isp's being load balanced on our firewall. Hence, 2 different public ip's that snmp can travel over. I don't see the snmp traffic hit the remote routers over the one isp being load balanced on our firewall.

Both isp's are allowed on the remote routers via ACL.

I am testing the ping sensor but it seems to be fine.

Yeah, I can see that UDP could cause an issue, but it never works over the one isp, ever. The only thing I haven't tried is setting a static nat on my machine to go over the isp we are having issues with. I am just failing to understand how snmp can have issues with one isp and not the other.

Created on May 19, 2015 1:28:44 AM by  Bob Boklewski (0) 1



Votes:

0

Your Vote:

Up

Down

Dear Bob,

please check if you entered both of PRTG's IPs as accepted host.

Created on May 21, 2015 2:34:41 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Assuming you are referring to the remote router's ACL list? Or are you talking about a PRTG setting?

Created on May 21, 2015 3:21:53 PM by  Bob Boklewski (0) 1



Votes:

0

Your Vote:

Up

Down

Hi Bob,

Some devices require an "Accept SNMP packets from these hosts" entry for both public IP addresses from your load balancer. Could you please check if the router accepts packets from both IPs? As the SNMP requests are working from one ISP, I assume that this might be caused by security restrictions of the target device.

Best regards

Created on May 25, 2015 3:14:26 AM by  Felix Saure [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.