poBuild 2723: traffic flow not stable when svm's right port as src ecmp with port mirroring enabled

Bug #1552101 reported by Ankit Jain
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
R2.20
Fix Committed
High
Anand H. Krishnan
R2.21.x
Fix Committed
High
Anand H. Krishnan
R2.22.x
Fix Committed
High
Anand H. Krishnan
R3.0
Fix Committed
High
Anand H. Krishnan
Trunk
Fix Committed
High
Anand H. Krishnan

Bug Description

Issue: Ping reply was getting dropped after enabling port mirroring on svm's right port

svm's right ports as src ecmp

                                                                svcinst1 tranparent
left-vm-5 10.1.1.8 (vn1) ------(vn1)left-vn svm1, svm2, svm4 rightvn(vn2)------right-vm-2 20.1.1.7
                                                                                                                          |
                                                                                                         analyzer-3 40.1.1.6(vn4)

Routes leaked from vn2 to vn4 through RT

Port mirroring enabled on svm1's right port, svm2's right port and svm3's right port

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

Review in progress for https://review.opencontrail.org/18090
Submitter: Anand H. Krishnan (<email address hidden>)

Revision history for this message
Nagabhushana R (bhushana) wrote :

This seems to be an issue when port mirroring is enabled on a Service VM which is part of a 'transparent Service chain'. We need to release note this.

Changed in juniperopenstack:
importance: Undecided → High
tags: added: releasenote
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] master

Review in progress for https://review.opencontrail.org/18368
Submitter: Anand H. Krishnan (<email address hidden>)

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

Reviewed: https://review.opencontrail.org/18090
Committed: http://github.org/Juniper/contrail-vrouter/commit/356bc69d51bbd760e37f31ab48f5f4cc02d53f98
Submitter: Zuul
Branch: R3.0

commit 356bc69d51bbd760e37f31ab48f5f4cc02d53f98
Author: Anand H. Krishnan <email address hidden>
Date: Wed Mar 2 12:12:07 2016 +0530

Do not reuse forwarding metadata post mirroring

A mirror action needs its own forwarding metadata since the forwarding
parameeters that are used for mirroring will be different from those
that are used for packet forwarding. In this particular case, the vrf
to which the packets are mirrored are different from the vrf to which
packets need to be classified, and hence the packets were dropped in the
flow module with no source route as the drop reason.

Change-Id: I21930818a5cdec560818acb79f671ce29ac8bc85
Closes-BUG: #1552101

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

Reviewed: https://review.opencontrail.org/18368
Committed: http://github.org/Juniper/contrail-vrouter/commit/7481ce1b1289a545a865f00a9e74637444f50385
Submitter: Zuul
Branch: master

commit 7481ce1b1289a545a865f00a9e74637444f50385
Author: Anand H. Krishnan <email address hidden>
Date: Tue Mar 1 00:35:52 2016 +0530

Post GRO, label in fmd can't be used to check whether the packet
was tunneled or not

Once the packet is submitted for GRO, all datapath information is
lost. Post GRO, only values that are saved in the packet are the
vif and the nexthop. vif is a recent addition to the saved
information that helped us to identify which interface the packet
came from originally. Once the vif value was set properly, the logic
that checked whether the packet should be trapped to agent or not
based on the presence of label (basically fabric arp responses should
be trapped or not), misbehaved since label information is not saved
pre-GRO and hence not available in the metadata post GRO. For now,
fix the specific logic by checking whether the egress vrf is different
from the ingress vrf, which will be the case since physical interface
vrf will not be the same as vm's vrf.

Change-Id: Iba000889039bc8a5020fc11a462ba1b1a68ce1c8
Closes-BUG: #1551382

Do not reuse forwarding metadata post mirroring

A mirror action needs its own forwarding metadata since the forwarding
parameeters that are used for mirroring will be different from those
that are used for packet forwarding. In this particular case, the vrf
to which the packets are mirrored are different from the vrf to which
packets need to be classified, and hence the packets were dropped in the
flow module with no source route as the drop reason.

Change-Id: I21930818a5cdec560818acb79f671ce29ac8bc85
Closes-BUG: #1552101

Changed in juniperopenstack:
milestone: r3.0-fcs → r3.1.0.0-fcs
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R2.21.x

Review in progress for https://review.opencontrail.org/18729
Submitter: Anand H. Krishnan (<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/18732
Submitter: Anand H. Krishnan (<email address hidden>)

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

Review in progress for https://review.opencontrail.org/18730
Submitter: Anand H. Krishnan (<email address hidden>)

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

Reviewed: https://review.opencontrail.org/18730
Committed: http://github.org/Juniper/contrail-vrouter/commit/a4a93081416697c3f47db63050f288e55292d4b3
Submitter: Zuul
Branch: R2.20

commit a4a93081416697c3f47db63050f288e55292d4b3
Author: Anand H. Krishnan <email address hidden>
Date: Wed Mar 2 12:12:07 2016 +0530

Do not reuse forwarding metadata post mirroring

A mirror action needs its own forwarding metadata since the forwarding
parameeters that are used for mirroring will be different from those
that are used for packet forwarding. In this particular case, the vrf
to which the packets are mirrored are different from the vrf to which
packets need to be classified, and hence the packets were dropped in the
flow module with no source route as the drop reason.

Change-Id: I21930818a5cdec560818acb79f671ce29ac8bc85
Closes-BUG: #1552101

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

Reviewed: https://review.opencontrail.org/18732
Committed: http://github.org/Juniper/contrail-vrouter/commit/d3d0e9846c0ed5c4d783f77706839afcc5494c1d
Submitter: Zuul
Branch: R3.0

commit d3d0e9846c0ed5c4d783f77706839afcc5494c1d
Author: Anand H. Krishnan <email address hidden>
Date: Thu Mar 24 14:15:24 2016 +0530

Pass correct forwarding metadata to mirroring

Post copying the metadata to the one supposed to be used for mirroring
and modifying the vrf value in it, we are not passing the copy to the
mirror.

Change-Id: Id3cbc5dcc296fc005d06a9aa797339c1cc4a10cc
Closes-BUG: #1552101

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

Reviewed: https://review.opencontrail.org/18729
Committed: http://github.org/Juniper/contrail-vrouter/commit/56611ab4bc5826c60081445420f0f80494f3b4b2
Submitter: Zuul
Branch: R2.21.x

commit 56611ab4bc5826c60081445420f0f80494f3b4b2
Author: Anand H. Krishnan <email address hidden>
Date: Wed Mar 2 12:12:07 2016 +0530

Do not reuse forwarding metadata post mirroring

A mirror action needs its own forwarding metadata since the forwarding
parameeters that are used for mirroring will be different from those
that are used for packet forwarding. In this particular case, the vrf
to which the packets are mirrored are different from the vrf to which
packets need to be classified, and hence the packets were dropped in the
flow module with no source route as the drop reason.

Change-Id: I21930818a5cdec560818acb79f671ce29ac8bc85
Closes-BUG: #1552101

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

Reviewed: https://review.opencontrail.org/18731
Committed: http://github.org/Juniper/contrail-vrouter/commit/eeaa761b982524b1e0984b91dc417c98fe4c52ed
Submitter: Zuul
Branch: R2.22.x

commit eeaa761b982524b1e0984b91dc417c98fe4c52ed
Author: Anand H. Krishnan <email address hidden>
Date: Wed Mar 2 12:12:07 2016 +0530

Do not reuse forwarding metadata post mirroring

A mirror action needs its own forwarding metadata since the forwarding
parameeters that are used for mirroring will be different from those
that are used for packet forwarding. In this particular case, the vrf
to which the packets are mirrored are different from the vrf to which
packets need to be classified, and hence the packets were dropped in the
flow module with no source route as the drop reason.

Change-Id: I21930818a5cdec560818acb79f671ce29ac8bc85
Closes-BUG: #1552101

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

Other bug subscribers

Remote bug watches

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