Oi...lemme dredge up those long-unused neurons to remember how Multilink PPP works.
During the LCP phase when the first link is brought up during a non-multilink PPP session, the two sides negotiate the MRU (Maximum Receive Unit) for each direction of the link...basically each side tells the other how big of a packet it can handle being sent to it.
With Multilink PPP, they negotiate that, but they also negotiate, when the first link is brought up, an MRRU, or Maximum Reconstructed Receive Unit.
Because Multilink PPP added extra frame header space, the creators were concerned about Path MTU problems, so they decided that Multilink would be able to fragment and reassemble packets on either end of the Multilink PPP session.
So, yes, unlike Ethernet bonding, its not just a matter of balancing frames across the multiple links...the frames can actually be fragmented and reassembled. This can cause a jump in latency and jitter.
On T-1's you should be able to configure each side with a significantly larger MRU and MRRU than any packets that would likely need to cross the link, and if the MRU is as large as, or larger than the MRRU, then you shouldn't see any fragmentation and reassembly occuring. Hopefully this will get the latency and jitter under control and help out your VoIP behavior. You will likely need to adjust this configuration on both sides of the links, though, as each direction is negotiated independently.
In general, I wouldn't expect VoIP packets to need to be fragmented, though...they tend to not be big enough to need that. Worth a shot to check your MRU and MRRU sizes on the links and the Multilink session, maybe they're way out of whack and causing problems.
I'd remove the Ericsson box. It isn't a BRAS. From your diagram it looks like you'd be using it as a aggregation switch and the Linux PPP Server would be your BRAS.
Personally, for lab purposes I'd also remove the Linux PPP Server and hook the DSLAM up to a Cisco 3825 or 7200 configured as a BRAS. If you really want the Linux element set up a FreeRADIUS server to do AAA for the PPP sessions.
Best Answer
CHAP is defined in RFC 1994.
You concatenate the identifier, the password (secret), and the challenge, in ASCII, in that order. The response is
hashMD5(identifier.secret.challenge), sent in binary (16 bytes for MD5).For your example, that should be in hex
0x017465737412345hashed.Note that MD5 is not cryptographically safe any more due to advances in processing power and methods. On an unsafe channel, you'll need to provide additional password protection (like SSL/TLS or VPN).