Why fragmenting would cause packet loss on MLPPPoA/FR
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)
Re: Why fragmenting would cause packet loss on MLPPPoA/FR
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.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...