After a little correspondence in private with a helpful and clueful 3Com employee (thank you), we've figured out the cause of the slow MLPPP we have been seeing with the HARC. It seems that the HARC does not fragment packets for MLPPP, it simply round-robins them out the interfaces. While this doesn't cause performance problems with sane protocols such as TCP, the software that our customer is using attempts to reinvent TCP over UDP. Badly. It sends one big packet, then waits for an ACK before sending the next one. The net result of this is that on a simple "ping" style test, a multilink bundle of any number of links won't show a significantly lower roundtrip time than a single link would. Also, I mentioned "mon ppp" showing traffic over only one interface on a multilink connection. This was confirmed as a "mon ppp" issue by 3Com. The "TAP USER" function shows traffic distributed across all interfaces. The "mon ppp" problem is slated to be fixed in upcoming releases, and there are plans to add a configurable parameter and/or RADIUS VSA to cause the HARC to fragment outgoing packets on multilink. As a temporary workaround until this code is available, we've found that lowering the link MTU for this particular customer alleviates the problem. It should be noted, however, that lowering MTUs may cause problems accessing certain sites that block all incoming ICMP. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.