Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(ASCEND) Undeliverable Message
To: <ascend-users-digest@max.bungi.com>
Cc:
Subject: ascend-users-digest V96 #633
Message not delivered to recipients below. Press F1 for help with VNM
error codes.
VNM3036: Samuel Chiu@Support@DAHK-HKG
VNM3036 -- RETRY PERIOD EXPIRED
If a user sends a message with an undeliverable
address, Mail keeps trying to deliver the
message for a time period specified by the message
expiration time. If the message cannot be
delivered within that period, the sender receives
a notice of undeliverable mail with this error code.
Check the address on the message, and make any
necessary corrections. If the address appears to
be correct, verify that the connections to the
recipient's mail service are working properly and
that the recipient's group still exists.
---------------------- Original Message Follows ----------------------
ascend-users-digest Friday, 23 May 1997 Volume 96 : Number 633
In this issue:
Re: (ASCEND) 56k and CT1
Re: (ASCEND) Cannot get 5.0A to work
Re: (ASCEND) Newbie Radius Question.
(ASCEND) K56flex NOT reporting user's receive speed in RADIUS
Re: (ASCEND) Analog Multilink PPP and RAS
Digital Padding at the Switch, was RE: (ASCEND) 56k and CT1
Re[2]: (ASCEND) Cannot get 5.0A to work
Re: (ASCEND) Analog Multilink PPP and RAS
(ASCEND) thank you, Ascend
Re: (ASCEND) K56flex NOT reporting user's receive speed in RADIUS
Re: (ASCEND) Analog Multilink PPP
Re: (ASCEND) Analog Multilink PPP
Re: (ASCEND) PPP over Clear Channel T-1 into Max 4000?
Re: (ASCEND) AMPPP>Why same modem?
(ASCEND) 5.0Ap9 only for MAX2000/BRI
Re: (ASCEND) 5.0Ap9 only for MAX2000/BRI
(ASCEND) CT1 Not Answering Call
Re: (ASCEND) CT1 Not Answering Call
Re: (ASCEND) K56flex NOT reporting user's receive speed in RADIUS
----------------------------------------------------------------------
From: Dale Botkin <dbotkin@probe.net>
Date: Fri, 23 May 1997 15:33:49 -0500 (CDT)
Subject: Re: (ASCEND) 56k and CT1
On Fri, 23 May 1997, Darkshot wrote:
> Watch this space. We have K56FLEX modems going in on Trunkside
> CT1's next week- our K56FLEXen on PRI are already working fine.
> Even with the marginal phone lines out here in the boonies.
Lucky SOB! 8-)
OK, Ascend, to what address do I need to send the hookers to get my 56K
upgrade cards shipped? And to whose attention?
Dale
- --------------------------------------------------------------
Dale Botkin, President | Voice: (402) 593-9800
Probe Technology Internet Services | FAX: (402) 593-8748
Omaha, NE | Email: dbotkin@probe.net
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: Kevin Smith <kevin@ascend.com>
Date: Fri, 23 May 1997 13:32:15 -0700
Subject: Re: (ASCEND) Cannot get 5.0A to work
At 11:51 AM 5/23/97 +0200, Pierre-Yves Kerembellec wrote:
>Le [Fri, 23 May 97 10:14:09 EET], Sakari Aaltonen ecrivait :
>
>> I have been connecting succesfully to a Max200+ - software
>> version 4.6C - using ISDN and callback.
>>
>> Now there is a new software version, 5.0A, that replaces
>> 4.6C. Well, neither p1, p3, p4, p5, nor p7 work.
>>
<snip>
>
>Hi !
>
>I already have an open ticket with Ascend support regarding this
>particular issue : this is a problem in Ascend software.
>
>My ticket # is 106492 ...
>This problem is reported as TR 2140
Just FYI, TR#2140 *seems* to be fixed in 5.0Ap8 -despite not being in the
release notes. I'll try to get more details on who tested it, but
may be worth a try...
Kevin Smith Updated Service and Support
Ascend Communications Resources are now at:
http://www.ascend.com/service
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: Kevin Smith <kevin@ascend.com>
Date: Fri, 23 May 1997 13:33:42 -0700
Subject: Re: (ASCEND) Newbie Radius Question.
At 08:39 AM 5/23/97 +0100, Adrian J Bool wrote:
>On Fri 23 May, Kevin Smith wrote:
>> At 05:58 PM 5/21/97 -0400, Craig Salmond wrote:
>> >Is it possible to have radius read the /etc/passwd (or /etc/shadow) file
>> >instead of the /etc/raddb/users file? Or alternatley a way to create the
>> >users file from the /etc/passwd file.
>>
>> Well if you just put the DEFAULT entry in the users file, it will go to
>> the UNIX password file via the "login" daemon (that's right isn't it?).
>
>... and "UNIX" as the password for that entry ?
Yes. I was *assuming* the same entry that is in all of the example user
files...
Kevin Smith Updated Service and Support
Ascend Communications Resources are now at:
http://www.ascend.com/service
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: Todd Vierling <tv@pobox.com>
Date: Fri, 23 May 1997 16:48:56 -0400 (EDT)
Subject: (ASCEND) K56flex NOT reporting user's receive speed in RADIUS
I've now confirmed the question I raised earlier, that 5.0Ap7 does *NOT*
report the connect rate the user sees (the K56flex rate) in RADIUS
accounting for the Ascend-Data-Rate parameter, but rather 31200 (our most
common transmit rate for K56flex) or 33600. Now, I'd consider this a TR,
but Ascend techs are telling me to raise it as a feature enhancement.
Show of hands: Who considers this a TR? Who considers this a FE?
=====
== Todd Vierling (Personal tv@pobox.com; Business tv@iag.net) Foo-bar-baz! ==
== System administrator/technician, Internet Access Group, Orlando Florida ==
== Dialups in Orange, Volusia, Lake, Osceola counties - http://www.iag.net ==
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: David Lesher <wb8foz@nrk.com>
Date: Fri, 23 May 1997 17:08:01 -0400 (EDT)
Subject: Re: (ASCEND) Analog Multilink PPP and RAS
You just gained another reason to support analog MP.
The Maryland Hearing examiner has ruled in favor of
Bell Awful; by rejecting testimony to the contrary,
and adopting the PUC staff proposal.
- --
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: Dave Van Allen <dave@fast.net>
Date: Fri, 23 May 1997 18:16:33 -0400
Subject: Digital Padding at the Switch, was RE: (ASCEND) 56k and CT1
Just FYI -
On channelized T1's (not PRI), the digital-padding Kevin refereed to is
usually configurable at the Switch. While I don't have specifics for
Lucent/AT&T switches, on NorTel the following info may be handy.
When ordering lines (trunk side) from DMS provisioned services, specify
to the provider that you wish to have your trunks data-filled with NIL
PAD GROUP. This tells the DSP on the DMS switch to *not* alter the gain
or frequency response of the incoming DS0 channels. Most Telco's still
apply standard "pads" to data circuits incorrectly, mainly because of
not understanding the issues. (they use voice designed pads as a
default in many cases)
On a DMS switch, there are about 50 pad groups, the one you usually want
is "NPDGP" (NIL PAD GROUP)
In some cases, this change alone is worth 2 speed increases higher in
connect rates, and far less "phantom" discos for end users.
You mileage will vary and there are a few reasons why this is NOT
absolute advise for all instances, but it is a pointer for those who are
experiencing troubles.
Best regards,
Dave Van Allen - You Tools Corporation/FASTNET(tm)
dave@fast.net (610)289-1100 http://www.fast.net
FASTNET - PA/NJ/DE Business Internet Solutions
>-----Original Message-----
>From: Kevin Smith [SMTP:kevin@ascend.com]
>Sent: Thursday, May 22, 1997 9:21 PM
>To: Matt Holdrege
>Cc: ascend-users@bungi.com
>Subject: Re: (ASCEND) 56k and CT1
>
>At 05:58 PM 5/22/97 -0700, Matt Holdrege wrote:
>>At 08:15 PM 5/22/97 -0400, Matthew S. Dwyer wrote:
>>>
>>>Hello,
>>>
>>>We are planning to order a number of Series56 modems for evaluation
>>>on our CT1 circuits. Given that we have seen lower performance on CT1
>>>compared to PRI with 28.8k, what sort of performance should we
>>>expect with 56k? Can these modems adjust for the bandwidth limitations
>>>per channel on CT1? (200-3800hz)
>>
>>With channelized T1, you must have the telco provision trunk-side rather
>>than line-side to get the higher speeds. It's theoretically possible to get
>>56K on a trunk-side T1, but in practice that may be iffy.
>
>According to USR/Rockwell:
>
>As far as T1 lines are concerned, both Rockwell and USR claim to have
>been able to avoid signal loss in T1 lines by detecting what they call
>"digital-padding" in T1 switch. This digital pad can cause the modem signal
>to drop as much as 6db. Once they detect this digital pad during the first
>stage of negotiation, they boost their transmit level by 6db. They also have
>algorithm to compensate for robbed-bit signaling.
>
>Kevin Smith Updated Service and Support
>Ascend Communications Resources are now at:
> http://www.ascend.com/service
>++ Ascend Users Mailing List ++
>To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
>To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
>or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: Pierre-Yves Kerembellec <Pierre-Yves.Kerembellec@vtcom.fr>
Date: Sat, 24 May 1997 00:25:55 +0200
Subject: Re[2]: (ASCEND) Cannot get 5.0A to work
Le [Fri, 23 May 1997 13:32:15 -0700], Kevin Smith ecrivait :
> >Hi !
> >
> >I already have an open ticket with Ascend support regarding this
> >particular issue : this is a problem in Ascend software.
> >My ticket # is 106492 ...
> >This problem is reported as TR 2140
> Just FYI, TR#2140 *seems* to be fixed in 5.0Ap8 -despite not being in the
> release notes. I'll try to get more details on who tested it, but
> may be worth a try...
Unfortunatly, I tested p8 and not succeed in 'callbacking' my Cisco
And MAX4000 software was _NOT_ released in p9 ... still waiting for p10 ... :-)
Regards,
Pierre-Yves
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pierre-Yves KEREMBELLEC Phone # +33 1 46 12 67 50
VTCOM Fax # +33 1 46 12 67 00
40, rue Gabriel Crie E-mail pyk@vtcom.fr
92245 Malakoff Cedex, France Systemes et Reseaux
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: cclemmer@baynetworks.com (Charlie Clemmer)
Date: Fri, 23 May 1997 18:17:12 -0500
Subject: Re: (ASCEND) Analog Multilink PPP and RAS
At 11:59 AM 5/23/97 -0700, Kevin Smith wrote...
>>We support combinations with different link types, either async or sync.
>
>Interesting....just Bay/Bay, or have you done this with other Vendors?
>
>p.s. do you guys have a user-mailing-list too ?
See John Carlson's notes on the same subject. I don't believe it to be just
Bay/Bay.
We don't have a mailing list, at least that I'm aware of, but there is an
internet newsgroup, comp.dcom.sys.wellfleet.
Charlie Clemmer
Bay Networks
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: Josh Bailey <josh@actrix.gen.nz>
Date: Sat, 24 May 1997 11:31:45 +1200 (NZST)
Subject: (ASCEND) thank you, Ascend
Hey all,
In the past you've seen some pretty vocal messages from me.
In response, our distributer got an Ascend engineer over here to examine
our issues first-hand.
We were able to demonstrate our performance problems to him - the only
change he suggested we make to our configuration was to tweak a PPP
parameter by one second to help an occasional PAP problem. He commented
that our installation was very well set up and managed (we have more than
50 M4000E's spread nationally and maintained via some in-house developed
software using Ascend's Machine Interface Format).
Thank you Ascend for acknowledging our very genuine issues and getting on
to them to sort them out, and thanks to Asnet NZ for responding to our
needs so efficiently.
One comparitively small gripe - it's a shame we had to push so hard to get
some of these issues acknowledged - and we've lost customers tired of
hearing that magic initialisation strings will fix everything.
Ascend, you're making the right support moves now, but next time PLEASE
may we have some assistance a little faster.
- --
Josh Bailey (mailto:joshb@xtra.co.nz)
Internet Network Specialist Voice (DDI): +64-9-355-5923
Telecom Internet Services Voice (Mob): +64-25-514-899
Extension: 93423 Fax: +64-9-355-5924
PO Box 92028, Auckland, NZ Pager: +64-26-114-448
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: James Fischer <jfischer@supercollider.com>
Date: Fri, 23 May 1997 19:45:11 +0000
Subject: Re: (ASCEND) K56flex NOT reporting user's receive speed in RADIUS
Todd Vierling claimed:
>I've now confirmed the question I raised earlier, that 5.0Ap7 does *NOT*
>report the connect rate the user sees (the K56flex rate) in RADIUS
>accounting for the Ascend-Data-Rate parameter, but rather 31200 (our most
>common transmit rate for K56flex) or 33600. Now, I'd consider this a TR,
>but Ascend techs are telling me to raise it as a feature enhancement.
>
>Show of hands: Who considers this a TR? Who considers this a FE?
If (and only if) the description above is accurate,
it is a Hands Down Winner!! TR all the way!! :-)
Given the level of (understandable) confusion that WILL
exist in the mind of the users, I expect that there will
be many calls to our 800-number support staff asking:
"OK, I have a 56K modem, you say that you
support 56K, so why can't I get a 56K connection?"
Now, since these calls cost us money AND are damaging
to customer good-will, we need to be able to:
A) Be proactive (just like we could before 56K)
and run scans through the radius data to find
users who are not connecting at "decent speeds",
so that we can suggest that they contact their
telco about line quality BEFORE they call us
to complain.
B) Get accurate info from the Maxen on this issue,
just as we could before 56K.
Therefore, THIS IS A BUG, since the "upgrade" to 56K
should not "break" a fairly basic feature that has
been available from Ascend on all prior products.
It should be obvious even to the casual observer that
"connection speed" is going to once again be a hot
issue, just as it was when 28.8kbps was first rolled out.
It matters not what the throughput is, and you can talk
until you are blue in the face about "overall performance",
the bottom line is that the user/customer will expect
to connect "at 56K".
If an ISP was to charge "extra" for 56Kbps service, and
the user claimed that he was unable to connect at anything
above 33.6K, how would the matter be addressed, debugged,
and resolved without such features?
It looks like 56K is going to be "a pain" until this
bug is fixed (if the report above is accurate), since
Maxen simply will not know/tell what is going on.
Consciousness: that annoying time between naps
james fischer jfischer@supercollider.com
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: cclemmer@baynetworks.com (Charlie Clemmer)
Date: Fri, 23 May 1997 18:55:44 -0500
Subject: Re: (ASCEND) Analog Multilink PPP
Matt,
As Jeff pointed out, this thread is going to far off topic. The important
aspect this that async MP is support now in the "i" branch and will be
released in production code sometime soon.
I'll be glad to move this thread offline if that's more appropriate.
Charlie Clemmer
At 11:47 AM 5/23/97 -0700, Matt Holdrege wrote...
>If you read my email below, it says that we may not have checked the ED on
>analog calls. That can be called a bug if you are a purist, or just an
>unsupported feature of MP. But as I said below, we do support it in 5.0Aix.
>
>Code doesn't just fall out of the sky. Someone has to write the lines of
>code necessary to check incoming calls for ED and an MP header. Since
>Ascend code is so feature rich, we do all sorts of checking on inbound
>calls. We do far more than standards indicate and far more than other
>vendors support. This is because we are driven by our customers network
>design ideas. Our customers in the past have never asked us to support
>analog MP. Now they are asking for it and now we have added the code to
>check for MP and ED on types other than just ISDN data calls.
>
>
>At 01:35 PM 5/23/97 -0500, Charlie Clemmer wrote:
>>
>>Matt,
>>
>>What you describe is what I understood MP to be. The question that comes up
>>because of this then, is why would Livingston and maybe Ascend not support
>>MP over all types of links?
>>
>>I keep seeing mixed responses as to whether the Ascend box does support MP
>>over any kind of link, while I saw a response from a Livingston guy who
>>indicated that their box only supports MP on ISDN calls.
>>
>>Knowing that MP should not be related to the physical call type, why would
>>this limitation exist?
>>
>>Can we get a definitive answer from Ascend as to whether or not the Ascend
>>boxes share this limitation? Again, I would expect that it is supported,
>>for the reasons you mentioned.
>>
>>Charlie Clemmer
>>
>>At 08:41 AM 5/23/97 -0700, Matt Holdrege wrote:
>>>Folks, MP operates at a layer above the physical connection or media. You
>>>can combine any types of calls in any increment. I've seen NT call the Max
>>>with one analog call bundled with one ISDN call. Or two analog calls
>>>together. I've seen the Max call a Bay router with 23 channels of MP.
>>>
>>>All MP does is take (in one case) the endpoint discriminator and compare it
>>>with any other call it has, be it analog or MP or whatever. If there is a
>>>match, it bundles the two calls together. I haven't tested it on the Max
>>>5.0ap branch, but by the reports here I might assume that the Max code
>>>didn't check ED on analog calls. But the reports say that it does in the i
>>>branch.
>>
>>
>Matt Holdrege - http://www.ascend.com - matt@ascend.com
>++ Ascend Users Mailing List ++
>To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
>To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
>or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
>
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: cclemmer@baynetworks.com (Charlie Clemmer)
Date: Fri, 23 May 1997 19:06:33 -0500
Subject: Re: (ASCEND) Analog Multilink PPP
Jeff,
I have no problem splitting this into two threads. In fact, I'll be happy
to take this conversation offline if that's more appropriate. I'm not sure
how many people are following the dialer conversation vs. the other.
I still don't necessarily understand the comment regarding the inability to
use different vendors modems for an analog MP connection. The MP process is
the process that worries about sequencing and fragmentation/reassembly,
correct? So if one link in the bundle is slower for whatever reason,
shouldn't the MP process deal with this? If I'm missing something here,
please correct me.
Charlie Clemmer
At 12:34 PM 5/23/97 -0700, Jeff_Powell@ascend.com wrote...
>
>This thread has wandered, so I hope we can split it in two.
>
>When I said "I'm not aware of any other....blah blah, etc. etc." I was
>referring to PC based dialers [the title of the thread is "Analog Multilink
>PPP and RAS" after all. So let's divide this into two discussions:
>
>1. Asynch MPP [Specifically Windows based PC's dialing into an access
>router/server with more than one modem]
>2. All other MP/MPP types [UNIX machines, ISDN TA's/routers, router to
>router, etc. etc. etc.]
>
>Sound fair?
>
>Now, as to #1. Microsoft release multiline RAS in NT 4.0 [there's a patch
>for Win 95 as well, part of the ISDN connectivity kit]. Choosing "multiple
>lines" in the "modem properties" dialog in RAS [dial up networking] allows
>you to use two modems to dial into a RAS server.
>
>The AMPP specs don't care about what kind of modems, serial ports, etc.
>etc. that you have, but let's think it through for a minute. The hardest
>job an MP server has is to synch up the incoming calls. This is easy in
>the digital world, but in the analog world, it gets quite tricky. Ascend
>has had support for Analog MP in the MAX for awhile, but the only clients
>that could do it were UNIX machines and some remote access servers. When
>Microsoft came out with its offering, it didn't work with the Max.
>Basically there was too much slop on the client side of things and the Max
>couldn't compensate [a Pentium box running NT4.0 is still not a REAL
>workstation...]. Since this was a new offering from Microsoft, the
>reworking of MP code in the Max to make it more aggressive [and lenient at
>the same time...] in synching up the calls was put in an "i" release so it
>could get beat up in the real world before going prime-time.
>
>As to the client side, the closer in functionality the serial ports and the
>modems are, the better it works. The phone lines are not as important.
>I've tested this with one "normal" POTS line and one going through a POTS
>jack on a P25. On the line going through the P25, I would get 33.6k and on
>the POTS line I would get 31.2k and the lines synched up just fine. The
>key was that I used a third party 115k serial board [as Com2 and 3] and two
>Courier V.Everything modems [same firmware, etc.]. Any attempts to get a
>session with two different modems or different serial ports failed.
>
>Reports from the field have been positive so far, both in the support for
>Multiline RAS and that other aspects of MP didn't break, so we'll probably
>see this in 5.1xxxx.
>
>Anyway, I hope that clears that up...
>
>
>
>
>
>cclemmer@baynetworks.com on 05/23/97 11:35:46 AM
>
>To: matt@ascend.com
>cc: Ascend-users@bungi.com (bcc: Jeff Powell/Ascend/US)
>Subject: Re: (ASCEND) Analog Multilink PPP and RAS
>
>
>
>
>
>Matt,
>What you describe is what I understood MP to be. The question that comes up
>because of this then, is why would Livingston and maybe Ascend not support
>MP over all types of links?
>I keep seeing mixed responses as to whether the Ascend box does support MP
>over any kind of link, while I saw a response from a Livingston guy who
>indicated that their box only supports MP on ISDN calls.
>Knowing that MP should not be related to the physical call type, why would
>this limitation exist?
>Can we get a definitive answer from Ascend as to whether or not the Ascend
>boxes share this limitation? Again, I would expect that it is supported,
>for the reasons you mentioned.
>Charlie Clemmer
>At 08:41 AM 5/23/97 -0700, Matt Holdrege wrote:
>>Folks, MP operates at a layer above the physical connection or media. You
>>can combine any types of calls in any increment. I've seen NT call the Max
>>with one analog call bundled with one ISDN call. Or two analog calls
>>together. I've seen the Max call a Bay router with 23 channels of MP.
>>
>>All MP does is take (in one case) the endpoint discriminator and compare
>it
>>with any other call it has, be it analog or MP or whatever. If there is a
>>match, it bundles the two calls together. I haven't tested it on the Max
>>5.0ap branch, but by the reports here I might assume that the Max code
>>didn't check ED on analog calls. But the reports say that it does in the i
>>branch.
>++ Ascend Users Mailing List ++
>To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
>To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
>or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
>
>
>
>
>
>
>
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: German Martinez <German.Martinez@globalone.net>
Date: Fri, 23 May 1997 19:21:15 -0500
Subject: Re: (ASCEND) PPP over Clear Channel T-1 into Max 4000?
Ascend wrote:
> Can this be done?
Yes, you can do it. You can run ppp over a clear channel. When we
connect here in Colombia cust going to Global IP backbone, if the cust
has Cisco Router we use HDLC (cisco) and when the cust has another
router
Regards
> ++ Ascend Users Mailing List ++
> To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
> To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
> or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
- -------------------------------------------------------------------
\_/
@ @
,-------------vvvV--<o o>--Vvvvv---------------------.
| V^V |
| German A. Martinez Ramirez |
| Network Engineer |
| German.Martinez@globalone.net |
| Phone +571-621-0177 |
| Fax +571-618-0712 |
| Mobile +573-232-3728 |
| |
| "Out of order there is a chaos and |
| out of chaos there is an order" |
`----------------------------------------------------'
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: Jeff_Powell@ascend.com
Date: Fri, 23 May 1997 17:32:22 -0700
Subject: Re: (ASCEND) AMPPP>Why same modem?
Ah, nothing like a change of subject!
As to "why the same modem" I think it is a peculiarity of NT. If the two
channels don't bond in a reasonably synchronous way, it doesn't work.
Since different modems will take different amounts of time to synch, it may
or may not work unless the modems are very, very similar. You're right, it
has nothing to do with AMPPP per se, I see it as an NT issue.
cclemmer @ BayNetworks.COM on 05/23/97 05:06:33 PM
To: Jeff Powell/Ascend/US
cc: Ascend-Users @ Bungi.Com
Subject: Re: (ASCEND) Analog Multilink PPP
Jeff,
I have no problem splitting this into two threads. In fact, I'll be happy
to take this conversation offline if that's more appropriate. I'm not sure
how many people are following the dialer conversation vs. the other.
I still don't necessarily understand the comment regarding the inability to
use different vendors modems for an analog MP connection. The MP process is
the process that worries about sequencing and fragmentation/reassembly,
correct? So if one link in the bundle is slower for whatever reason,
shouldn't the MP process deal with this? If I'm missing something here,
please correct me.
Charlie Clemmer
At 12:34 PM 5/23/97 -0700, Jeff_Powell@ascend.com wrote...
>
>This thread has wandered, so I hope we can split it in two.
>
>When I said "I'm not aware of any other....blah blah, etc. etc." I was
>referring to PC based dialers [the title of the thread is "Analog
Multilink
>PPP and RAS" after all. So let's divide this into two discussions:
>
>1. Asynch MPP [Specifically Windows based PC's dialing into an access
>router/server with more than one modem]
>2. All other MP/MPP types [UNIX machines, ISDN TA's/routers, router to
>router, etc. etc. etc.]
>
>Sound fair?
>
>Now, as to #1. Microsoft release multiline RAS in NT 4.0 [there's a patch
>for Win 95 as well, part of the ISDN connectivity kit]. Choosing
"multiple
>lines" in the "modem properties" dialog in RAS [dial up networking] allows
>you to use two modems to dial into a RAS server.
>
>The AMPP specs don't care about what kind of modems, serial ports, etc.
>etc. that you have, but let's think it through for a minute. The hardest
>job an MP server has is to synch up the incoming calls. This is easy in
>the digital world, but in the analog world, it gets quite tricky. Ascend
>has had support for Analog MP in the MAX for awhile, but the only clients
>that could do it were UNIX machines and some remote access servers. When
>Microsoft came out with its offering, it didn't work with the Max.
>Basically there was too much slop on the client side of things and the Max
>couldn't compensate [a Pentium box running NT4.0 is still not a REAL
>workstation...]. Since this was a new offering from Microsoft, the
>reworking of MP code in the Max to make it more aggressive [and lenient at
>the same time...] in synching up the calls was put in an "i" release so it
>could get beat up in the real world before going prime-time.
>
>As to the client side, the closer in functionality the serial ports and
the
>modems are, the better it works. The phone lines are not as important.
>I've tested this with one "normal" POTS line and one going through a POTS
>jack on a P25. On the line going through the P25, I would get 33.6k and
on
>the POTS line I would get 31.2k and the lines synched up just fine. The
>key was that I used a third party 115k serial board [as Com2 and 3] and
two
>Courier V.Everything modems [same firmware, etc.]. Any attempts to get a
>session with two different modems or different serial ports failed.
>
>Reports from the field have been positive so far, both in the support for
>Multiline RAS and that other aspects of MP didn't break, so we'll probably
>see this in 5.1xxxx.
>
>Anyway, I hope that clears that up...
>
>
>
>
>
>cclemmer@baynetworks.com on 05/23/97 11:35:46 AM
>
>To: matt@ascend.com
>cc: Ascend-users@bungi.com (bcc: Jeff Powell/Ascend/US)
>Subject: Re: (ASCEND) Analog Multilink PPP and RAS
>
>
>
>
>
>Matt,
>What you describe is what I understood MP to be. The question that comes
up
>because of this then, is why would Livingston and maybe Ascend not support
>MP over all types of links?
>I keep seeing mixed responses as to whether the Ascend box does support MP
>over any kind of link, while I saw a response from a Livingston guy who
>indicated that their box only supports MP on ISDN calls.
>Knowing that MP should not be related to the physical call type, why would
>this limitation exist?
>Can we get a definitive answer from Ascend as to whether or not the Ascend
>boxes share this limitation? Again, I would expect that it is supported,
>for the reasons you mentioned.
>Charlie Clemmer
>At 08:41 AM 5/23/97 -0700, Matt Holdrege wrote:
>>Folks, MP operates at a layer above the physical connection or media. You
>>can combine any types of calls in any increment. I've seen NT call the
Max
>>with one analog call bundled with one ISDN call. Or two analog calls
>>together. I've seen the Max call a Bay router with 23 channels of MP.
>>
>>All MP does is take (in one case) the endpoint discriminator and compare
>it
>>with any other call it has, be it analog or MP or whatever. If there is a
>>match, it bundles the two calls together. I haven't tested it on the Max
>>5.0ap branch, but by the reports here I might assume that the Max code
>>didn't check ED on analog calls. But the reports say that it does in the
i
>>branch.
>++ Ascend Users Mailing List ++
>To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
>To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
>or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
>
>
>
>
>
>
>
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: Kevin Smith <kevin@ascend.com>
Date: Fri, 23 May 1997 18:15:54 -0700
Subject: (ASCEND) 5.0Ap9 only for MAX2000/BRI
5.0Ap9 has been given to support. This release contains the following:
This release introduces the MAX 2000 T1 software load with BRI support.
- --Lew
Kevin Smith Updated Service and Support
Ascend Communications Resources are now at:
http://www.ascend.com/service
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: Kevin Smith <kevin@ascend.com>
Date: Fri, 23 May 1997 18:30:29 -0700
Subject: Re: (ASCEND) 5.0Ap9 only for MAX2000/BRI
At 06:15 PM 5/23/97 -0700, Kevin Smith wrote:
>5.0Ap9 has been given to support. This release contains the following:
>
>This release introduces the MAX 2000 T1 software load with BRI support.
Which all along I've been saying is not possible...I guess we decided it
was worth it...BRI slot cards are now supported in the MAX2000 along with
DM-12 and DM56-12 cards....
Kevin Smith Updated Service and Support
Ascend Communications Resources are now at:
http://www.ascend.com/service
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: Craig Salmond <salmond@unix.cde.com>
Date: Fri, 23 May 1997 20:40:41 -0400 (EDT)
Subject: (ASCEND) CT1 Not Answering Call
When I place a call to the Max, I get a "c" in the status window,
but no carrier tone. The phone company says it is a problem on my end, but
I have tried each of the Rob Ctl options... I do have each Channel Slot
set to 3 (which is the first modem card) and the call type as switched.
TIA
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Craig Salmond salmond@mail.cde.com
Craig's DATA Exchange! http://www.cde.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Shipping Address (FLA) 735-CDE1 Sales Billing Address
Craig's DATA Exchange! (FLA) 483-2482 Home Craig's DATA Exchange!
18826 U.S. HWY 441 (FLA) 735-9511 FAX P.O. Box 1401
Mt. Dora, FL 32757 (FLA) 735-INET DIAL-UP Mt. Dora, FL 32757
(FLA) 742-1515 Digital
"Lake County's Internet Authority"
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: Kevin Smith <kevin@ascend.com>
Date: Fri, 23 May 1997 19:12:04 -0700
Subject: Re: (ASCEND) CT1 Not Answering Call
At 08:40 PM 5/23/97 -0400, Craig Salmond wrote:
> When I place a call to the Max, I get a "c" in the status window,
>but no carrier tone. The phone company says it is a problem on my end, but
>I have tried each of the Rob Ctl options... I do have each Channel Slot
>set to 3 (which is the first modem card) and the call type as switched.
You don't say anything about how the T1 is provisioned....signaling
setup (wink/loops-start/ground)....answer supervision... ?
Kevin Smith Updated Service and Support
Ascend Communications Resources are now at:
http://www.ascend.com/service
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
From: Brantley Jones <bjones@cte.net>
Date: Fri, 23 May 1997 22:22:45 -0500
Subject: Re: (ASCEND) K56flex NOT reporting user's receive speed in RADIUS
At 07:45 PM 5/23/97 +0000, you wrote:
> Todd Vierling claimed:
>
>>I've now confirmed the question I raised earlier, that 5.0Ap7 does *NOT*
>>report the connect rate the user sees (the K56flex rate) in RADIUS
>>accounting for the Ascend-Data-Rate parameter, but rather 31200 (our most
>>common transmit rate for K56flex) or 33600. Now, I'd consider this a TR,
>>but Ascend techs are telling me to raise it as a feature enhancement.
>>
>>Show of hands: Who considers this a TR? Who considers this a FE?
Definitely a bug. How are we supposed to get an idea of how many of our
customers are actually GETTING better than 33.6 speeds????
This should be fixed immediately. It is definitely a BUG!
Brantley
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
------------------------------
End of ascend-users-digest V96 #633
***********************************
++ Ascend Users Mailing List Digest++
To unsubscribe:
"echo unsubscribe | mail ascend-users-digest-request@bungi.com"
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.shore.net/~dreaming/ascend-faq>
or <ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>