Re: ISDN Error code 0x82E2 on PRI

phil_carter · ‎07-02-2008

Hello,

I've set up an ISDN line between a PRI on a 3845 running IOS c3845-ipbase-mz.124-3g.bin, and a BRI on 2811 running IOS c2800nm-advipservicesk9-mz.124-8d.bin. When testing (or pinging across) the ISDN from the 3845 the ISDN line comes up for a second and then drops each time. The following error code is seen:

Cause i = 0x82E2 - Message not compatible with call state or not implemented

I found the following bug code for a similar IOS release (on the 3845), but not sure if this covers my problem:

CSCsi14053

Symptoms: When a gateway responds to a request for information (for example, "CC_INFO_REQ:Ux_InfoReq(nlcb)") from a service provider with an information message for incoming calls, the service provider releases the call with a message similar to the following one:

Q931: RX <- RELEASE pd = 8 callref = 0x00B2

Cause i = 0x82E2 - Message not compatible with call state or not implemented

Conditions: This symptom is observed when a Cisco platform that runs Cisco IOS Release 12.4(9)T2 or Release 12.4(11)T1 dials into a third-party vendor switch via a PRI.

Can anyone advise why the ISDN line drops continually every second and doesn't remain up? Interestingly, if you test the line with >1 calls it will stay up the default 120seconds before dropping....

Thanks

Phil

paolo bevilacqua · ‎07-02-2008

Hi,

One would need to see the full q931 trace to see in which context the message is thrown and who is to blame about.

phil_carter · ‎07-03-2008

Q931 debug info:

Jul 3 09:27:25: ISDN Se1/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0088

Bearer Capability i = 0x8890

Standard = CCITT

Transfer Capability = Unrestricted Digital

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9839F

Exclusive, Channel 31

Called Party Number i = 0x81, ''

Plan:ISDN, Type:Unknown

Jul 3 09:27:25: ISDN Se1/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x8088

Channel ID i = 0xA9839F

Exclusive, Channel 31

Jul 3 09:27:26: ISDN Se1/0:15 Q931: RX <- CONNECT pd = 8 callref = 0x8088

Jul 3 09:27:26: %LINK-3-UPDOWN: Interface Serial1/0:30, changed state to up

Jul 3 09:27:26: %ISDN-6-CONNECT: Interface Serial1/0:30 is now connected to 011

62852587 N/A

Jul 3 09:27:26: ISDN Se1/0:15 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0088

Jul 3 09:27:26: ISDN Se1/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x8088

Cause i = 0x8090 - Normal call clearing

Jul 3 09:27:26: %LINK-3-UPDOWN: Interface Serial1/0:30, changed state to down

Jul 3 09:27:26: ISDN Se1/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x0088

Jul 3 09:27:26: ISDN Se1/0:15 Q931: RX <- STATUS pd = 8 callref = 0x8088

Cause i = 0x82E2 - Message not compatible with call state or not impleme

nted

Call State i = 0x0C

Jul 3 09:27:26: ISDN Se1/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8088

Jul 3 09:27:27: ISDN Se1/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0

x1, Called num

paolo bevilacqua · ‎07-03-2008

Hi,

you are receiving a a disconnect:

Jul 3 09:27:26: ISDN Se1/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x8088

That is unrelated with the status messages, that comes after and is likely only a cosmetic issue.

You should look at the PPP debugs of the other router to see why it is disconnecting.

phil_carter · ‎07-03-2008

It looks as though it closes as a normal call, but it only stays up for a split second each time.... it should stay up for the default period. Logs from the other end (2811):

Jul 3 10:26:59: ISDN BR0/1/0 Q931: RX <- SETUP pd = 8 callref = 0x01

Sending Complete

Bearer Capability i = 0x8890

Standard = CCITT

Transfer Capability = Unrestricted Digital

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0x89

Calling Party Number i = 0x00A3, N/A

Plan:Unknown, Type:Unknown

Called Party Number i = 0x81, ''

Plan:ISDN, Type:Unknown

Jul 3 10:26:59: %LINK-3-UPDOWN: Interface BRI0/1/0:1, changed state to up

Jul 3 10:26:59: %ISDN-6-CONNECT: Interface BRI0/1/0:1 is now connected to N/A N

/A

Jul 3 10:26:59: ISDN BR0/1/0 Q931: TX -> CALL_PROC pd = 8 callref = 0x81

Channel ID i = 0x89

Jul 3 10:26:59: BR0/1/0:1 PPP: Using dialer call direction

Jul 3 10:26:59: BR0/1/0:1 PPP: Treating connection as a callin

Jul 3 10:26:59: BR0/1/0:1 PPP: Session handle[A0000710] Session id[963]

Jul 3 10:26:59: BR0/1/0:1 PPP: Phase is ESTABLISHING, Passive Open

Jul 3 10:26:59: BR0/1/0:1 LCP: State is Listen

Jul 3 10:26:59: ISDN BR0/1/0 Q931: TX -> CONNECT pd = 8 callref = 0x81

Jul 3 10:26:59: ISDN BR0/1/0 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x01

Jul 3 10:26:59: ISDN BR0/1/0 Q931: TX -> DISCONNECT pd = 8 callref = 0x81

Cause i = 0x8090 - Normal call clearing

Jul 3 10:26:59: ISDN BR0/1/0 Q931: RX <- RELEASE pd = 8 callref = 0x01

Jul 3 10:26:59: %LINK-3-UPDOWN: Interface BRI0/1/0:1, changed state to down

Jul 3 10:26:59: ISDN BR0/1/0 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x81

Jul 3 10:26:59: BR0/1/0:1 LCP: State is Closed

Jul 3 10:26:59: BR0/1/0:1 PPP: Phase is DOWN

rgodden · ‎07-03-2008

still check your ppp authentication debugs ,

phil_carter · ‎07-03-2008

Jul 3 12:46:59: ISDN BR0/1/0 Q931: RX <- SETUP pd = 8 callref = 0x01

Sending Complete

Bearer Capability i = 0x8890

Standard = CCITT

Transfer Capability = Unrestricted Digital

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0x89

Calling Party Number i = 0x00A3, N/A

Plan:Unknown, Type:Unknown

Called Party Number i = 0x81, ''

Plan:ISDN, Type:Unknown

Jul 3 12:46:59: %LINK-3-UPDOWN: Interface BRI0/1/0:1, changed state to up

Jul 3 12:46:59: %ISDN-6-CONNECT: Interface BRI0/1/0:1 is now connected to N/A N

/A

Jul 3 12:46:59: ISDN BR0/1/0 Q931: TX -> CALL_PROC pd = 8 callref = 0x81

Channel ID i = 0x89

Jul 3 12:46:59: BR0/1/0:1 PPP: Using dialer call direction

Jul 3 12:46:59: BR0/1/0:1 PPP: Treating connection as a callin

Jul 3 12:46:59: BR0/1/0:1 PPP: Session handle[72000728] Session id[987]

Jul 3 12:46:59: BR0/1/0:1 PPP: Phase is ESTABLISHING, Passive Open

Jul 3 12:46:59: BR0/1/0:1 LCP: State is Listen

Jul 3 12:46:59: ISDN BR0/1/0 Q931: TX -> CONNECT pd = 8 callref = 0x81

Jul 3 12:46:59: ISDN BR0/1/0 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x01

Jul 3 12:46:59: ISDN BR0/1/0 Q931: TX -> DISCONNECT pd = 8 callref = 0x81

Cause i = 0x8090 - Normal call clearing

Jul 3 12:47:00: ISDN BR0/1/0 Q931: RX <- RELEASE pd = 8 callref = 0x01

Jul 3 12:47:00: %LINK-3-UPDOWN: Interface BRI0/1/0:1, changed state to down

LCP doesn't appear to OPEN nor does CHAP authentication seem to take place. Usernames are present on both routers and both have ppp encapsulation configured. Your help is appreciated....

paolo bevilacqua · ‎07-03-2008

Hi, as mentioned before, you need "debug ppp negotiation" and "debug ppp authentication" taken on the router that is disconnecting.

phil_carter · ‎07-10-2008

Hi,

Debug ppp authentication & debug ppp negotiation logs:

Dialling router:

Jul 10 15:42:32: %LINK-3-UPDOWN: Interface BRI0/1/0:1, changed state to up

Jul 10 15:42:32: %ISDN-6-CONNECT: Interface BRI0/1/0:1 is now connected to N/A

Jul 10 15:42:32: BR0/1/0:1 PPP: Using dialer call direction

Jul 10 15:42:32: BR0/1/0:1 PPP: Treating connection as a callout

Jul 10 15:42:32: BR0/1/0:1 PPP: Session handle[A8000735] Session id[1000]

Jul 10 15:42:32: BR0/1/0:1 PPP: Phase is ESTABLISHING, Active Open

Jul 10 15:42:32: BR0/1/0:1 PPP: Authorization NOT required

Jul 10 15:42:32: BR0/1/0:1 LCP: O CONFREQ [Closed] id 111 len 15

Jul 10 15:42:32: BR0/1/0:1 LCP: AuthProto CHAP (0x0305C22305)

Jul 10 15:42:32: BR0/1/0:1 LCP: MagicNumber 0x824CE0F5 (0x0506824CE0F5)

Jul 10 15:42:32: %LINK-3-UPDOWN: Interface BRI0/1/0:1, changed state to down

Jul 10 15:42:32: BR0/1/0:1 PPP: Sending Acct Event[Down] id[1794]

Jul 10 15:42:32: BR0/1/0:1 LCP: State is Closed

Jul 10 15:42:32: BR0/1/0:1 PPP: Phase is DOWN

Jul 10 15:42:36: %LINK-3-UPDOWN: Interface BRI0/1/0:1, changed state to up

Jul 10 15:42:36: %ISDN-6-CONNECT: Interface BRI0/1/0:1 is now connected to N/A

Jul 10 15:42:36: BR0/1/0:1 PPP: Using dialer call direction

Jul 10 15:42:36: BR0/1/0:1 PPP: Treating connection as a callout

Jul 10 15:42:36: BR0/1/0:1 PPP: Session handle[51000736] Session id[1001]

Jul 10 15:42:36: BR0/1/0:1 PPP: Phase is ESTABLISHING, Active Open

Jul 10 15:42:36: BR0/1/0:1 PPP: Authorization NOT required

Jul 10 15:42:36: BR0/1/0:1 LCP: O CONFREQ [Closed] id 112 len 15

Jul 10 15:42:36: BR0/1/0:1 LCP: AuthProto CHAP (0x0305C22305)

Jul 10 15:42:36: BR0/1/0:1 LCP: MagicNumber 0x824CF092 (0x0506824CF092)

Jul 10 15:42:36: %LINK-3-UPDOWN: Interface BRI0/1/0:1, changed state to down

Jul 10 15:42:36: BR0/1/0:1 PPP: Sending Acct Event[Down] id[1795]

Jul 10 15:42:36: BR0/1/0:1 LCP: State is Closed

Jul 10 15:42:36: BR0/1/0:1 PPP: Phase is DOWN

Remote router logs:

Jul 10 15:43:31: %LINK-3-UPDOWN: Interface Serial1/0:0, changed state to up

Jul 10 15:43:31: %ISDN-6-CONNECT: Interface Serial1/0:0 is now connected to N/A

Jul 10 15:43:31: Se1/0:0 PPP: Using dialer call direction

Jul 10 15:43:31: Se1/0:0 PPP: Treating connection as a callin

Jul 10 15:43:31: Se1/0:0 PPP: Session handle[2E000060] Session id[65]

Jul 10 15:43:31: Se1/0:0 PPP: Phase is ESTABLISHING, Passive Open

Jul 10 15:43:31: Se1/0:0 LCP: State is Listen

Jul 10 15:43:31: %LINK-3-UPDOWN: Interface Serial1/0:0, changed state to down

Jul 10 15:43:31: Se1/0:0 LCP: State is Closed

Jul 10 15:43:31: Se1/0:0 PPP: Phase is DOWN

Jul 10 15:43:35: %LINK-3-UPDOWN: Interface Serial1/0:0, changed state to up

Jul 10 15:43:35: %ISDN-6-CONNECT: Interface Serial1/0:0 is now connected to N/A

Jul 10 15:43:35: Se1/0:0 PPP: Using dialer call direction

Jul 10 15:43:35: Se1/0:0 PPP: Treating connection as a callin

Jul 10 15:43:35: Se1/0:0 PPP: Session handle[2000061] Session id[66]

Jul 10 15:43:35: Se1/0:0 PPP: Phase is ESTABLISHING, Passive Open

Jul 10 15:43:35: Se1/0:0 LCP: State is Listen

Jul 10 15:43:35: %LINK-3-UPDOWN: Interface Serial1/0:0, changed state to down

Jul 10 15:43:35: Se1/0:0 LCP: State is Closed

Jul 10 15:43:35: Se1/0:0 PPP: Phase is DOWN

rgds,

Phil

paolo bevilacqua · ‎07-10-2008

Hi, is the router with se1/0 working for other sites ? Which exact HW it has ?

Reason, it doesn't appear to receive any packet from the BRI routr, nor it sends any, that is very strange.

phil_carter · ‎07-10-2008

Hi,

The dialling router has 2 bri's for 2 different remote sites (each on a pri), and both are seeing them same result. The router hardware is:

LEI_UTN_2811_01#sh ver

Cisco IOS Software, 2800 Software (C2800NM-ADVIPSERVICESK9-M), Version 1

RELEASE SOFTWARE (fc2)

Technical Support: http://www.cisco.com/techsupport

Compiled Wed 25-Jul-07 17:05 by prod_rel_team

ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)

LEI_UTN_2811_01 uptime is 9 weeks, 6 days, 59 minutes

System returned to ROM by Reload Command

System restarted at 15:44:01 BST Fri May 2 2008

System image file is "flash:/c2800nm-advipservicesk9-mz.124-8d.bin"

This product contains cryptographic features and is subject to United

States and local country laws governing import, export, transfer and

use. Delivery of Cisco cryptographic products does not imply

third-party authority to import, export, distribute or use encryption.

Importers, exporters, distributors and users are responsible for

compliance with U.S. and local country laws. By using this product you

agree to comply with applicable laws and regulations. If you are unable

to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be fou

http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to

export@cisco.com.

Cisco 2811 (revision 53.51) with 249856K/12288K bytes of memory.

Processor board ID FCZ121173TB

2 FastEthernet interfaces

2 ISDN Basic Rate interfaces

1 Virtual Private Network (VPN) Module

DRAM configuration is 64 bits wide with parity enabled.

239K bytes of non-volatile configuration memory.

62720K bytes of ATA CompactFlash (Read/Write)

Configuration register is 0x2102

It dials 2 remote routers, both 3845's running the same IOS:

SLH_UTN_3845_01#sh ver

Cisco IOS Software, 3800 Software (C3845-IPBASE-M), Version 12.4(3g), RELEASE S

FTWARE (fc2)

Technical Support: http://www.cisco.com/techsupport

Compiled Mon 06-Nov-06 05:34 by alnguyen

ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)

SLH_UTN_3845_01 uptime is 9 weeks, 1 day, 2 hours, 50 minutes

System restarted at 13:58:25 BST Wed May 7 2008

System image file is "flash:c3845-ipbase-mz.124-3g.bin"

Cisco 3845 (revision 1.0) with 223232K/38912K bytes of memory.

Processor board ID FCZ1121718R

2 Gigabit Ethernet interfaces

62 Serial interfaces

2 Channelized E1/PRI ports

DRAM configuration is 64 bits wide with parity enabled.

479K bytes of NVRAM.

62720K bytes of ATA System CompactFlash (Read/Write)

Configuration register is 0x2102

I upgraded one of the 3845's to a new IOS (c3845-ipbase-mz.124-19b.bin) as the bug I mentioned does list 124-3g as affected, but the same thing happens when dialling.

rgds

Phil

phil_carter · ‎07-10-2008

Answer to your question about the remote router with Se1/0 dialling other sites - no. The remote router doesn't dial out to any site, it is only used to dial in via the single router.