Advice on troubleshooting Server connectivity

[Mark Mattix]

An application in my organization will intermittently have connectivity issues to the Database it queries. For the purpose of testing, we installed the application directly onto the Database server and the user still had connectivity issues. Because of this, I don't believe it's related to the network. Would anyone have advice on what they would do in this situation? How can I verify throughout the entire day that the Database server is accessible on a specific port? I've used the command telnet, IP and port number but I'd like to make sure the connection is available throughout the entire day, is there a better tool I could use?

Thanks for your help!   -Mark

[Rolf Fischer · Accepted solution]

Hi Mark,

Cisco IP SLA could be interesting for you if you just want to check connectivity to the DB-server on a certain port:

http://www.cisco.com/en/US/tech/tk920/tsd_technology_support_sub-protocol_home.html

You could e.g. configure a TCP-connect measurement for the port used for database traffic:

http://www.cisco.com/en/US/docs/ios/ipsla/configuration/guide/sla_tcp.html

If you don't want to configure this on a producitve router or switch, just take a Cisco device from the warehouse and use it as an "IP SLA probe".

HTH

Rolf

[Mark Mattix]

Thank you very much for that info! I will try this!

[Mark Mattix]

Well I configured this on a new device to be used as an SLA probe:

ip sla monitor 10

type tcpConnect dest-ipaddr 192.168.1.100 dest-port 1433

ip sla monitor schedule 10 life forever start-time now

!

and when I type the show ip sla mon stat, I see nothing but failed attempts. If I run a telnet session to the ip using the 1433 port from the same device, it opens the connection, so it seems like it should be working. I have a Cisco 1801 router running as the SLA probe to a Windows server. any idea of what might be wrong? I apprecaite the help! Also, what type of data or query is the sla probe sending to the server?

[Mark Mattix]

I reconfigured the SLA as follows:

ip sla monitor 10

type tcpConnect dest-ipaddr 192.168.1.100 dest-port 1433 source-ipaddr 10.10.10.100 source-port 1433

timeout 30

ip sla monitor schedule 10 life forever start-time now

The statistics are still coming up as failed.

[Rolf Fischer]

Mark,

could you try to add the "control disable" option to the "type tcpConnect" line and see if it works then?

[Mark Mattix]

That did the trick, thank you! I have let the TCPConnect process run for over an hour with no errors and did pings before it and also didn't notice errors. I was wondering though, it seems like after every hour the SLA statistics resets. Is the way to change this? Do I have to modify the the history time parameter?

Thanks!

[Rolf Fischer]

This commands might be useful:

history filter all

show ip sla history

hours-of-statistics-kept (replaced by the history hours-of-statistics-kept command in recent IOS)

For longer term monitoring you may want to use a management application to query objects of the ciscoRttMonMIB.

HTH

Rolf