[cisco-voip] Checking hardware -- PRI

Mon Feb 15 11:45:58 EST 2010

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
>> >>> >>
>> >>> >>
>> >>> >
>> >>
>> >>
>> >
>
>