> We have resolved out problem with the help of a tech at Ascend. We turned
> off the link compression on the P50 and everything came together.
>
> Why can't Livingston support Stac Compression? This becomes a drag when
> clients want to use equipment such as Ascends which at least has
> compression options available.
They can and do in their new OR-U com os and they do in the PM 3 with the
Stac card. You MIGHT need to upgrade the P50 to 5.0 or higher, or an
ascend OS that supports REAL STAC and not their proprietary stac
comrpession they had in older os's.
> > At 08:36 AM 8/11/97 -0500, you
wrote: > >On Mon, 11 Aug 1997, Ben Gasser wrote:
> >
> >> Our client has a Novell Netware 3.12 server on there end with the Ascend
> >> P50 on an ethernet segment and another segment made up of token ring. The
> >> clients are using Internet Explorer 3.02. The clients IP segments are 28
> >> bit subnets of our class c. When a user pings a web page from the token
> >> side everything seems to be fine, but when they attempt to load a web page
> >> they tend to get time out errors.
> >
> >What do your syslogs say? Are you seeing any dns requests on the dns
> >server? Are their machines pointing to the right dns server? What if they
> >specify just ip address on the URL line? Do they still get the time outs?
> >
> >>
> >> This problem did not seem to crop up until we went from bridging a P50->P50
> >> to routing P50->5Bri.
> >>
> >>
> >> At 01:07 PM 8/5/97 -0400, you wrote:
> >> >Ben:
> >> >We do this all the time around here. As was stated before, the P50 will
> >> >automatically try the second number if the first is busy.
> >> >
> >> >There may be several reasons why your second call is not completing. Most
> >> >likely one or the other BRI is not configured properly. From the P50, try
> >> >the following. From System->Diag->Term Server,
> >> >do a
> >> >show isdn
> >> >
> >> >command. Make sure that you're not getting any invalid SPID messages.
> >> >Then try
> >> >
> >> >test xxxyyyy
> >> >
> >> >where "xxxyyyy" is the second telephone number on the P50. That should do
> >> >a line-to-line test call. If either of these tests doesn't complete
> >> >correctly, you've got a line/P50 configuration problem on the P50 end.
> >> >Make sure that the ISDN line is configured properly. We usually ask for
> >> >NI-1 with Circuit switched data on both B chanels.
> >> >
> >> >On the Livingston end, you really should have the lines set up as a hunt
> >> >group. We've had trouble where Bell has configured our lines as CSVD
> >> >(circuit switched voice + data) on the first B and CSD (circuit switched
> >> >data) on the second. On some switches, the combination of voice and
> data B
> >> >chanels don't hunt properly.
> >> >We've corrected that by asking for CSD on all B chanels.
> >> >
> >> >You can 'attach' to the first port and dial a v.120 isdn call to the
> second
> >> >port as shown below.
> >> >
> >> >attach s20
> >> >
> >> >atd xxxyyyy
> >> >
> >> >If you can't get a connection, neither will the remote p50.
> >> >
> >> >
> >> >It really sounds like there's an ISDN configuration problem on one or both
> >> >ends.
> >> >
> >> >Hope this helps,
> >> >
> >> >Bob
> >> >
> >> >> From: Ben Gasser <netwkhlp@gabs.net>
> >> >> To: portmaster-users@livingston.com
> >> >> Date: Sunday, August 03, 1997 1:46 PM
> >> >> Subject: Ascend P50 -> PM2
> >> >>
> >> >> >We have have a client who has an Ascend Pipeline 50 and is
> attempting to
> >> >> >connect into our PM2 with a 5 Bri card. Our problem is bonding both of
> >> >> the
> >> >> >B channels together, especially since the client will be dialing
> into out
> >> >> >PM2 using IP.
> >> >> >
> >> >> >The Pipeline 50 seems to make the call and attach to the first availble
> >> >> >channel, but the second channel attempts to dial in and attach to the
> >> >> same
> >> >> >port on the PM2 with no success, especially since the first call has
> >> >> >already used the port.
> >> >> >
> >> >> >Please help with any thoughts or ideas, especially if you have done
> this
> >> >> >successfully.
> >> >> >
> >> >> >
> >> >> >Ben Gasser, CNE
> >> >> >National Network Serivices, Inc.
> >> >> >Voice: 913.491.5388
> >> >> >Fax: 913.491.1529
> >> >> >
> >> >
> >> >Robert M. Zachok rmz@exit109.com
> >> >Atlantic Internet Technologies
> >> >628 Shrewsbury Ave., Red Bank, NJ 07701
> >> >908.758.0505, 908.758.0869 (FAX)
> >> >
> >> Ben Gasser, CNE
> >> National Network Services, Inc.
> >> bengasser@gabs.net
> >> (v) 913.491.5388
> >> (f) 913.491.1529
> >>
> >
> >~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
> > Jake Messinger 713-772-6690 jake@ams.com
> > Advanced Medical Systems, Inc. jake@uh.edu
> > 8300 Bissonnet #400
> > Houston, Texas 77074 http://www.ams.com/~jake
> >~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
> >
> >
> Ben Gasser, CNE
> National Network Services, Inc.
> bengasser@gabs.net
> (v) 913.491.5388
> (f) 913.491.1529
>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
Jake Messinger 713-772-6690 jake@ams.com
Advanced Medical Systems, Inc. jake@uh.edu
8300 Bissonnet #400
Houston, Texas 77074 http://www.ams.com/~jake
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~