Troubleshooting Routing Issue of an RLI 2

[rachelle]

Route 104 has 8 T1s assigned as members.
RLI 104 has entry 0 to this RT 104 members.
RLI 104 has entry 1 LTRE yes and sends calls to a menu service.

Callers to this route are hitting the menu service even though the members of RT 104 are available. What would cause this? How would I troubleshoot?


rlc

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.

 

[trvlr1]

Have you tried setting up a maintenance phone and testing lines? You would know exactly where the call is and you can point it out to a Cisco tech to see what they see.

 

[allenmac]

If the TGAR on the inbound trunk is 1, then it will be blocked because the TARG on your Route 104 is also 1.

 

[phnechic]

Looks to me like you have a match on the TGAR and TARG settings between the route and the tie line, which would deny the call. It's been a while since I worked on this system, so maybe I'm crazy. What do you think?

 

[phnechic]

Sorry, allenmac, didn't refresh before I posted. I agree with your post.

 

[rachelle]

If that is the case then, none of my calls would be processing. Right? All of the trunk members are set to 1 so, why would some work and some not work??? I don't mess with TGAR/TARG.

How would I use a test set to test? I have one configured but, haven't used it in years.
Recommendation???



no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.

 

[bigindian65]

That would only matter if TGAR is set to YES in ESN block ld 86.

Mato' Was'aka

 

[rachelle]

TGAR is set to NO in the ESN.


rlc

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.

 

[phnechic]

Then I would suggest what trvlr1 indicated:

Turn on the DCH messaging during a low call volume time and that will allow you to show the Cisco folks that you are seeing the calls get rejected by Call Manager (or will help you identify where in the Nortel switch you are having problems). In LD 96, use the ENL MSGO X and ENL MSGI X to see the full call flow in and out of that DCH.

 

[allenmac]

dam, just when I thought I was onto something.

+1 for trvlr1 and phnechic. D-channel message monitoring should prove it.

I would also try logging the D-channel messages on the call manager side during your test to make sure the calls match up.

 

[habbe1]

Just a thought;

It seems liley that a mis-match exists between the PRI configuration between the Nortel and the Cisco.

I would think a likely cause would be that on at least one of the 8 PRI's in your ISDN pipe, a mis-match exists on the Interface ID.

When you configure the D-Channel, an Interface ID of zero is hard-coded for the circuit that carries the Primary D-Channel - Interface ID is hard coded to one for the circuit that carries the Back-up D-Channel. By hard coded I mean you cannot change them on the Nortel side - the other side - in this case cisco, may be able to change their side - but they must use zero for the circuit that carries Prime D-Channel and one for the circuit that carries a Backup D-Channel so they match with the Nortel side.

The rest of the circuits are added be controlled by the D-Channel at the PRI prompt of the D-Channel Adan.
Example:

PRI 106 3
PRI 107 4
PRI 108 5
PRI 109 6

In the example, the Interface ID for loop 106 is 3.

This must match the interface ID for the same circuit on the CISCO side - if not, the symptom will be;

PRI is up - all channels idle - unable to make calls on this circuit.

If a mis-match exists mid-way into your route member list, this may be why you find calls successful during low traffic, but not successfull when traffic is heavy and the mis-matched circuit is accessed.

The advise in earlier posts suggesting either the use of a maintenance set to access specific trunks may help you to isolate the failing circuit. Or you could also disable some of the circuits (as suggested earlier) to force traffic onto specific circuits to identify which work and which fail.

Either way, once you have identified the failing circuits, you may need to speak to the person configuring the CISCO side so that you can be sure the circuits match.

I also noticed that IFC D100 was used in the RDB - is that correct and matching what the Cisco is emulating?