Juniper Openstack

  1. Series trunk
  2. Bug #1461882
  3. Comment #52

Comment 52 for bug 1461882

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

Reviewed: https://review.opencontrail.org/26145
Committed: http://github.org/Juniper/contrail-vrouter/commit/5bdd3992309ef8cf138fff1b5af8332849a7959f
Submitter: Zuul
Branch: R3.0.2.x

commit 5bdd3992309ef8cf138fff1b5af8332849a7959f
Author: Divakar D <email address hidden>
Date: Sat Oct 8 19:25:38 2016 +0530

Transmit V6 Neighbour advertisement on the receiving interface

This fix is IPV6 equivalent of
https://review.opencontrail.org/#/c/11506/.

In in-network service instance case, when service scaling
is more than one, all the instances are going to have the
same mac address and IP address. Inet route points to
ECMP composite nexthop but FDB route does not point to ECMP
nexthop. So when neighbour request is received from service VM
Vrouter needs to send response on the incoming interface
rather bridging the reply packet, as FDB route points
to arbitrarly any of the service VM encap L2 nexthop.

After preparing the reply packet,bridge lookup is done
and outgoing interface is compared against ingress interface.
If they are not same, reply packet is transmitted on
ingress interface.

Change-Id: Ib0113227019d7a452541129843813a647d388b36
closes-bug: #1461882

Disable the flow processing for Neighbour Advertisements

The neighbour request packets are typically Multicast packets and there
is no flow processing for these. When a neighbour request is converted
to neighbour advertisement, we continue to use the same packet buffer
and same packet flags for this advertisement too. This ends up in not
creating a flow for neighbour advertisement too as the original packet
is marked as multicast packet. But the fix we gave
https://review.opencontrail.org/#/c/24973/ for bug: #1461882 for V6
resulted in creating new packet flags for advertisement and this is
resulting in flow being created. The flow processing is dropping the
response as the neighbour advertisement should have ideally come from
different interface.

We can fix this issue either by manipulating the source interface to
match the interface on which neighbour is falling so that flow
processing succeeds or by disabling the flow processing for
advertisements.

The fix now disables the flow processing for advertisements

Change-Id: Ic91f0fb794c13912e43d8c96c726bd80e559b7fb
closes-bug: #1635931