ISDN PRI

[thisisshanky]

I have a customer who has a ISDN Voice PRI circuit. The circuit is terminated on a 2621 with NM-HDV. VWIC-2MFT-T1 and 4 DSP chips on board. The T1 controller seems to be UP. But the ISDN layer 2 status is still at TEI_ASSIGNED. Switch type is Primary-NI. There is a CallManager involved and this router is running MGCP with the CallManager. The T1 controller is configured to backhaul incoming calls to the CallManager. The version of software running on router is 12.2.15.T8

On doing a Debug isdn q921, I am getting messages incoming from the switch. But the router does not seem to send any thing back. I am waiting upon the customer to plug a loopback plug to check if the card is bad. Mean while any other thoughts or troubleshooting tips that anybody can think of would be greatly appreciated...

PS: When I remove the "no isdn bind-l3 ccm-manager" command from the D channel (serial 1/0:23 interface), the Layer 2 channel status comes up as MULTIPLE_FRAME_ESTABLISHED

Sankar.

[frazier24]

Check your MGCP settings on both the CCM and the GW.. See if CCM is "seeing" the GW via MGCP, because it seems that your CCM is not able to "control" the PRI. Now, if you were to do H.323, then the PRI is controlled directly from the GW, and is not reliant on CCM like MGCP is.

Lee

[adignan]

Ok, first off make sure this isn't an NM-HDV2. There is a horrid bug out right now w/ no resolution yet with the HDV2's and this exact problem.

Secondly, I ran into a similar situation where there were some access-lists applied that blocked port 2428 (pri backhaul port between CM and gateway)between the gateways loopback address (MGCP was bound to loopback) and the subnet CallManager resided on.

That fact that you get MULTIPLE_FRAME_ESTABLISHED when you unbind the pri from CM back to the gateway is a definate indicator that it is an CM > gateway communication issus.

[thisisshanky]

Its not NM-HDV2, a regular HDV. No ACLs, both CCM and gateway connected to same LAN switch. On the router, MGCP status is active, "show ccm-manager" displays the router to be registered with the primary callmanager. In the CallManager MGCP endpoint configuration page, I dont see the registration status to be successful, which makes it definite that there is some communication issue between the two entities..(See attached picture)...

Any further thoughts ?

[jasyoung]

The registration status under "show ccm-manager" basically means the router can successfully connect to the right TCP port on CallManager. It does mean you have IP connectivity, but it doesn't mean anything else.

Make sure your CallManager configuration is lined up just right with your router's hardware and software configuration. Do a "show mgcp endpoint" on your router and make sure that matches CallManager's idea of the endpoint name. One common problem here is being off by one hardware slot; the MGCP endpoint name is dependent on where the hardware is in the router. That probably can't be confused on a 2621, but I thought I'd mention it for future reference. It's even more common to have the wrong hostname configured in CallManager. If you have configured an 'ip domain-name' on the router, you absolutely must use the FQDN (routerhostname.domain.com) when configuring it in CallManager as an MGCP gateway. Otherwise, the MGCP endpoint names differ.

If none of this helps, post your password-sanitized gateway config.

[adignan]

Yeah, what jasyoung said...could post the output from "debug mgcp all". Unbind layer 3 from ccm on the voice-port then put the command back in all while you have debug mgcp all on and post that.

[mlinsemier]

I am running into this exact same problem on 2651XM's running 12.3(7)T2 and 12.3(8)T3. However, I have found a few ways to resolve the issue without changing the config, however what unbinding as stated above does work.

running a "clear mgcp statistics" establishes ISDN PRI layer 3 and sometimes reseting the gateway in CallManager will do it as well.

I definately want to see a resolution to this. I was about to open a ticket with TAC before I saw this forum. I am thinking day in and out that H.323 is a much better choice these days.

Matt

[thisisshanky]

Thank you for all the responses.

I am awaiting access to the router, to do the debugs and unbinding tests. Meanwhile,

I was diagnosing the VWIC with loopback tests. I plugged a hardloop on the VWIC, configured a channel group for 24 channels and configured hdlc as encapsulation and an IP address on the resulting serial interface.

Then did an extended ping to the configured IP address with various data patterns (0x0000, 0xaaaa, 0xffff) with 1500 bytes of data on each ping. I should have got a 100 percent success rate, but I am getting packet loss. There are no input errors under the serial interface statistics, but there are CRC errors. Doesnt this indicate a bad VWIC ?? Any thoughts in this direction ??

AHB-PRI-1#ping ip

Target IP address: 1.1.1.1

Repeat count [5]: 50

Datagram size [100]: 1500

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]: 0x1111

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 50, 1500-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

Packet has data pattern 0x1111

!!.!!!.!!!.!!!.!!!.!.!!!.!.!!!.!!!!!!.!!!.!!!.!.!!

Success rate is 74 percent (37/50), round-trip min/avg/max = 24/25/28 ms

AHB-PRI-1#ping ip

Target IP address: 1.1.1.1

Repeat count [5]: 50

Datagram size [100]: 1500

Timeout in seconds [2]:

Extended commands [n]: yes

Source address or interface:

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]: 0x0000

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 50, 1500-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

Packet has data pattern 0x0000

.!!!.!!!.!.!!!.!.!!!.!!!.!.!!!.!!!!!!.!!!.!!!.!.!!

AHB-PRI-1#ping ip

Target IP address: 1.1.1.1

Repeat count [5]: 50

Datagram size [100]: 1500

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]: 0xffff

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 50, 1500-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

Packet has data pattern 0xFFFF

.!!!.!.!.!.!..!.!.!.!.!!!.!..!.!.!.!.!!!.!..!!!.!.

Success rate is 54 percent (27/50), round-trip min/avg/max = 28/28/32 ms

AHB-PRI-1#

[smif101]

Remember you are not using the full T1 here, only the D channel. So it might be overloaded with those packet sizes. Try bringing it down to 64 bytes and see if that works.

[adignan]

Yeah, definately. I think once we get those debugs it will tell us exactly what is going on.

[thisisshanky]

Attached are the debugs!

[thisisshanky]

Here are the outputs with 64 bytes sizes..

AHB-PRI-1#ping ip

Target IP address: 1.1.1.1

Repeat count [5]: 1000

Datagram size [100]: 64

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]: 0x0000

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 1000, 64-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

Packet has data pattern 0x0000

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!.!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!

!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!.!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!.!!!!

!!!!!!!!!!!!!!!!!!!!

Success rate is 98 percent (987/1000), round-trip min/avg/max = 4/6/24 ms

AHB-PRI-1#

Will get the debugs for MGCP in the next post.

[smif101]

So what is the load of the interface when you have the pings going?

[thisisshanky]

Andrew, Regarding your statement about the bug with NM-HDV2's, what was the version of code running on the router and what router platform was it ?

[maharris]

Just to add a general comment in here somewhere, we have had a lot of issues with ISDN layer 2 on NM-HDV using MGCP, usually TAC traces it back to bug CSCec12689 - even if things behave slightly differently than the failure described in the bug, they read all the attached notes and tell us it is the same thing. We can often recover by doing a shut/no shut on the d channel, or as last resort, do global 'no mgcp' then 'mgcp'. Bug is resolved, shows fixed versions start at: 12.3(5.4), 12.3(5.5)T, 12.3(7)XI, 12.2(15)T12, 12.3(4)T06, 12.3(03g), 12.3(05d)

Mary Beth