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.
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
Reviewed: https:/ /review. opencontrail. org/26145 github. org/Juniper/ contrail- vrouter/ commit/ 5bdd3992309ef8c f138fff1b5af833 2849a7959f
Committed: http://
Submitter: Zuul
Branch: R3.0.2.x
commit 5bdd3992309ef8c f138fff1b5af833 2849a7959f
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 /review. opencontrail. org/#/c/ 11506/.
https:/
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: Ib0113227019d7a 452541129843813 a647d388b36
closes-bug: #1461882
Disable the flow processing for Neighbour Advertisements
The neighbour request packets are typically Multicast packets and there /review. opencontrail. org/#/c/ 24973/ for bug: #1461882 for V6
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:/
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: Ic91f0fb794c139 12e43d8c96c726b d80e559b7fb
closes-bug: #1635931