Build 2715 : Port mirroring not working when src vm and analyzer vm on different CNs

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

Review in progress for https://review.opencontrail.org/17961
Submitter: Hari Prasad Killi (<email address hidden>)

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

commit ce86dd46913a85e16a56099d7df2066bf0ef2625
Author: Divakar <email address hidden>
Date: Sat Feb 27 09:37:41 2016 +0530

Use innerpacket's destip as source ip while doing Tx Port mirroring

When Transmit port mirroring is enabled, packet received on Fabric
interface is right now mirrored using the source IP of the inner packet.
This results in RPF failure on Analyzer VM's compute node because the
compute node which is doing the port mirroring is using other compute
node's VM IP.

As a fix, if mirroring is Tax mirroring, rather using inner packets
source ip, dest ip is used, so that Analyzer VM's RPF will not have any
issues

Change-Id: I5beaa0dd0cc3c886a1e77f244c8003595ed348e2
closes-bug: #1550312

Reviewed: https://review.opencontrail.org/17961
Committed: http://github.org/Juniper/contrail-controller/commit/3a91f7d39688afca74b53229696568db677afbcc
Submitter: Zuul
Branch: R3.0

commit 3a91f7d39688afca74b53229696568db677afbcc
Author: Hari <email address hidden>
Date: Sat Feb 27 22:51:56 2016 +0530

Use current vrf for mirror entry.

Do not use the vrf name so that -1 (current vrf) will be used.

Change-Id: I1627dbdce471980813a1e2830e07aa3ed3b2ab73
related-bug: 1550312

The following were the scenarios where port mirroring was not working:

1)Analyzer : nodei4 analyzervn2-4 20.1.1.13 VN2 <--- This should work with Divakar's changes
10.1.1.7 nodeh6 ——20.1.1.9 nodei5
10.1.1.4 nodei4 — 20.1.1.9 nodei5
10.1.1.7 nodeh6— 20.1.1.10 nodei4

2) Analyzer : nodei4 analyzervn3-4 50.1.1.6 VN3 <--This should work with Hari's changes
10.1.1.7 nodeh6 ——20.1.1.11 nodeh6
10.1.1.7 nodeh6 ——20.1.1.9 nodei5
10.1.1.7 nodeh6— 20.1.1.10 nodei4

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

Reviewed: https://review.opencontrail.org/17993
Committed: http://github.org/Juniper/contrail-vrouter/commit/3958b00a2bff624bfdb49f42b56d6c637b44b901
Submitter: Zuul
Branch: master

commit 3958b00a2bff624bfdb49f42b56d6c637b44b901
Author: Divakar <email address hidden>
Date: Sat Feb 27 09:37:41 2016 +0530

Use innerpacket's destip as source ip while doing Tx Port mirroring

When Transmit port mirroring is enabled, packet received on Fabric
interface is right now mirrored using the source IP of the inner packet.
This results in RPF failure on Analyzer VM's compute node because the
compute node which is doing the port mirroring is using other compute
node's VM IP.

As a fix, if mirroring is Tax mirroring, rather using inner packets
source ip, dest ip is used, so that Analyzer VM's RPF will not have any
issues

closes-bug: #1550312

Conflicts:
 dp-core/vr_mirror.c

Change-Id: Iaef919a47dceff00efd183d9b128e07ec8b6a0ba

Review in progress for https://review.opencontrail.org/18112
Submitter: Praveen K V (<email address hidden>)

Reviewed: https://review.opencontrail.org/18112
Committed: http://github.org/Juniper/contrail-controller/commit/369031afe9489acdaf2c688410c0f4d1c79ce9a3
Submitter: Zuul
Branch: master

commit 369031afe9489acdaf2c688410c0f4d1c79ce9a3
Author: Hari <email address hidden>
Date: Sat Feb 27 22:51:56 2016 +0530

Use current vrf for mirror entry.

Do not use the vrf name so that -1 (current vrf) will be used.

(cherry picked from commit ca360231a5f2bb897c5cef0deaa3d9585e65306c)
related-bug: 1550312
Change-Id: I1627dbdce471980813a1e2830e07aa3ed3b2ab73

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

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

commit a2f91353b8488de562f91cd6e1f565d5a5c41c79
Author: Divakar <email address hidden>
Date: Sat Feb 27 09:37:41 2016 +0530

Use innerpacket's destip as source ip while doing Tx Port mirroring

When Transmit port mirroring is enabled, packet received on Fabric
interface is right now mirrored using the source IP of the inner packet.
This results in RPF failure on Analyzer VM's compute node because the
compute node which is doing the port mirroring is using other compute
node's VM IP.

As a fix, if mirroring is Tax mirroring, rather using inner packets
source ip, dest ip is used, so that Analyzer VM's RPF will not have any
issues

closes-bug: #1550312

Conflicts:
 dp-core/vr_mirror.c
 dp-core/vr_nexthop.c

Change-Id: I43a3304f8186f3489c97be3093a5dbea4a247762

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

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

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

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

commit 0f6968087779988f36a68423f4eceb4e92874035
Author: Divakar <email address hidden>
Date: Sat Feb 27 09:37:41 2016 +0530

Use innerpacket's destip as source ip while doing Tx Port mirroring

When Transmit port mirroring is enabled, packet received on Fabric
interface is right now mirrored using the source IP of the inner packet.
This results in RPF failure on Analyzer VM's compute node because the
compute node which is doing the port mirroring is using other compute
node's VM IP.

As a fix, if mirroring is Tax mirroring, rather using inner packets
source ip, dest ip is used, so that Analyzer VM's RPF will not have any
issues

Using the correct FMD and setting pkt_type correctly for mirrored packets

If port mirroring is enabled, cloned packet is subjected to mirroring
using the original packet's forwarding metadata. If mirroring code
changes the metadata content, original packet will be forwarded as per
the changed fmd and results in wrong forwarding.

In the current case, mirroring is to a VM in different VN (hence new VRF)
and mirroring code is modifying the fmd's dvrf to new VRF.
The original ARP packet's L2 and L3 looksups are happening on the
modified VRF resulting in ARP getting dropped.

Also the type of packet is identified using vr_pkt_type() after packet
is mirrored. This is resulting in wrong pkt_type being used for mirrored
packet hence the source IP packet the mirrored packet is not correctly
computed.

As a fix, new FMD is used for mirrored packet and packet type is
identified before mirroring itself.

Change-Id: If6c1d75692dbd29daf8594d35d1452e5d5efad77
closes-bug: #1549727
closes-bug: #1550312

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

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

commit b898326e4a15199d5b8555d158a3509bd2bfcb8b
Author: Divakar <email address hidden>
Date: Sat Feb 27 09:37:41 2016 +0530

Use innerpacket's destip as source ip while doing Tx Port mirroring

When Transmit port mirroring is enabled, packet received on Fabric
interface is right now mirrored using the source IP of the inner packet.
This results in RPF failure on Analyzer VM's compute node because the
compute node which is doing the port mirroring is using other compute
node's VM IP.

As a fix, if mirroring is Tax mirroring, rather using inner packets
source ip, dest ip is used, so that Analyzer VM's RPF will not have any
issues

Using the correct FMD and setting pkt_type correctly for mirrored packets

If port mirroring is enabled, cloned packet is subjected to mirroring
using the original packet's forwarding metadata. If mirroring code
changes the metadata content, original packet will be forwarded as per
the changed fmd and results in wrong forwarding.

In the current case, mirroring is to a VM in different VN (hence new VRF)
and mirroring code is modifying the fmd's dvrf to new VRF.
The original ARP packet's L2 and L3 looksups are happening on the
modified VRF resulting in ARP getting dropped.

Also the type of packet is identified using vr_pkt_type() after packet
is mirrored. This is resulting in wrong pkt_type being used for mirrored
packet hence the source IP packet the mirrored packet is not correctly
computed.

As a fix, new FMD is used for mirrored packet and packet type is
identified before mirroring itself.

closes-bug: #1549727
closes-bug: #1550312

Change-Id: If74cbbd2d80dbd9c95f674414cadc86ba43b3782