The problem is the timeout on the PM3 interfaces. Since it appears ASCEND
is only transmitting on ONE channel, the timeout never gets reset, and the
line drops.
My understanding of MPP is that this is broken behavior; you WANT to
ping-pong between logical interfaces.
---- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 99 Analog numbers, 77 ISDN, http://www.mcs.net/ Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W InternalOn Wed, Apr 02, 1997 at 05:08:57PM -0800, Philip Thomas wrote: > Karl we just purchased 2 P-50s and I have just completed the setup of > both units. Like you we are dialing into the PM3 with the 2 channels, > but my question to you, our of curosity is: what encapsulation scheme > are you using & are you using ripv2 or v1? > > Phil > > Karl Denninger wrote: > > > > Hi folks, > > > > Dig this... > > > > Customer with a 2B account. Configured on an ASCEND P50 for > > "min channels = 2", "max channels = 2". > > > > Now, am I dense, or should this configuration: > > > > 1) Bring up both channels. > > 2) Ping-pong transmit packets between them so BOTH see traffic upbound. > > 3) Not run afoul of the idle timer on either channel (unless both go > > idle, in which case it hangs up both lines). > > > > It doesn't work. It *appears* that the upbound traffic only goes out ONE > > channel from the P50 to the network; the other appears to be idle! Since > > we have the PM3 idle timeout set to 20 minutes, and most traffic in an ISP > > environment to customers is DOWNBOUND, after 20 minutes channel #2 drops -- > > and then NEVER gets restored until the call is terminated and re-initiated > > by the customer! EVEN IF THE CUSTOMER PLASTERS THE FIRST CHANNEL, the > > Pipeline won't re-establish the second channel connection! > > > > ASCEND's answer to the customer? You have to use MP+ (their proprietary > > nonsense) or BACP to get the behavior you want. > > > > My response? That's BADLY braindead. Its TRIVIALLY SIMPLE to measure > > the throughput on a sync line, and bring up the second channel ON YOUR OWN > > when the threshold is reached WITHOUT the central-site hardware dialing > > you or using BACP-anything. > > > > Further, if I say NAIL BOTH CHANNELS I know damn well what I want, I meant > > what I said, and I want both channels USED all the time! > > > > I will note with some interest that the Farallon Netopia does the "right > > thing" and doesn't suffer from this. You can keep a 2B call up until > > hell freezes with that box and it won't drop a channel -- but it ping-pongs > > the data upbound (you can see it on the blinken-lights) so both channels see > > traffic. > > > > Anyone got ideas? Or is this just something that I have to tell the customer > > they should go beat their vendor about the ears until they fix it -- or > > perhaps the fix is to return the ASCEND and get a Farallon product that > > knows how to do this stuff correctly.... > > > > Talk about people not playing nice in an open systems environment..... > > > > -- > > -- > > Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity > > http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > > | 99 Analog numbers, 77 ISDN, http://www.mcs.net/ > > Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines! > > Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal