Hi, I want to do what it seems very simple thing: on arrival of snmpget alarm, test access to the host of interest using ping before making snmpget alarm visible. I have pretty much AO profiles worked out, I am just struggling with LUA script.
Is there any way to issue five or more ping commands to net_connect probe via nimbus.request call (or any other way to check connectivity to host of interest)? Note that I can't directly test ping from main NAS as we run distributed hub architecture to support multiple clients.
Thanks in advance.
Why do you need to issue five or more ping requests? You can test connectivity using the test_service callback of the net_connect probe. It looks to me like this would issue one or more ping requests if the port is not specified, although I am not completely sure. There is no option to control the number of requests. You could probably verify the behavior with a packet capture or open a support case to have someone check the code for a definite answer. I do not think there is a whitepaper for that probe yet, so there is probably nowhere to find documentation about the callbacks.
I noticed that if you try to test an IP that is not available, it takes a little while for the attempt to timeout and the callback to return a status.
thanks for reply. If test_service callback of the net_connect probe issues multiple ping tests (when port is not specified) before returning the result, then it is great. Can you insert quick snippet of your code how you use test_service callback? I can't seem to get the result just by specifying hostname variable. Thanks.
Hi, I did some more testing. It seems that I need to use ip variable vs. hostname variable for test_service callback and I can put either actual ip or hostname as the value.
However, I noticed the following:
1. when I issue test_service command via net_connect probe utility, I see ICMP traffic being initiated and returned state of the command = 1
2. when I run below script, I get state = 0 and I don't see any ICMP (or any other protocol) traffic being initiated to the host of interest (I am using sniffer to look @ the traffic)
args = pds.create()
status,rc = nimbus.request(net_connect,"test_service",args)
if rc ~= 0 then
printf("Unable to query the net_connect probe '%s'",net_connect)
for k,p in pairs (status) do
----------- Executing script at 10/8/2010 3:34:31 PM ----------
Any thoughts why I see the differentce between results returned by probe utility and script?
I think you might be sending to the wrong net_connect.
Maybe this is what you meant:
status,rc = nimbus.request(hubaddr.."/"..net_connect,"test_service",args)
Does that help? In this case, the hubaddr variable needs to be the nimaddress for the robot running the hub rather than the nimaddress for the hub component itself. (Hopefully I said that in a way that make sense.)
Nice work on validating with a sniffer. Always good to know it is doing what you think it should...
thanks for pointing the probe address issue. I was able to accomplish what I needed. Thanks again.
You could always issue a external ping command from the system if the test_service doesn't give you what you want. I use to use this when I recieved some snmpget alarms I would go poll some other oids on the system and get the exact alarm and parse the output.
can you tell me the method you used to issue external ping in distributed environment? Meaning from my main hub NAS my host of interest is not reachable via external ping. I would need to issue an external ping on the different hub to get the appropriate result. Is there any way to executed external command on remote hub calling it from main hub NAS?
The nexec probe runs preconfigured commands in response to requests. You can configure arguments for each command that can be specified in the requests.
You could also create a custom probe that does the ping for you and send a request to that probe from the NAS. The one advantage of this option is that the probe could interpret the ping results and send back a simple pass/fail answer back to the NAS. Of course, I do not think it would be difficult for the NAS to interpret the results that it gets back from the nexec probe.