vRouter : Ping between two application VM's using L2 ntwk is failing.

[kapil Neeralgi]

We have enabled L2 forwarding mode and flood_unknown_unicast .

The arp send packets are reaching the destination VM , Arp reply packets which are unicast to source are getting dropped by vRouter.

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

commit f5b35d2d59b436e84fb9411cbc6954e6397381d9
Author: Divakar <email address hidden>
Date: Fri Nov 13 19:45:28 2015 +0530

Not processing unknown unicast ARP reply packets

Currently, an ARP reply, which is an unicast packet is attempted to be
flooded in Multicast tree, if it is an unknown unicast. But as part of
L2 multicast nexthop processing, this ARP packet is processed as if this
has come from VM to Vrouter and trapped to Agent.

As a fix, an ARP reply is never processed in Vrouter, unless it is
destined to Vrouter's MAC or Vhosts mac. This is identified using
fmd_to_me in forwarding metadata.

Change-Id: I67613ab8ed21a6661bc7131ef0f9fcccca3b17c5
closes-bug: #1516026
closes-bug: #1514703

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/16105
Committed: http://github.org/Juniper/contrail-vrouter/commit/5a9e3b4f151602dea8d1d97dc1ceae4aa291ab67
Submitter: Zuul
Branch: master

commit 5a9e3b4f151602dea8d1d97dc1ceae4aa291ab67
Author: Divakar <email address hidden>
Date: Fri Nov 13 19:45:28 2015 +0530

Not processing unknown unicast ARP reply packets

Currently, an ARP reply, which is an unicast packet is attempted to be
flooded in Multicast tree, if it is an unknown unicast. But as part of
L2 multicast nexthop processing, this ARP packet is processed as if this
has come from VM to Vrouter and trapped to Agent.

As a fix, an ARP reply is never processed in Vrouter, unless it is
destined to Vrouter's MAC or Vhosts mac. This is identified using
fmd_to_me in forwarding metadata.

Change-Id: I67613ab8ed21a6661bc7131ef0f9fcccca3b17c5
closes-bug: #1516026
closes-bug: #1514703

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

commit 4a635e41737a14dba4cf191d50e338ffa8e01bc3
Author: Divakar <email address hidden>
Date: Fri Nov 13 19:45:28 2015 +0530

Not processing unknown unicast ARP reply packets

Currently, an ARP reply, which is an unicast packet is attempted to be
flooded in Multicast tree, if it is an unknown unicast. But as part of
L2 multicast nexthop processing, this ARP packet is processed as if this
has come from VM to Vrouter and trapped to Agent.

As a fix, an ARP reply is never processed in Vrouter, unless it is
destined to Vrouter's MAC or Vhosts mac. This is identified using
fmd_to_me in forwarding metadata.

Change-Id: I67613ab8ed21a6661bc7131ef0f9fcccca3b17c5
closes-bug: #1516026
closes-bug: #1514703

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