cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 9

problems adding a new call path

 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.

thanks 

0 Kudos
4 Replies
Level 13

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.

0 Kudos

 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:
    1.3.6.1.4.1.9.9.42.1.2.1.1.9.1 =  (OID_TYPE_NULL)

where the other routers that work do respond to that, even though I have the same IOS.  

0 Kudos

 Cisco's response to that was:

 

In order for this object to become active, the following row objects must be

defined:

        - rttMonCtrlAdminRttType

      Additionally:

        - for echo, pathEcho based on 'ipIcmpEcho' and dlsw probes

          rttMonEchoAdminProtocol and

          rttMonEchoAdminTargetAddress;

        - for echo, pathEcho based on 'mplsLspPingAppl'

          rttMonEchoAdminProtocol, rttMonEchoAdminTargetAddress

           and rttMonEchoAdminLSPFECType

        - for udpEcho, tcpConnect and jitter probes

          rttMonEchoAdminTargetAddress and

          rttMonEchoAdminTargetPort

        - for http and ftp probe

          rttMonEchoAdminURL

        - for dns probe

          rttMonEchoAdminTargetAddressString

          rttMonEchoAdminNameServer

        - 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

          'notInService'.

        - Objects in the rttMonScheduleAdminTable can be

          modified only when this object has the value of

         'notInService'.

        - 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? 

0 Kudos

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.

0 Kudos