vRouter drops ARP request which destination MAC is set Unicast

[Daisuke Nakajima]

10.0.0.3 sent ARP request but it didn't receive any ARP reply for that.
After that, 10.0.0.3 sent ARP request (No34) which destination is set as Broadcast (ff.ff.ff.ff.ff.ff), the ARP packet reached to 10.0.0.4.
10.0.0.4 sent ARP reply then 10.0.0.3 received its ARP reply.
It seems Unicast ARP packet is dropped at vRouter.

I confirmed ARP unicast requests from VM1 to VM2 at physical-interface of vm2 compute node. (vm2_bond0.pcap No42,45,48) However, vm2 didn't receive them. As you said before, Unicast ARP is dropping at vRouter of receiver.
It seems https://bugs.launchpad.net/juniperopenstack/+bug/1550632.

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

commit 72e76497e3e5a20fb46a6538c8a4771a4c663e0e
Author: Divakar <email address hidden>
Date: Thu Apr 14 14:34:33 2016 +0530

Treat ARP requestsas VM's requests if VRF is different when compared to VIF's VRF

This issue is valid only for unicast ARP request packets. As multicast ARP
request packets are always handled in Multicast Composite nexthop and as
they are never subjected to GRO, this issue is not observed for
multicast ARP packets.
When an unicast ARP request is received on Fabric interface it is treated as ARP
reqest for VM if there is a label attached to it. Due to the changes in
GRO, post GRO, the label is not going to be present in fmd. So ARP
packets are treated as if they are meant for fabric network. This is
resulting in unicast ARP requests never being answered.

As a fix, if the VRF of fmd is different from VIF's VRF, these packets
are treated as VM's ARP packets.

Change-Id: I013b83c38642697c81e32460be936154e42a067e
closes-bug: #1570180

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

commit d5c774a7f702ee796e17e04a14664f4ce062171a
Author: Divakar <email address hidden>
Date: Thu Apr 14 14:34:33 2016 +0530

Treat ARP requestsas VM's requests if VRF is different when compared to VIF's VRF

This issue is valid only for unicast ARP request packets. As multicast ARP
request packets are always handled in Multicast Composite nexthop and as
they are never subjected to GRO, this issue is not observed for
multicast ARP packets.
When an unicast ARP request is received on Fabric interface it is treated as ARP
reqest for VM if there is a label attached to it. Due to the changes in
GRO, post GRO, the label is not going to be present in fmd. So ARP
packets are treated as if they are meant for fabric network. This is
resulting in unicast ARP requests never being answered.

As a fix, if the VRF of fmd is different from VIF's VRF, these packets
are treated as VM's ARP packets.

Change-Id: I013b83c38642697c81e32460be936154e42a067e
closes-bug: #1570180

[OpenContrail Admin (ci-admin-f)]

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

commit 67cdf45909b8415dd58a797e24719794f602b2ec
Author: Divakar <email address hidden>
Date: Thu Apr 14 14:34:33 2016 +0530

Treat ARP requestsas VM's requests if VRF is different when compared to VIF's VRF

This issue is valid only for unicast ARP request packets. As multicast ARP
request packets are always handled in Multicast Composite nexthop and as
they are never subjected to GRO, this issue is not observed for
multicast ARP packets.
When an unicast ARP request is received on Fabric interface it is treated as ARP
reqest for VM if there is a label attached to it. Due to the changes in
GRO, post GRO, the label is not going to be present in fmd. So ARP
packets are treated as if they are meant for fabric network. This is
resulting in unicast ARP requests never being answered.

As a fix, if the VRF of fmd is different from VIF's VRF, these packets
are treated as VM's ARP packets.

Change-Id: I013b83c38642697c81e32460be936154e42a067e
closes-bug: #1570180

[OpenContrail Admin (ci-admin-f)]

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

commit e111a45c802cf81227638cbd9a8ddda07dc4437e
Author: Divakar <email address hidden>
Date: Thu Apr 14 14:34:33 2016 +0530

Treat ARP requestsas VM's requests if VRF is different when compared to VIF's VRF

This issue is valid only for unicast ARP request packets. As multicast ARP
request packets are always handled in Multicast Composite nexthop and as
they are never subjected to GRO, this issue is not observed for
multicast ARP packets.
When an unicast ARP request is received on Fabric interface it is treated as ARP
reqest for VM if there is a label attached to it. Due to the changes in
GRO, post GRO, the label is not going to be present in fmd. So ARP
packets are treated as if they are meant for fabric network. This is
resulting in unicast ARP requests never being answered.

As a fix, if the VRF of fmd is different from VIF's VRF, these packets
are treated as VM's ARP packets.

Change-Id: I013b83c38642697c81e32460be936154e42a067e
closes-bug: #1570180

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/19516
Committed: http://github.org/Juniper/contrail-vrouter/commit/57f47cc1ada0b474ddaa28d1478dba59a9ad1f2f
Submitter: Zuul
Branch: master

commit 57f47cc1ada0b474ddaa28d1478dba59a9ad1f2f
Author: Divakar <email address hidden>
Date: Thu Apr 14 14:34:33 2016 +0530

Treat ARP requestsas VM's requests if VRF is different when compared to VIF's VRF

This issue is valid only for unicast ARP request packets. As multicast ARP
request packets are always handled in Multicast Composite nexthop and as
they are never subjected to GRO, this issue is not observed for
multicast ARP packets.
When an unicast ARP request is received on Fabric interface it is treated as ARP
reqest for VM if there is a label attached to it. Due to the changes in
GRO, post GRO, the label is not going to be present in fmd. So ARP
packets are treated as if they are meant for fabric network. This is
resulting in unicast ARP requests never being answered.

As a fix, if the VRF of fmd is different from VIF's VRF, these packets
are treated as VM's ARP packets.

Change-Id: I013b83c38642697c81e32460be936154e42a067e
closes-bug: #1570180