[cisco-voip] Checking hardware -- PRI

Mon Feb 15 11:51:17 EST 2010

yep CSCsx95959  controller command issues.

there are a couple it looks like

scott

On Mon, Feb 15, 2010 at 8: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
>> >> >>> >>
>> >> >>> >>
>> >> >>> >
>> >> >>
>> >> >>
>> >> >
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100215/9851e029/attachment.html>