ppp multilink slippage in 12.2 mainline?

ppp multilink slippage issupposed to be in 12.2SB if you can use that stream

In article , snipped-for-privacy@rogers.com (Merv) writes: | | ppp multilink slippage issupposed to be in 12.2SB if you can use that | stream

Is 12.2SB is available for the 4700M?

I've tried suppressing fragmentation which has the interesting effect that lost fragments, discarded, and lost received increase (slowly) in lockstep as opposed to discarded jumping ahead. It also seems to avoid the problem (or at least make it too rare to see so far). The problem is that once the links get "out of sync" (for some meaning of "out of sync") the tcp connection that was causing the load stops making any progress until the second multilink link drops completely. Then the load works its way back up, a second link comes up, progress is made for a while until the discarded counter starts increasing wildly, the connection stalls, and the whole cycle repeats.

What are the exact meanings of the three counters: "lost fragments", "discarded", and "lost received"?

Dan Lanciani ddl@danlan.*com

nope

"discarded", and "lost received"?

good explanation of the detection of lost fragments in RFC 1717 section 4.1

In article , snipped-for-privacy@rogers.com (Merv) writes: | | > Is 12.2SB is available for the 4700M? | | nope

Yes, that would be too easy. :)

| > What are the exact meanings of the three counters: "lost fragments", "discarded", and "lost received"? | | good explanation of the detection of lost fragments in RFC 1717 | section 4.1

Do you know specifically how the conditions described map to Cisco's three counters? In particular, is "lost received" a packet count (as opposed to a fragment count) and does "lost fragments" include any fragments counted as "discarded"?

Dan Lanciani ddl@danlan.*com

"discarded", and "lost received"?

Perhaps it's time for a trip to ebay?

You don't say what kind of links you are using or what the error rates are but it might be possible to reduce the error rate on them. i.e get them fixed. I don't fully understand MLPPP but I have alwars had the idea that it was not really happy with links with an excesive error rate.

In article , snipped-for-privacy@hotmail.co.uk writes: | On 4 Sep, 05:01, ddl@danlan.*com (Dan Lanciani) wrote: | > In article , snipped-for-privacy@rogers.com (Merv) writes: | > | | > | > Is 12.2SB is available for the 4700M? | > | | > | nope | >

| > Yes, that would be too easy. :) | >

| > | > What are the exact meanings of the three counters: "lost fragments", "discarded", and "lost received"? | > | | > | good explanation of the detection of lost fragments in RFC 1717 | > | section 4.1 | >

| > Do you know specifically how the conditions described map to Cisco's | > three counters? In particular, is "lost received" a packet count (as | > opposed to a fragment count) and does "lost fragments" include any | > fragments counted as "discarded"? | | 4500M!

| Perhaps it's time for a trip to ebay?

Do you have a specific reason to think that a different router would behave differently? The 4700M is actually a nice, fast, flexible box. Getting & licensing something newer of comparable power would cost a fair bit. And I'd still need to know what the counters mean to figure out what is going on...

| You don't say what kind of links you are using | or what the error rates are but it might be | possible to reduce the error rate on them. i.e get them | fixed.

The error rate on the individual links is negligible. Over the course of any given test that demonstrates the problem the error rate is 0, i.e., there are no errors on the links at all. The problem is likely provoked by the different delay characteristics of the links. One is a direct synchronous connection via an ISDN terminal adapter while the other uses a similar ISDN connection on another router via a VPDN "accept dialout" server. Of course, the router receiving the calls sees them as identical dialins.

| I don't fully understand MLPPP but I have alwars had | the idea that it was not really happy with links with | an excesive error rate.

That isn't the issue here.

Dan Lanciani ddl@danlan.*com