I have a site that was added just fine, but for some reason a call path cannot be created. The code is fine ( i have another site with the same code working fine) RW community, and no ACLs blocking any traffic are on the path. When I sniff traffic from the server to this site, I don't even see any packets to configure the SLA probe. Anyone know of a way to fix this? I have voip v1 with the latest hot fix, going to v2 is not an option at the moment.
Run through the process again to make sure that the latest logs have captured what is going on. Then run ...\Program Files\SolarWinds\Orion\SolarWinds.Diagnostics.exe and it will create a diagnostics dump. Send that dump to me via private thwack mail. The logs should show the reason for the call path creation failure.
hmm looking at the log, it looks like I am not getting a response for this:
2008-02-05 08:50:30,769 [Scheduler] DEBUG SolarWinds.Common.Snmp.Agent - SNMP Request - 10.136.26.2 - Get:
18.104.22.168.22.214.171.124.126.96.36.199.1.9.1 = (OID_TYPE_NULL)
where the other routers that work do respond to that, even though I have the same IOS.
Cisco's response to that was:
In order for this object to become active, the following row objects must be
- for echo, pathEcho based on 'ipIcmpEcho' and dlsw probes
- for echo, pathEcho based on 'mplsLspPingAppl'
- for udpEcho, tcpConnect and jitter probes
- for http and ftp probe
- for dns probe
- dhcp probe doesn't require any additional objects
All other objects can assume default values. The
conceptual Rtt control row will be placed into a
'pending' state (via the rttMonCtrlOperState object)
if rttMonScheduleAdminRttStartTime is not specified.
Most conceptual Rtt control row objects cannot be
modified once this conceptual Rtt control row has been
created. The objects that can change are the following:
- Objects in the rttMonReactAdminTable can be modified
as needed without setting this object to
- Objects in the rttMonScheduleAdminTable can be
modified only when this object has the value of
- The rttMonCtrlOperState can be modified to control
the state of the probe.
Once this object is in 'active' status, it cannot be
set to 'notInService' while the rttMonCtrlOperState
is in 'active' state. Thus the rttMonCtrlOperState
object must be transitioned first.
This object can be set to 'destroy' from any value
at any time."
Is voip2 and option at this point?
You identified what what going on in the log correctly. The OID was showing as not supported. In VoIP 2.0 we have changed the way we check for support. There was no fool proof way to get the appropriate OIDs so during support check we setup an actual operation and then remove it. This takes care of the issue in 1.0 where some configurations failed even though they should have worked.
If you want to verify 2.0 will work for you but you can't upgrade to it yet you can setup an eval on a spare machine and set up the call path in question.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.