There is a day-1 product limitation of Contrail vRouter agent such that if the first packet has more than three fragments, the first three fragments pass while the fourth fragment is dropped. This causes incomplete packets to be received. This fragment drop issue only occurs before the traffic flow has been created on vRouter. Therefore, the following fragmented packets should pass without problems. If the packet type is TCP, a TCP re-transmit mitigates this limitation. However, for some user UDP/SIP application where the first jumbo packet carries import session information, it may cause a call session fail to set up. This article describes this product limitation.

SIP invites sourced from VM 2001:1890:1001:22c4::7:3 are sent to VRF VM 2001:1890:1001:22c4::3:20. The SIP invite messages are dropped. VM's MTU is set to 1500 which is fixed. These SIP invites are large packet sizes >4500 so they are fragmented. Captured traces on the source host tap interface show that all four fragments of SIP invite are being passed to the vRouter. However, the fourth fragmentation of SIP invite is not seen on bond0 underlay interface. Packet sniffers at the same time on source tap/bond0, destination tap/bond0.

In the Source TAP capture, note that all 4 fragments are highlighted:

But in source bond0 capture, note that the 4th fragment is missing:

This is a known vRouter fragmentation handling limitation described in the following bug reports:

• 1716308 (ipv6 UDP packet) - IPv6 Fragments: If there are more than 3 fragments for the first ICMPv6 packet then the packet is dropped.
• 1493687 (ipv4 case) - [R2.21-Build 95]: vrouter fragments handling issues and limitations

When the head fragment is received in the Vrouter, it is en-queued to the assembler immediately upon arrival. The flow is created as Hold flow, then trapped to agent. If fragments corresponding to this head fragment are already in the assembler or if new fragments arrive immediately after head fragment, the assembler releases them to flow module. If agent does not write flow action by the time assembler releases fragments to Flow module, fragments get en-queued in Hold queue. Only a maximum of three fragments are en-queued in the Hold queue. The rest of the fragments from assembler gets dropped in flow module. This leads to whole packet getting dropped in the receive side leading to first packet loss.

This is a known product limitation. A possible enhancement may be available in the future. Unless a user can adjust the MTU size to accommodate a jumbo packet or to generate less than four fragments strictly, there is no working workaround at the moment for the first packet corrupt issue.