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.
Technically, you're doing PPPoEoA.
The VC Mux part will have to be set on the modem, as that's the only thing that has access to the ATM layer. If you had a dsl interface in the router, you'd do:
blue-gw#show run int atm0.1
Building configuration...
Current configuration : 131 bytes
!
interface ATM0.1 point-to-point
bandwidth 6000
pvc dsl 8/35
encapsulation aal5mux ppp dialer
dialer pool-member 1
!
end
Other devices will vary.
Best Answer
The PPP header starts with a 16-bit protocol id. You need to look at that first in order to know how to interpret the rest.
If the protocol id is LCP/IPCP/IPv6CP then the header structure typically looks like this:
If the protocol id is IPv4 or IPv6 then the IP header comes immediately after the protocol id. Both IPv4 and IPv6 have a length field in their headers.
I'm not familiar with HDLC frames, but I assume you are receiving them from a socket. The socket read/receive function would provide you with the size of each incoming frame. So you can use that for validation purposes as well.