Skip to content

Commit

Permalink
Disable the flow processing for Neighbour Advertisements
Browse files Browse the repository at this point in the history
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
  • Loading branch information
divakardhar committed Oct 24, 2016
1 parent 4bba1f1 commit dc00a57
Showing 1 changed file with 3 additions and 0 deletions.
3 changes: 3 additions & 0 deletions dp-core/vr_datapath.c
Expand Up @@ -434,6 +434,9 @@ vr_mac_reply_send(struct vr_packet *pkt, struct vr_forwarding_md *fmd)
fmd_new.fmd_dvrf = fmd->fmd_dvrf;
vr_pkt_type(pkt, 0, &fmd_new);

/* Disable the flow processing for response packets */
pkt->vp_flags |= VP_FLAG_FLOW_SET;

/*
* XXX: for vcp ports, there won't be bridge table entries. to avoid
* doing vr_bridge_input, we check for the flag NO_ARP_PROXY and
Expand Down

0 comments on commit dc00a57

Please sign in to comment.