Juniper Openstack

2.21.2-36:Out of order fragments are not received well by the vRouter

  1. Series r3.2.3.x
  2. Bug #1698986
Bug #1698986 reported by Sandeep Sridhar
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
R2.21.x
Fix Committed
Critical
Divakar Dharanalakota
Juniper Openstack r2.21.3
R2.22.x
Fix Committed
Critical
Divakar Dharanalakota
Juniper Openstack r2.22.3
R3.0
Fix Committed
Critical
Divakar Dharanalakota
Juniper Openstack r3.0.4.0
R3.0.2.x
Fix Committed
Critical
Divakar Dharanalakota
Juniper Openstack r3.0.2.1
R3.0.3.x
Fix Committed
Critical
Divakar Dharanalakota
R3.1
Fix Committed
Critical
Divakar Dharanalakota
Juniper Openstack r3.1.3.0
R3.1.1.x
Fix Committed
Critical
Divakar Dharanalakota
R3.2
Fix Committed
Critical
Divakar Dharanalakota
Juniper Openstack r3.2.4.0
R3.2.3.x
Fix Committed
Critical
Divakar Dharanalakota
Juniper Openstack r3.2.3.2
R4.0
Fix Committed
Critical
Divakar Dharanalakota
Juniper Openstack r4.0.1.0 "r4.0.1.0"
Trunk
Fix Committed
Critical
Divakar Dharanalakota
Juniper Openstack r4.1.0.0-fcs "r4.1"

Bug Description

If a fragment without transport header (non-head fragment) is received on Fabric interface with VXLAN encapsulation, vRouter caches in assembler till the head fragment (fragment with transport header) is received. Once the head fragment is received, vRouter fails to map to same flow entry as head fragment flow. There is a bug in our code which is wrongly calculating the key next-hop index for the flow entry. This is observed only for VXLAN encapsulation and other encapsulations are fine (MPLSoGRE/UDP). This issue exists across all releases. Please fix this on all branches.

163957<=>334232 10.11.84.253:40788 192.168.241.254:0 1 (24)
(K(nh):711, Action:F, E:0, S(nh):0, Statistics:1/1514 UdpSrcPort 61947), Action:F

--
287448 10.11.84.253:40788 192.168.241.254:0 1 (24)
(K(nh):0, Action:H, S(nh):0, Statistics:1/56 UdpSrcPort 0), Action:H

--
334232<=>163957 192.168.241.254:40788 10.11.84.253:0 1 (24)
(K(nh):711, Action:F, E:0, S(nh):0, Statistics:0/0 UdpSrcPort 64038),Action:F

Greetings,
Sandeep.

Tags: vrouter
Sandeep Sridhar (ssandeep)
Changed in juniperopenstack:
assignee: nobody → Divakar Dharanalakota (ddivakar)
importance: Undecided → Critical
milestone: none → r3.1.1.1
information type: Proprietary → Public
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] master

Review in progress for https://review.opencontrail.org/33012
Submitter: Divakar Dharanalakota (<email address hidden>)

Hari Prasad Killi (haripk)
tags: added: vrouter
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

Reviewed: https://review.opencontrail.org/33012
Committed: http://github.com/Juniper/contrail-vrouter/commit/84603e172554a835043fcff879b142ad9fa04ba0
Submitter: Zuul (<email address hidden>)
Branch: master

commit 84603e172554a835043fcff879b142ad9fa04ba0
Author: Divakar D <email address hidden>
Date: Tue Jun 20 17:22:52 2017 +0530

Fill the NH of the packet in fragment assembler

When fragments are recieved out of order, assembler code caches them
till head fragment is received. While holding the packet, packet's nh is
not cached to avoid taking a reference to NH. Once the head fragment is
received, these out of order fragments are released for flow processing.
While doing this, packet's nh is not filled if the encap is Vxlan packet
as this requires a mac address lookup. For Mpls packets, label is looked
up to extract the NH. Not filling the NH, is resulting in Flow lookup
failure as NH id is also a key for the flow table. Failure to look up
the original flow entry (of head fragment) results in either creating
the new flow entry (with wrong key nh id) in Hold state, or dropping the
packet without flow processing.

To avoid this, bridge look up is done in the given VRF, to extract the
NH.

Change-Id: I03101536e3ac063f16bc4ea31a4b4f5041a5f2f6
closes-bug: #1698986

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R4.0

Review in progress for https://review.opencontrail.org/33053
Submitter: Divakar Dharanalakota (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R3.2

Review in progress for https://review.opencontrail.org/33054
Submitter: Divakar Dharanalakota (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R3.1

Review in progress for https://review.opencontrail.org/33055
Submitter: Divakar Dharanalakota (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R3.0

Review in progress for https://review.opencontrail.org/33056
Submitter: Divakar Dharanalakota (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R3.2.3.x

Review in progress for https://review.opencontrail.org/33057
Submitter: Divakar Dharanalakota (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R3.1.1.x

Review in progress for https://review.opencontrail.org/33058
Submitter: Divakar Dharanalakota (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R3.0.3.x

Review in progress for https://review.opencontrail.org/33059
Submitter: Divakar Dharanalakota (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R3.0.2.x

Review in progress for https://review.opencontrail.org/33060
Submitter: Divakar Dharanalakota (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R2.22.x

Review in progress for https://review.opencontrail.org/33061
Submitter: Divakar Dharanalakota (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R2.21.x

Review in progress for https://review.opencontrail.org/33062
Submitter: Divakar Dharanalakota (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

Reviewed: https://review.opencontrail.org/33059
Committed: http://github.com/Juniper/contrail-vrouter/commit/4349fdd01a287a1ca84a33d275053978f4b8262d
Submitter: Zuul (<email address hidden>)
Branch: R3.0.3.x

commit 4349fdd01a287a1ca84a33d275053978f4b8262d
Author: Divakar D <email address hidden>
Date: Tue Jun 20 17:22:52 2017 +0530

Fill the NH of the packet in fragment assembler

When fragments are recieved out of order, assembler code caches them
till head fragment is received. While holding the packet, packet's nh is
not cached to avoid taking a reference to NH. Once the head fragment is
received, these out of order fragments are released for flow processing.
While doing this, packet's nh is not filled if the encap is Vxlan packet
as this requires a mac address lookup. For Mpls packets, label is looked
up to extract the NH. Not filling the NH, is resulting in Flow lookup
failure as NH id is also a key for the flow table. Failure to look up
the original flow entry (of head fragment) results in either creating
the new flow entry (with wrong key nh id) in Hold state, or dropping the
packet without flow processing.

To avoid this, bridge look up is done in the given VRF, to extract the
NH.

closes-bug: #1698986

Conflicts:
 dp-core/vr_bridge.c
 dp-core/vr_flow.c
 include/vr_bridge.h

Change-Id: Iba3185cf3289b8d42e98af598ec5ac82adaedc45

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/33054
Committed: http://github.com/Juniper/contrail-vrouter/commit/93523e65d82ddf57279e8b47a3d0fd50d753815b
Submitter: Zuul (<email address hidden>)
Branch: R3.2

commit 93523e65d82ddf57279e8b47a3d0fd50d753815b
Author: Divakar D <email address hidden>
Date: Tue Jun 20 17:22:52 2017 +0530

Fill the NH of the packet in fragment assembler

When fragments are recieved out of order, assembler code caches them
till head fragment is received. While holding the packet, packet's nh is
not cached to avoid taking a reference to NH. Once the head fragment is
received, these out of order fragments are released for flow processing.
While doing this, packet's nh is not filled if the encap is Vxlan packet
as this requires a mac address lookup. For Mpls packets, label is looked
up to extract the NH. Not filling the NH, is resulting in Flow lookup
failure as NH id is also a key for the flow table. Failure to look up
the original flow entry (of head fragment) results in either creating
the new flow entry (with wrong key nh id) in Hold state, or dropping the
packet without flow processing.

To avoid this, bridge look up is done in the given VRF, to extract the
NH.

closes-bug: #1698986

Conflicts:
 dp-core/vr_bridge.c
 dp-core/vr_flow.c
 include/vr_bridge.h

Change-Id: I6b5ab1163f7d5381ccc8ec4f2ccce0df2efe332b

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/33057
Committed: http://github.com/Juniper/contrail-vrouter/commit/5404714af34afd1a075eac6f4b90eed77596273b
Submitter: Zuul (<email address hidden>)
Branch: R3.2.3.x

commit 5404714af34afd1a075eac6f4b90eed77596273b
Author: Divakar D <email address hidden>
Date: Tue Jun 20 17:22:52 2017 +0530

Fill the NH of the packet in fragment assembler

When fragments are recieved out of order, assembler code caches them
till head fragment is received. While holding the packet, packet's nh is
not cached to avoid taking a reference to NH. Once the head fragment is
received, these out of order fragments are released for flow processing.
While doing this, packet's nh is not filled if the encap is Vxlan packet
as this requires a mac address lookup. For Mpls packets, label is looked
up to extract the NH. Not filling the NH, is resulting in Flow lookup
failure as NH id is also a key for the flow table. Failure to look up
the original flow entry (of head fragment) results in either creating
the new flow entry (with wrong key nh id) in Hold state, or dropping the
packet without flow processing.

To avoid this, bridge look up is done in the given VRF, to extract the
NH.

closes-bug: #1698986

Conflicts:
 dp-core/vr_bridge.c
 dp-core/vr_flow.c
 include/vr_bridge.h

Change-Id: I93697ecee507dca380ed13ae7160c92cd233a97e

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/33053
Committed: http://github.com/Juniper/contrail-vrouter/commit/83b005a867a6897576b8d62afd1fae7e5f46be11
Submitter: Zuul (<email address hidden>)
Branch: R4.0

commit 83b005a867a6897576b8d62afd1fae7e5f46be11
Author: Divakar D <email address hidden>
Date: Tue Jun 20 17:22:52 2017 +0530

Fill the NH of the packet in fragment assembler

When fragments are recieved out of order, assembler code caches them
till head fragment is received. While holding the packet, packet's nh is
not cached to avoid taking a reference to NH. Once the head fragment is
received, these out of order fragments are released for flow processing.
While doing this, packet's nh is not filled if the encap is Vxlan packet
as this requires a mac address lookup. For Mpls packets, label is looked
up to extract the NH. Not filling the NH, is resulting in Flow lookup
failure as NH id is also a key for the flow table. Failure to look up
the original flow entry (of head fragment) results in either creating
the new flow entry (with wrong key nh id) in Hold state, or dropping the
packet without flow processing.

To avoid this, bridge look up is done in the given VRF, to extract the
NH.

Change-Id: I03101536e3ac063f16bc4ea31a4b4f5041a5f2f6
closes-bug: #1698986

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/33060
Committed: http://github.com/Juniper/contrail-vrouter/commit/124f4e339fd18c52d23200f8d009996c4f981888
Submitter: Zuul (<email address hidden>)
Branch: R3.0.2.x

commit 124f4e339fd18c52d23200f8d009996c4f981888
Author: Divakar D <email address hidden>
Date: Tue Jun 20 17:22:52 2017 +0530

Fill the NH of the packet in fragment assembler

When fragments are recieved out of order, assembler code caches them
till head fragment is received. While holding the packet, packet's nh is
not cached to avoid taking a reference to NH. Once the head fragment is
received, these out of order fragments are released for flow processing.
While doing this, packet's nh is not filled if the encap is Vxlan packet
as this requires a mac address lookup. For Mpls packets, label is looked
up to extract the NH. Not filling the NH, is resulting in Flow lookup
failure as NH id is also a key for the flow table. Failure to look up
the original flow entry (of head fragment) results in either creating
the new flow entry (with wrong key nh id) in Hold state, or dropping the
packet without flow processing.

To avoid this, bridge look up is done in the given VRF, to extract the
NH.

closes-bug: #1698986

Conflicts:
 dp-core/vr_bridge.c
 dp-core/vr_flow.c
 include/vr_bridge.h

Change-Id: I1b0c507cbd82c78a06b2d8f7c60d9e42181d029f

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/33062
Committed: http://github.com/Juniper/contrail-vrouter/commit/ab6162dc6fdf30167f3ece21a712e1512425f6e7
Submitter: Zuul (<email address hidden>)
Branch: R2.21.x

commit ab6162dc6fdf30167f3ece21a712e1512425f6e7
Author: Divakar D <email address hidden>
Date: Tue Jun 20 17:22:52 2017 +0530

Fill the NH of the packet in fragment assembler

When fragments are recieved out of order, assembler code caches them
till head fragment is received. While holding the packet, packet's nh is
not cached to avoid taking a reference to NH. Once the head fragment is
received, these out of order fragments are released for flow processing.
While doing this, packet's nh is not filled if the encap is Vxlan packet
as this requires a mac address lookup. For Mpls packets, label is looked
up to extract the NH. Not filling the NH, is resulting in Flow lookup
failure as NH id is also a key for the flow table. Failure to look up
the original flow entry (of head fragment) results in either creating
the new flow entry (with wrong key nh id) in Hold state, or dropping the
packet without flow processing.

To avoid this, bridge look up is done in the given VRF, to extract the
NH.

closes-bug: #1698986

Conflicts:
 dp-core/vr_bridge.c
 dp-core/vr_flow.c
 include/vr_bridge.h

Change-Id: I6e5d4efa31316800558a234595cf59d3d98f04e0

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/33056
Committed: http://github.com/Juniper/contrail-vrouter/commit/100295edeff1c481875f09bedc3fb206c4ef7fad
Submitter: Zuul (<email address hidden>)
Branch: R3.0

commit 100295edeff1c481875f09bedc3fb206c4ef7fad
Author: Divakar D <email address hidden>
Date: Tue Jun 20 17:22:52 2017 +0530

Fill the NH of the packet in fragment assembler

When fragments are recieved out of order, assembler code caches them
till head fragment is received. While holding the packet, packet's nh is
not cached to avoid taking a reference to NH. Once the head fragment is
received, these out of order fragments are released for flow processing.
While doing this, packet's nh is not filled if the encap is Vxlan packet
as this requires a mac address lookup. For Mpls packets, label is looked
up to extract the NH. Not filling the NH, is resulting in Flow lookup
failure as NH id is also a key for the flow table. Failure to look up
the original flow entry (of head fragment) results in either creating
the new flow entry (with wrong key nh id) in Hold state, or dropping the
packet without flow processing.

To avoid this, bridge look up is done in the given VRF, to extract the
NH.

closes-bug: #1698986

Conflicts:
 dp-core/vr_bridge.c
 dp-core/vr_flow.c
 include/vr_bridge.h

Change-Id: I62d1f0a2bd2112636a43ec00a25a9530838bd8ae

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/33058
Committed: http://github.com/Juniper/contrail-vrouter/commit/f107eaf4a2cd5fbd39bbb36f81289c49838dddf8
Submitter: Zuul (<email address hidden>)
Branch: R3.1.1.x

commit f107eaf4a2cd5fbd39bbb36f81289c49838dddf8
Author: Divakar D <email address hidden>
Date: Tue Jun 20 17:22:52 2017 +0530

Fill the NH of the packet in fragment assembler

When fragments are recieved out of order, assembler code caches them
till head fragment is received. While holding the packet, packet's nh is
not cached to avoid taking a reference to NH. Once the head fragment is
received, these out of order fragments are released for flow processing.
While doing this, packet's nh is not filled if the encap is Vxlan packet
as this requires a mac address lookup. For Mpls packets, label is looked
up to extract the NH. Not filling the NH, is resulting in Flow lookup
failure as NH id is also a key for the flow table. Failure to look up
the original flow entry (of head fragment) results in either creating
the new flow entry (with wrong key nh id) in Hold state, or dropping the
packet without flow processing.

To avoid this, bridge look up is done in the given VRF, to extract the
NH.

closes-bug: #1698986

Conflicts:
 dp-core/vr_bridge.c
 dp-core/vr_flow.c
 include/vr_bridge.h

Change-Id: Idf50ba23c1b04c828080cf258d1af35205bb1b4a

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/33055
Committed: http://github.com/Juniper/contrail-vrouter/commit/bf58fdb4cc854bc028825f807b3f3c3d853a6598
Submitter: Zuul (<email address hidden>)
Branch: R3.1

commit bf58fdb4cc854bc028825f807b3f3c3d853a6598
Author: Divakar D <email address hidden>
Date: Tue Jun 20 17:22:52 2017 +0530

Fill the NH of the packet in fragment assembler

When fragments are recieved out of order, assembler code caches them
till head fragment is received. While holding the packet, packet's nh is
not cached to avoid taking a reference to NH. Once the head fragment is
received, these out of order fragments are released for flow processing.
While doing this, packet's nh is not filled if the encap is Vxlan packet
as this requires a mac address lookup. For Mpls packets, label is looked
up to extract the NH. Not filling the NH, is resulting in Flow lookup
failure as NH id is also a key for the flow table. Failure to look up
the original flow entry (of head fragment) results in either creating
the new flow entry (with wrong key nh id) in Hold state, or dropping the
packet without flow processing.

To avoid this, bridge look up is done in the given VRF, to extract the
NH.

closes-bug: #1698986

Conflicts:
 dp-core/vr_bridge.c
 dp-core/vr_flow.c
 include/vr_bridge.h

Change-Id: I4deb969849db10903ddd88cd58198aa04546adb7

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/33061
Committed: http://github.com/Juniper/contrail-vrouter/commit/b97b2d116a65bc992c5d8b561564a56a1f00b837
Submitter: Zuul (<email address hidden>)
Branch: R2.22.x

commit b97b2d116a65bc992c5d8b561564a56a1f00b837
Author: Divakar D <email address hidden>
Date: Tue Jun 20 17:22:52 2017 +0530

Fill the NH of the packet in fragment assembler

When fragments are recieved out of order, assembler code caches them
till head fragment is received. While holding the packet, packet's nh is
not cached to avoid taking a reference to NH. Once the head fragment is
received, these out of order fragments are released for flow processing.
While doing this, packet's nh is not filled if the encap is Vxlan packet
as this requires a mac address lookup. For Mpls packets, label is looked
up to extract the NH. Not filling the NH, is resulting in Flow lookup
failure as NH id is also a key for the flow table. Failure to look up
the original flow entry (of head fragment) results in either creating
the new flow entry (with wrong key nh id) in Hold state, or dropping the
packet without flow processing.

To avoid this, bridge look up is done in the given VRF, to extract the
NH.

closes-bug: #1698986

Conflicts:
 dp-core/vr_bridge.c
 dp-core/vr_flow.c
 include/vr_bridge.h

Change-Id: Ida6a96f86bf5df62e7b8fef152c741bd9e2bc873

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.