Multilink PPP

[jrkauffman]

I've got two 2600 series routers running 12.3.11 with AIM compression modules on either end. When I do a "show ppp multilink" I get the following:

Multilink1, bundle name is group1

Bundle up for 1w1d, 8/255 load

Receive buffer limit 24384 bytes, frag timeout 1000 ms

0/0 fragments/bytes in reassembly list

0 lost fragments, 25823 reordered

0/4488 discarded fragments/bytes, 0 lost received

0x9E8D14 received sequence, 0xCEB0A3 sent sequence

Member links: 2 active, 0 inactive (max 2, min not set)

Se0/1, since 1w1d

Se0/0, since 1w1d

The reordered counters keep increasing, A debug ppp multilink gives me:

Nov 3 09:20:46.620: Se0/0 MLP: O frag C0CEC223 size 152

Nov 3 09:20:46.636: Se0/1 MLP: I frag C09E9FE0 size 43

Nov 3 09:20:46.636: Se0/1 MLP: O frag C0CEC224 size 175

Nov 3 09:20:46.640: Se0/0 MLP: I frag C09E9FE1 size 32

Nov 3 09:20:46.712: Se0/0 MLP: O frag C0CEC225 size 745

Nov 3 09:20:46.712: Se0/1 MLP: O frag C0CEC226 size 745

Nov 3 09:20:46.716: Se0/1 MLP: I frag C09E9FE2 size 54

Nov 3 09:20:46.736: Se0/0 MLP: I frag C09E9FE3 size 30

Nov 3 09:20:46.736: Se0/0 MLP: O frag C0CEC227 size 54

Nov 3 09:20:46.740: Se0/1 MLP: O frag C0CEC228 size 260

Nov 3 09:20:46.744: Se0/1 MLP: I frag C09E9FE4 size 46

Nov 3 09:20:46.748: Se0/0 MLP: O frag C0CEC229 size 295

Nov 3 09:20:46.776: Se0/0 MLP: I frag C09E9FE5 size 36

Nov 3 09:20:46.788: Se0/1 MLP: O frag C0CEC22A size 92

Nov 3 09:20:46.800: Se0/1 MLP: I frag C09E9FE6 size 67

Nov 3 09:20:46.808: Se0/0 MLP: O frag C0CEC22B size 52

Nov 3 09:20:46.816: Se0/0 MLP: I frag C09E9FE7 size 51

Nov 3 09:20:46.824: Se0/1 MLP: O frag C0CEC22C size 31

Nov 3 09:20:46.832: Se0/1 MLP: I frag C09E9FE8 size 31

Nov 3 09:20:46.836: Se0/0 MLP: O frag C0CEC22D size 63

Nov 3 09:20:46.840: Se0/1 MLP: O frag C0CEC22E size 34

Nov 3 09:20:46.840: Se0/0 MLP: I frag C09E9FE9 size 33

If tried int the multilink interface: ppp multilink fragment disable, but to no avail.

I'm sure this random reordering of packets is not good for the CPU. All examples on Cisco weg page has the ppp multilink reorder counter a zero or near zero. Mine is going crazy.

[Kevin Dorrell]

You seem to have quite a diverse range of fragment sizes. That being the case, I'm not surprised that the small (but later) ones seem to arrive before the bigger (but earlier) ones, and therefore need reordering. What surprises me is that the Cisco documentation should show the reordering at or near zero.

I should explain that I am saying this not from experience, but working from first principles.

My guess is that switching off the fragmentation will not help very much because you will have exactly the same effect, but with packets rather than ML fragments. I guess that the debug then refers to frames rather than fragments? BTW, to affect the reordering, I think you should switch off the fragmentation at the other end.

All the fragments in your debug seem to have arrived in the correct order. How does the reordering counter compare with the total fragments passed?

It is interesting to see the wide range of fragment sizes on the interface. Does that mean that the compression is applied after the fragmentation? If you switch off the compression, but keep the fragmentation, do all the fragments come out more-or-less the same size? In which case, does the amount of reordering go down?

As for the CPU, does show proc cpu show any significant increase during multilink traffic?

Kevin Dorrell

Luxembourg