[cisco-voip] Checking hardware -- PRI

Peter Slow peter.slow at gmail.com
Mon Feb 15 11:52:17 EST 2010 

it makes sense. the controller counters are at layer 1. your issue
appears to be at layer 2. it looks liek your telco stopped talking to
you. You need to ask them why, unless there's a bug in IOS that causes
it to eat SABMEs, which is doubtful. it appears your telco stopped
sending SABME frames. IOS waited 30 seconds and then asked your
telco's switch if it was still alive, and it did not respond.

-peter


On Mon, Feb 15, 2010 at 11:48 AM, Scott Voll <svoll.voip at gmail.com> wrote:
> no.  that's the part that has me confused.
> maybe a bug with the sh controller command?
> I have no errors until I get to last 24 hours.  nothing in the first 96
> intervals.
> I'll look for a bug with 12.4.24t1.
> Scott
>
>
> On Mon, Feb 15, 2010 at 8:45 AM, Peter Slow <peter.slow at gmail.com> wrote:
>>
>> im pretty sure that's telling you that your telco is being stupid. are
>> there any unavailable seconds on the controller for the interval in
>> which the timeframe "Feb 15 16:38:32.747 until  Feb 15 16:39:02.747"
>> lies?
>>
>> -Peter
>>
>> On Mon, Feb 15, 2010 at 11:41 AM, Scott Voll <svoll.voip at gmail.com> wrote:
>> > so what does this tell me?
>> > Feb 15 16:37:40.619: ISDN Se0/3/0:23 Q921: L2_EstablishDataLink: sending
>> > SABME
>> > Feb 15 16:37:40.619: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:37:41.619: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:37:42.619: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:37:43.619: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:37:49.699: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:37:49.699: ISDN Se0/3/0:23 Q921: S4_SABME: Sending UA
>> > Feb 15 16:37:49.699: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0/3/0:23,
>> > TEI
>> > 0 changed to up
>> > Feb 15 16:37:49.699: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:37:50.683: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:37:50.687: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:37:51.683: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:37:51.687: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:37:52.683: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:37:52.687: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:37:59.707: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:37:59.711: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:38:00.703: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:38:00.707: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:38:01.703: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:38:01.707: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:38:02.703: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:38:02.707: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:38:09.719: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:38:09.719: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:38:10.703: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:38:10.707: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:38:11.703: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:38:11.707: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:38:12.703: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:38:12.707: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:38:19.727: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:38:19.731: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:38:20.723: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:38:20.727: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:38:21.723: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:38:21.727: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:38:22.723: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:38:22.727: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:38:29.751: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:38:29.751: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:38:30.743: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:38:30.747: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:38:31.743: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:38:31.747: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:38:32.743: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:38:32.747: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0
>> > Feb 15 16:39:02.747: ISDN Se0/3/0:23 Q921: User TX -> RRp sapi=0 tei=0
>> > nr=0
>> > Feb 15 16:39:03.747: ISDN Se0/3/0:23 Q921: User TX -> RRp sapi=0 tei=0
>> > nr=0
>> > Feb 15 16:39:04.747: ISDN Se0/3/0:23 Q921: User TX -> RRp sapi=0 tei=0
>> > nr=0
>> > Feb 15 16:39:05.747: ISDN Se0/3/0:23 Q921: User TX -> RRp sapi=0 tei=0
>> > nr=0
>> > Feb 15 16:39:06.747: ISDN Se0/3/0:23 Q921: L2_EstablishDataLink: sending
>> > SABME
>> > Feb 15 16:39:06.747: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:07.747: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:08.747: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:09.747: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:10.747: %ISDN-6-LAYER2DOWN: Layer 2 for Interface
>> > Se0/3/0:23,
>> > TEI 0 changed to down
>> > Feb 15 16:39:10.755: ISDN Se0/3/0:23 Q921: L2_EstablishDataLink: sending
>> > SABME
>> > Feb 15 16:39:10.755: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:11.755: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:12.755: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:13.755: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:20.759: ISDN Se0/3/0:23 Q921: L2_EstablishDataLink: sending
>> > SABME
>> > Feb 15 16:39:20.759: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:21.759: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:22.759: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:23.759: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:30.779: ISDN Se0/3/0:23 Q921: L2_EstablishDataLink: sending
>> > SABME
>> > Feb 15 16:39:30.779: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:31.779: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:32.779: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:33.779: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:40.799: ISDN Se0/3/0:23 Q921: L2_EstablishDataLink: sending
>> > SABME
>> > Feb 15 16:39:40.799: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:41.799: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:42.799: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:43.799: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:50.819: ISDN Se0/3/0:23 Q921: L2_EstablishDataLink: sending
>> > SABME
>> > Feb 15 16:39:50.819: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:51.819: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0u
>> > Feb 15 16:39:52.819: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0
>> > Feb 15 16:39:53.819: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0
>> > tei=0n
>> > all
>> > Scott
>> > On Mon, Feb 15, 2010 at 8:38 AM, Peter Slow <peter.slow at gmail.com>
>> > wrote:
>> >>
>> >> ideally, we want all of those debugs starting abotu two minutes prior
>> >> to the failure. also... debug isdn q921 probably wouldnt hurt either.
>> >>
>> >> -Peter
>> >>
>> >> On Mon, Feb 15, 2010 at 11:36 AM, Peter Slow <peter.slow at gmail.com>
>> >> wrote:
>> >> > there are definitely going to be things going on with MGCP when this
>> >> > is happening.... We need to see what's going on what that in relation
>> >> > to the point at which the 921/931 states change. Is it possible for
>> >> > us
>> >> > to get the debugs leading up to and including one of the events?
>> >> >
>> >> > -Pete
>> >> >
>> >> > On Mon, Feb 15, 2010 at 11:33 AM, Scott Voll <svoll.voip at gmail.com>
>> >> > wrote:
>> >> >> mgcp packets are following back and forth.
>> >> >> isdn: Feb 15 16:31:19.360: %ISDN-6-LAYER2DOWN: Layer 2 for Interface
>> >> >> Se0/3/0:23, TEI 0 changed to down
>> >> >> Feb 15 16:31:48.852: %ISDN-6-LAYER2UP: Layer 2 for Interface
>> >> >> Se0/3/0:23, TEI
>> >> >> 0 changed to up
>> >> >> not seeing any ccm manager events.  should I?
>> >> >> Scott
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Mon, Feb 15, 2010 at 8:25 AM, Peter Slow <peter.slow at gmail.com>
>> >> >> wrote:
>> >> >>>
>> >> >>> Errrr.... Also I sort of jumped the gun....
>> >> >>>
>> >> >>> > I have shut not shut the interface but I continue to get RTMT
>> >> >>> > reports
>> >> >>> > that the D channel is down(every 1 - 3 minutes).  Router has been
>> >> >>> > up
>> >> >>> > for
>> >> >>> > multiple days.(had a power outage last week). but d channel went
>> >> >>> > down
>> >> >>> > yesterday afternoon.
>> >> >>>
>> >> >>> ...This can mean a TON of things... You're goign to see this alert
>> >> >>> if
>> >> >>> your GW ungesisters from your CCM. That could easily be due to a
>> >> >>> network issue. Its entirely possible that your interface is
>> >> >>> bouncing
>> >> >>> at one layer or another when it unregisters or re-registers with
>> >> >>> your
>> >> >>> CCM, that could explain your controller errors. We need to see
>> >> >>> what's
>> >> >>> happening first. Is the GW losing registration with the CCM for a
>> >> >>> network or software-related reason, or is the actual T1 interface
>> >> >>> bouncing, or is there a different issues thats just causing a
>> >> >>> problem
>> >> >>> with the q.931 signaling.
>> >> >>>
>> >> >>> we need:
>> >> >>> debug mgcp packet
>> >> >>> debug isdn q931
>> >> >>> debug ccm-manager backhaul events
>> >> >>> debug ccm-manager config-download all
>> >> >>>
>> >> >>> ...and anythign that appears in syslog, such as interface protocol
>> >> >>> state changes (int x is up down etc)
>> >> >>>
>> >> >>> ...begging before and ending after the occurrence of one of the
>> >> >>> D-Channel OOS events.
>> >> >>>
>> >> >>> -Peter
>> >> >>>
>> >> >>> On Mon, Feb 15, 2010 at 11:17 AM, Peter Slow <peter.slow at gmail.com>
>> >> >>> wrote:
>> >> >>> > I recommend doing one of two things:
>> >> >>> >
>> >> >>> > if you have hardware to accommodate a second PRI, wire it up to
>> >> >>> > this
>> >> >>> > one and set them up back to back, and we'll see if the issue
>> >> >>> > continues, and if you keep getting errors or not.
>> >> >>> >
>> >> >>> > If you can't go with option 1, you need to slap a loopback into
>> >> >>> > that
>> >> >>> > bad boy and set it up as an HDLC encapsulated data T1 and we can
>> >> >>> > send
>> >> >>> > packets of various sizes over it to see if you get any errors
>> >> >>> > that
>> >> >>> > way.
>> >> >>> >
>> >> >>> > Pick one, and we'll go through the specifics =)
>> >> >>> >
>> >> >>> > -Peter
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > On Mon, Feb 15, 2010 at 11:10 AM, Scott Voll
>> >> >>> > <svoll.voip at gmail.com>
>> >> >>> > wrote:
>> >> >>> >> show isdn stat shows multiple frames established which makes me
>> >> >>> >> still
>> >> >>> >> think
>> >> >>> >> it's a Telco issue.  any other ideas?
>> >> >>> >> Scott
>> >> >>> >> ps. I have no mgcp -- mgcp.
>> >> >>> >>
>> >> >>> >> On Mon, Feb 15, 2010 at 7:53 AM, Scott Voll
>> >> >>> >> <svoll.voip at gmail.com>
>> >> >>> >> wrote:
>> >> >>> >>>
>> >> >>> >>> I have a ticket in with the local telco, but I have a D channel
>> >> >>> >>> on
>> >> >>> >>> my
>> >> >>> >>> PRI
>> >> >>> >>> that is bouncing about every 1-3 minutes.
>> >> >>> >>> How do I check to make sure it's not a hardware issue on my
>> >> >>> >>> side?
>> >> >>> >>> it's a 2851 with vwic-2mft-t1=
>> >> >>> >>> I see on the controller in the last 24 hours it has 1610 path
>> >> >>> >>> code
>> >> >>> >>> violations, 9 line code violoations, 2 serverly err secs, and 6
>> >> >>> >>> unavail
>> >> >>> >>> secs. but nothing in the current interval.
>> >> >>> >>> I have shut not shut the interface but I continue to get RTMT
>> >> >>> >>> reports
>> >> >>> >>> that
>> >> >>> >>> the D channel is down(every 1 - 3 minutes).  Router has been up
>> >> >>> >>> for
>> >> >>> >>> multiple
>> >> >>> >>> days.(had a power outage last week). but d channel went down
>> >> >>> >>> yesterday
>> >> >>> >>> afternoon.
>> >> >>> >>> What else should I be looking at.
>> >> >>> >>> Thanks
>> >> >>> >>> Scott
>> >> >>> >>> ps. CM 6.1.3 and MGCP.
>> >> >>> >>
>> >> >>> >> _______________________________________________
>> >> >>> >> cisco-voip mailing list
>> >> >>> >> cisco-voip at puck.nether.net
>> >> >>> >> https://puck.nether.net/mailman/listinfo/cisco-voip
>> >> >>> >>
>> >> >>> >>
>> >> >>> >
>> >> >>
>> >> >>
>> >> >
>> >
>> >
>
>

More information about the cisco-voip mailing list