Do you have the flow control enabled?
Flow control is set by the pppd option crtscts for RTS/CTS and xonxoff for XON/XOFF. If you don't enable the flow control then you will probably overrun the modem\s buffers and this will prove to be disastrous with vj header compression.
It is important that the modem, not just the computer, have the proper setting for flow control. If the modem does not do flow control and the computer is expecting that the modem will tell it when the buffer overruns, then the buffer will overrun because the modem is not configured to tell the computer that it is full.
Likewise if the modem is configured to use RTS/CTS and your computer is configured to use XON/XOFF then you will not be able to recognize the modem\s request to suspend transmission.
The modern modems are configured with the use of a command code to do flow control. Check in your manual for the appropriate command code and include it along with the modem initialization.
Do not fall into the "well, the modem does this by default so I don't have to configure the modem before I use it." trap. Do the configuration. Do it explicitly. If the manual says that &H1 sets RTS and CTS flow control (what is also commonly called \hardware\ flow control) then send the modem AT&H1 to set the flow control. Do it before you dial the number. Don't expect that just giving the modem ATZ will enable the flow control properly.
The better flow control is CTS/RTS. However, if you can not do the hardware flow control with the signals CTS and RTS, then use XON/XOFF. The following three steps need to be performed.
Put the desired rate as an option to the pppd process. If you don't put the rate, then pppd process will use whatever rate is set currently at the time. Not all programs will restore all of the parameters to the previous settings properly upon exit. This may lead to strange rates configured for the serial device.
Linux does not support modems which use the RPI (Rockwell Protocol Interface) proprietary specification. Given the proprietary nature of the specification (even if you signed a NDA Rockwell will not release the code needed to interface to the modem) it is extremely unlikely that Linux will ever support this modem. The only solution, should you have a RPI modem, is to take it back to the dealer and get one which does not use RPI.
Some of the catch phrases to avoid are modems which are marked as having error correction in software, \windows\ compatible, or \requiring a special driver\ for full operation. These usually indicate that the modem uses RPI.
Did you specify the option:
asyncmap 0
when you ran pppd? If you forgot the option, the peer must quote (double) all of the control characters in the range from 00 to 1F (hex). This will result in a statistical loss of about 12.5% in speed for all of the data which you receive.
Did you configure the remote system? If so, did you forget flow control on its modem?
Use the ppp-2.1.2d.tar.gz package. The pppd process was erroneously compiled with the 1.1.8 kernel and it used Net-3 rather than Net-2 definitions.
Additionally, you should refer to the proxy-ARP mini-HOWTO about the requirements for using proxy-ARP.
The 2.1 package had a limit of 64 network devices. At the the that the proxyarp function was written, 64 seemed to be a very likely limit as most people had one or two ethernet controllers. This is no longer the case when we consider that some systems routinely have 128 network devices.
The 2.2 package has raised the limit to 5000 network devices. That limit is excessive. However, it means that in all practial purposes, there is no limit. It is a compile-time define in the sys-linux.c module.