[cisco-voip] Checking hardware -- PRI

[Scott Voll]

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/eccce0df/attachment.html>