E1 Controller down shwoing: Receiver is getting AIS

==========================================
Hi,
I have an E1 controller that is down indicating a rx AIS....As shown below
E1 0/0/0 is down.
Applique type is Channelized E1 - balanced
Receiver is getting AIS.
alarm-trigger is not set
Version info Firmware: 20070320, FPGA: 20, spm_count = 0
Framing is CRC4, Line Code is HDB3, Clock Source is Line.
CRC Threshold is 320. Reported from firmware is 320.
Data in current interval (598 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 598 Unavail Secs
Answer:
Receiver is getting AIS--->It can be either a circuit fault, or the device on th
e other end is turned off or port shutdown.
Yes, an inactive port on the switch would show AIS to your side. Telco Switch
loopback local line ---> under controller Line loopback transmits the received
bitstream as it is.
loopback local Payload---->generates framing as interface normally does, and onl
y retransmits the data portion in T1/E1.

2811 PRI Issues - show isdn status is TEI_ASSIGNED

===========================================
I've done all manner of troubleshooting on this PRI but it never goes to MULTIPL
E_FRAME_ESTABLISHED. We checked the Switch Type against that of the telco and i
t is PRIMARY-NI. I've checked framing and linecode and we match that of the tel
co.
When I loop the router T1 port, the show isdn status output shows Layer1 is acti
ve. Loopback tests that the telco has performed on their smartjack are successf
ul also. Can anyone draw any conclusions as to a root cause?
debug isdn q921 output follows:
Dec 9 18:18:20.947 UTC: ISDN Se0/0/0:23 Q921: L2_EstablishDataLink: sending SAB
ME

Dec
Dec
Dec
ME
Dec
Dec
Dec
ME
Dec
Dec

9 18:18:20.947 UTC: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0
9 18:18:20.955 UTC: ISDN Se0/0/0:23 Q921: User RX <- DMf sapi=0 tei=0
9 18:18:25.955 UTC: ISDN Se0/0/0:23 Q921: L2_EstablishDataLink: sending SAB
9 18:18:25.955 UTC: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0
9 18:18:26.003 UTC: ISDN Se0/0/0:23 Q921: User RX <- DMf sapi=0 tei=0
9 18:18:31.004 UTC: ISDN Se0/0/0:23 Q921: L2_EstablishDataLink: sending SAB
9 18:18:31.004 UTC: ISDN Se0/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0
9 18:18:31.012 UTC: ISDN Se0/0/0:23 Q921: User RX <- DMf sapi=0 tei=0

Answer:
Telco switch is sending DM - Disconnect Mode. Meaning it actively refuses connec
tion.
Show this trace to them, if they still refuse to act, have them come onsite with
their own call testing equipment, sit back, and enjoy the show.

Debug ISDN Q.921 Details

=======================
Output Meaning
ISDN BR0: This is the interface.
TX -> This router is sending this information.
RX <- This router is receiving this information.
SABME Indicates the Set Asynchronous Balanced Mode Extended command.
This command places the recipient into modulo 128 multiple
frame acknowledged operation. This command also indicates
that all exception conditions have been cleared.
sapi Identifies the service access point at which the Data-Link layer
entity provides services to layer 3 or to the management layer. A
SAPI with the value 0 indicates it is a call control procedure.
IDCKRQ ri = 0 ai = 127 Indicates the Identity Check Request message type sent fr
om the
ISDN service provider on the network to the local router during
the TEI check procedure. This message is sent in a UI command
frame. The ri field is always 0. The ai field for this message contains
either a specific TEI value for the local router to check or 127,
which indicates that the local router should check all TEI values.
IDREM This indicates the Identity Remove message type sent from the
network to the user-side layer management entity during the TEI
removal procedure. This message is sent in a UI command frame.
The message includes a reference number that is always 0, because
it is not responding to a request from the local router. It is sent twice
by the network to prevent a lost message.
IDCKRP Indicates the Identity Check Response message type sent from
the local router to the ISDN service provider on the network during
the TEI check procedure. This message is sent in a UI command
frame in response to the IDCKRQ message
IDREQ This indicates an Identity Request message sent from the local
router to the network during the automatic TEI assignment.
UAf This confirms that the network side has accepted the SABME command
previously sent by the local router. The final bit is set to 1.
INFOc This is an information command. It is used to transfer sequentially

numbered frames containing Information Fields cap provided

by layer 3.
IDASSN This indicates an Identity Assigned message type sent from the
network s ISDN service provider to the local router during the
automatic TEI assignment procedure.
RRx This indicates Receive Ready. If x = r, it is responding to an
INFOc. If x = p, the router is polling the network side. And x = f
means the network side has responded to the poll and the final
bit is set.
Now what does everything in Table 26.7 mean? According to the output, the router
attempts
to establish a connection with the switch, using legacy TEI information that it
has left over:
ISDN BR0: TX -> SABMEp sapi = 0 tei = 77
The service provider s switch disapproves of this and orders a check of the router s
current TEIs
with the IDCKRQ message. The ai of 127 (broadcast) simply tells the router that
the switch
would like for it to check all TEIs it currently has registered:
ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127
The router promptly returns an IDCKRP message for each TEI it finds within itsel
f. In this case,
these are 77 and 78:
ISDN BR0: TX -> IDCKRP ri = 44602 ai = 77
ISDN BR0: TX -> IDCKRP ri = 37339 ai = 78
The switch does not want the router to continue using these TEIs, so it issues a
n IDREM message
for each offending TEI. This tells the router to forget about these TEIs:
ISDN BR0: RX <- IDREM ri = 0 ai = 77
The router quickly throws itself at the mercy of the switch by sending the IDREQ
message with
an ai of 127. Notice that the router is looking for two TEIs, one for each logic
al B channel interface
within BRI0, but it has to issue four IDREQs to overcome the timeouts:
ISDN BR0: TX -> IDREQ ri = 43085 ai = 127
ISDN BR0: TX -> IDREQ ri = 11550 ai = 127
As soon as an IDASSN returns that matches the ri of one of the IDREQs, as follow
s:
ISDN BR0: RX <- IDASSN ri = 11550 ai = 79
the router turns around and establishes service with a new SABME message, using
the new TEI:
ISDN BR0: TX -> SABMEp sapi = 0 tei = 79
ISDN BR0: TX -> IDREQ ri = 65279 ai = 127
Because the switch obviously approves of this TEI, it responds with the UA messa
ge the router
was originally looking for.
ISDN BR0: RX <- UAf sapi = 0 tei = 79
After the UAs come in, the whole INFO/RR exchange for layer 3 information begins
for each
TEI assigned:
ISDN BR0: TX -> INFOc sapi = 0 tei = 79 ns = 0 nr = 0 i =
?0x08007B3A0A30383335383636313031
ISDN BR0: TX -> RRr sapi = 0 tei = 79 nr = 1
This occurs for both the 79 and 80 TEIs.
Layer 2 Negotiation
================

You need to have an understanding of the LAPD frame before you understand how la
yer 2
negotiates. This will help you identify where a potential or existing problem is
occurring. One
useful feature of Cisco equipment is that it includes good diagnostic tools for
finding ISDN
problems. Knowing which side of the ISDN connection does what will help you iden
tify a problem
and start corrective action.
The first part of the process is TEI assignment, which is accomplished by using
this process:
1. The terminal endpoint (TE) and the network initially exchange Receive Ready (
RR) frames,
listening for an initiated connection.
2. The TE sends an Unnumbered Information (UI) frame with a SAPI of 63 (manageme
nt procedure,
query network) and TEI of 127 (broadcast).
3. The network assigns an available TEI (in the range 64 126).
4. The TE sends a Set Asynchronous Balanced Mode Extended (SABME) frame with a S
API
of 0 (call control, used to initiate a SETUP) and a TEI of the value assigned by
the network.
5. The network responds with an Unnumbered Acknowledgment (UA); SAPI = 0, TEI =
assigned.
As you examine this partial output from the command debug isdn q921, please refe
r to
Table 26.7, which explains the meaning of the output.
ISDN
ISDN
ISDN
ISDN
ISDN
ISDN
ISDN

BR0:
BR0:
BR0:
BR0:
BR0:
BR0:
BR0:

TX
RX
TX
TX
RX
TX
RX

->
<->
->
<->
<-

SABMEp sapi = 0 tei = 77

IDCKRQ ri = 0 ai = 127
IDCKRP ri = 44602 ai = 77
IDCKRP ri = 37339 ai = 78
IDREM ri = 0 ai = 77
IDREQ ri = 44940 ai = 127
IDREM ri = 0 ai = 78

ISDN BR0: TX -> IDREQ ri = 43085 ai = 127

ISDN BR0: TX -> IDREQ ri = 11550 ai = 127
ISDN BR0: RX <- IDASSN ri = 11550 ai = 79
ISDN BR0: TX -> SABMEp sapi = 0 tei = 79
ISDN BR0: TX -> IDREQ ri = 65279 ai = 127
ISDN BR0: RX <- UAf sapi = 0 tei = 79
ISDN BR0: TX -> INFOc sapi = 0 tei = 79 ns =
?nr = 0 i = 0x08007B3A0A30383335383636313031
ISDN BR0: RX <- IDASSN ri = 65279 ai = 80
ISDN BR0: TX -> SABMEp sapi = 0 tei = 80
ISDN BR0: RX <- INFOc sapi = 0 tei = 79 ns =
?0x08007B3B028181
ISDN BR0: TX -> RRr sapi = 0 tei = 79 nr = 1
ISDN BR0: RX <- UAf sapi = 0 tei = 80
ISDN BR0: TX -> INFOc sapi = 0 tei = 80 ns =
nr = 0 i = 0x08007B3A0A30383335383636333031
ISDN BR0: RX <- INFOc sapi = 0 tei = 80 ns =
?0x08007B3B028381
ISDN BR0: TX -> RRr sapi = 0 tei = 80 nr = 1

0 nr = 1 i =

0 _
0 nr = 1 i =