[cisco-nas] X.75 (LAPB-TA) sessions getting "stuck"? (AS5300, 12.3)

[Gert Doering]

Hi,

On Fri, Oct 02, 2009 at 11:40:33AM -0700, Aaron Leonard wrote:
> > I have this AS5300 that is handling incoming X.75/LAPB-TA calls, and
> > every few weeks, it seems to get stuck in weird ways.
> 
> Well, since I was the one who talked you into using the 5300 for
> this, I suppose I bear some responsibility here.

Well, originally it was my idea :-) - but I had certainly hoped for your
help here.

[..]
> Compare and contrast what happens when things are working as desired,
> what what is happening when things are not.

Things look perfectly normal from the debug output - the call connects,
the first few bytes (encapsulated in X.75) are exchanged normally, and
then "something" stops in the chain

 data -> AS5300(X.75) -> AS5300(ISDN B-Channel) -> ISDN network -> caller

the "debug lapb-ta packets" claims that packets are X.75 encapsulated,
and the caller claims "nothing arriving here".  I have no means to 
figure out whether the X.75 layer in the AS5300 is not passing the
frames properly to the ISDN layer, or they get lost "somewhere in the
ISDN network".

... which might very well be, given that ISDN Data is something a number
of Telcos don't really support any longer...  "who wants this when you
can have DSL".


> - during that little 1-minute window where things are stuck, get:
> 
>   show line vty <n>    <= on the VTY used by the LAPB-TA session
>   show interface serial0:<n>  <= on the B channel used by the call
> 
>   compare how the vty and the serial interface look, with how they
>   look when things are working right

It's not actually a "1-minute window where things are stuck" - maybe that
was misleading from the log and from my description.  When they are stuck, 
they stay stuck - a reload was needed to bring it back to working.


But I'll definitely give "show line" and "show int" a very close look
when/if it happens next time.


> > If I reboot the box, everything is back to working.  "shut / no shut" on
> > the serial0:15 interface did *not* change anything.
> 
> I'm guessing that you've got some problem with a vty, but that's just
> a guess.  If so, then maybe you could do a "clear line" on the vty
> to get things unstuck.

The weird thing is, the effect persists across calls.

So for the next call, it will behave identically - it will connect,
exchange a few frames just fine, and then get stuck again.

What I did not test yet was to do multiple calls in parallel, to see
whether the effect only hits a specific vty or "all of them".  Thanks
for that idea.


> > This is currently running 12.3(26), which is the latest 12.3 release.
> > 
> > I'd bet willing to try an upgrade to 12.4, but this brings up the next
> > question - is the 5300 supported in 12.4?
> 
> Nope.  12.3 mainline is the last branch to support the 5300.

OK - so I'm not going to try this :)

> > The IOS files that can be
> > found on the FTP server in 12.4/12.4.25b/as5300/ are all named "as5350-...",
> > so I'm wondering whether they will work on the 5300 as well, or whether
> > this is incompatible, and the directory naming is just weird.
> 
> The 5350 is an entirely different system from the 5300, and neither's
> images will boot on the other.

Interesting artefact, to have 5350 IOS in the 5300 subdirectory, then :-)

> > (We could also downgrade to 12.2, if this is a new problem in 12.3...)
> 
> Yeah, if you just want to try different code versions, you could try
> (among stuff that's still on CCO):
> 
> 12.3(3i)
> 12.2(15)T7

Under normal circumstances, I'd try 12.2 "main line" next - but since 
you've recommended these two versions, what's special about them?  "Major
surgery between 12.3(3) and 12.3(4)"?

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nas/attachments/20091002/2bccf7ae/attachment.bin>