Why fragmenting would cause packet loss on MLPPPoA/FR

David Williams · ‎03-05-2010

I've been struggling with some MLPPPoA MLPPPoFR packet loss issues for the past couple days. We knew that packet size was an element to the problem we just didn't know why. Anything over 1494 bytes would experience 5 to 10 percent packet loss. Using access lists I was able to determine that the loss was happening outbound from the 7200 after the packets were counted by the access list. After trying many things I modified the mtu on the virtual template to 1506. This pushed the fragment size for the virtual-access interfaces to 1502 and resolved the packet loss. Since the only thing that made sense about that was that the fragment size was pushed higher than the 1500 byte mtu and consequently wasn't fragmenting any traffic, I changed the vt mtu back to 1500 and disable fragmenting with the ppp multilink fragment disable command on both multilink group interfaces. That too seemed to work. So why would fragmenting induce packet loss outbound from the 7200? I've attached a basic diagram and included some config from the 7200. I'd love to hear any theories.

interface Multilink68
description TEST MLPPP
bandwidth 3072
ip address x.x.x.x
no ip redirects
no ip unreachables
no ip proxy-arp
no snmp trap link-status
ppp multilink
ppp multilink interleave
ppp multilink group 68
ppp multilink fragment delay 10
no cdp enable
service-policy output qos
end

interface Virtual-Template68
description TEST MLPPP
bandwidth 1536
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
no snmp trap link-status
ppp multilink
ppp multilink group 68
end

Multilink68, bundle name is remote-router
Endpoint discriminator is remote-router
Bundle up for 00:14:54, total bandwidth 3072, load 1/255
Receive buffer limit 24000 bytes, frag timeout 1000 ms
Interleaving enabled
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 5857 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x46D8 received sequence, 0x46B9 sent sequence
Member links: 2 active, 1 inactive (max not set, min not set)
    Vi14, since 00:14:54, 1920 weight, 1496 frag size
    PPPoATM link, ATM PVC 0/197 on ATM6/0.197
    Packets in ATM PVC Holdq: 0 , Particles in ATM PVC Tx Ring: 0
    Vi69, since 00:14:54, 1920 weight, 1496 frag size
    PPPoATM link, ATM PVC 0/196 on ATM6/0.196
    Packets in ATM PVC Holdq: 0 , Particles in ATM PVC Tx Ring: 0
    Vt68 (inactive)

David Williams · ‎04-15-2010

This seems to be a bug. A reload of the chassis resolved the issue for now. We are due for code upgrades anyway so we will pursue that path and hope the issue doesn't return. I would like to identify the bug but once the router was reloaded we couldn't replicate the issue.