[R2.21-Build 95]: vrouter fragments handling issues and limitations
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Juniper Openstack | Status tracked in Trunk | |||||
R2.20 |
Won't Fix
|
Low
|
Raja Sivaramakrishnan | |||
R3.0 |
Won't Fix
|
Low
|
Raja Sivaramakrishnan | |||
R3.2 |
Won't Fix
|
High
|
Raja Sivaramakrishnan | |||
R4.0 |
Won't Fix
|
High
|
Raja Sivaramakrishnan | |||
Trunk |
New
|
High
|
Raja Sivaramakrishnan |
Bug Description
Listing few issues which was found during out of order fragments testing:
1. Fragments with partial TCP header gets dropped but still creates the flow and next fragments gets forwarded to receiver.In this case as first fragment would be missing, receiver can not reassemble it which will cause retransmission.
2. Overlapping fragments:
When the fragment head has full TCP header and next fragments offset is 1 then vrouter forwards this fragment.This may cause problem when fragments with offset 1 overwrites the flags fields of TCP header.
To avoid issues 1 and 2, as per RFC 1858:
"A general algorithm, then, for ensuring that filters work in the
face of both the tiny fragment attack and the overlapping fragment
attack is:
IF FO=1 and PROTOCOL=TCP then
"
3. limitation of flow buffer size 3. sometime this leads to fragments loss when fragment head is received after 3 or more fragments.
If fragments received in order f1,f2,f3,f4,f0 then f3 and f4 may get dropped.
As per discussion with Raja:
[9/2/15, 11:02:21 AM] Raja Sivaramakrishnan: If the flow was already present when the fragments are received in this order, vrouter will forward f0, f1, f2, f3, f4.
[9/2/15, 11:04:51 AM] Raja Sivaramakrishnan: If this is the first packet of the flow, then timing comes into play. If agent sets f0 to forward before vrouter gets around to processing f0 (asynchronously), no drops will occur. Otherwise, f0, f1, f2 will be forwarded. f3, f4 will be dropped (but the flow will continue to remain, so if the retransmission is also similarly fragmented, we should be ok).
[9/2/15, 11:07:48 AM] Raja Sivaramakrishnan: I am about to go offline now. Anything else to discuss?
[9/2/15, 11:09:25 AM] alok kumar: but we storing all the fragments till flow is created?
[9/2/15, 11:11:48 AM] alok kumar: if there is separate fragment buffer to store all the frags then why we need to drop few. this part im not able to understand.
[9/2/15, 11:14:23 AM] Raja Sivaramakrishnan: yes, but the flow entry itself has space for only 3 packets. It is possible to forward the other fragments, but will take more work. Don’t think it can be done in 2.21.
4. Mixed fragments with same id for same source/
summary: |
- [R2.21-Build 95]: vrouter fragments handling issues + [R2.21-Build 95]: vrouter fragments handling issues and limitations |
tags: | added: releasenote |
information type: | Proprietary → Public |
Changed in juniperopenstack: | |
assignee: | nobody → Raja Sivaramakrishnan (raja-u) |
status: | New → Won't Fix |
information type: | Public → Private |
tags: | added: att-aic-contrail |
tags: | added: blocker |
information type: | Private → Public |
I used contrail R3.0 version now and found that if fragment happened in UDP packet, the performance dropped distinctly. Is it related to this bug?
Thanks
Andy Wang