Hi mmunford -
Can you verify that the IPSLA source node (the node running the IPSLA operation) can access the web servers hosting your applications?
Just because your browser can access the web sites doesn't necessarily mean the node actually running the IPSLA operation is able to reach the same web sites.
Hope this helps.
The error you're seeing is tied to an error response from the router itself.
Here is a link to Cisco's instructions for debugging the HTTP operation. You'll want to use the "debug" router commands to determine the cause of the router not being able to execute the HTTP operation. Is the device low on resources? (memory/CPU)?
Hope this helps.
I have the same issue if i use dns names in the url
But if i use the IP address for the HTTP IP SLA it works fine
Is this a know issue and also when we create a new IP SLA operation it is transferred to the switch the opertaion is created but the config is not saved in the switch (wr mem)
Can you please clarify?
I hadn't had time to dig into the Router Debugs as I had promised earlier.. I just circled back to this this morning after the other thread discussion and have this to report:
In my case, the DNS resolution works fine to the HTTP sites that produce the failure. Changing the operation to use the IP address instead of the FQDN did not make a difference. Here's my new info to add here. It seems if I browse to the URL using a browser and using the FQDN, I can see the site. Browsing using the IP address alone produces an HTTP error message (connection reset in my case). I am assuming from this finding that the IPSLA operation is not passing the URL FQDN as part of the HTTP request. Rather, it seems that perhaps it is resolving the IP via DNS and then constructing a HTTP request using the resolved IP?? I have not done any captures to confirm this yet..
I also did a spot check comparison of the Running and Startup configs on the Router hosting the IPSLA operations and found them to be inconsistent as well..
The "debug RTR Trace <operation>" produces this output:
.Nov 2 15:48:09.429 est: SAA(40019) Scheduler: Starting an operation
.Nov 2 15:48:09.429 est: SAA(40019) http operation: Starting http operation
.Nov 2 15:48:09.429 est: SAA(40019) dns operation: Starting dns operation
.Nov 2 15:48:09.429 est: SAA(40019) dns operation: Query name - laradirect.cma-cgm.com
.Nov 2 15:48:09.429 est: SAA(40019) dns operation: Query name server - 10.150.8.4
.Nov 2 15:48:09.429 est: SAA(40019) dns operation: Query return code - no error
.Nov 2 15:48:09.429 est: SAA(40019) dns operation: received IP Address 10.0.101.1
.Nov 2 15:48:09.429 est: SAA(40019) dns operation: RTT=1
.Nov 2 15:48:09.533 est: SAA(40019) http operation: Sent 18 of 18 bytes
.Nov 2 15:48:09.533 est: SAA(40019) http operation: Wait connection - connected
.Nov 2 15:48:11.473 est: SAA(40019) Scheduler: Updating result
I tried to manually add a custom IPSLA operation that specified a HTTP RAW request to the target server, but I'm not sure I had the correct syntax.. I'm going to attempt it again soon.
This logically leads to my next question: If I can manually contruct the appropriate HTTP RAW query, What needs to happen to get ORION to pickup the manual operation for display?? perhaps I missed this in the Docs??
Once you have created the IPSLA operation manually on the router, make a note of the operation number.
Then, go through the Add Operations wizard in IPSLA Manager. Instead of creating a new operation, you need to choose the "monitor existing" option.
Toward the end of the wizard, you will have the opportunity to enter the operation number for the custom operation.
Hope this helps,
I have made some progress, but am still not quite there yet...
I was able to manually create an IPSLA HTTP RAW request operation that does not produce the socket error and appears to generate a valid HTTP page download from the target.
This Syntax seems to correctly satisfy the server's Host Header requirement (notice the placement of multiple \r\n codes):
type http operation raw url http://target.webserver.com
GET / HTTP/1.1\r\nHOST: target.webserver.com\r\n\r\n
rtr schedule 40007 life forever start-time now ageout 3600
And a Packet capture confirms the operation seems to be working:
GET / HTTP/1.1
HTTP/1.1 200 OK
Set-Cookie: 1113915402.25886.0000; path=/
Date: Tue, 17 Nov 2009 22:08:16 GMT
Server: Oracle-Application-Server-10g/10.1.2.2.0 Oracle-HTTP-Server
Last-Modified: Tue, 29 Sep 2009 13:52:40 GMT
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
<title>Target Home Page</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link href="LHP_homepage.css" rel="stylesheet" type="text/css">
---->Additional Output Truncated<----
I have added the manual operation to IPSLA using the operation number as outlined earlier in this thread (and of course the Docs, if you pay attention!).
Now the IPSLA operation details show a status of "Operation timed out." with RTT, DNS RTT and Tranaction RTT all at 0ms, and TCP connect RTT at 100ms.
I've cranked up the RTT thresholds just for kicks, with no difference in status..