Please ignore this. There clearly is a bug.
On Fri, Jul 24, 2015 at 12:02 PM, Gurucharan Shetty <[email protected]> wrote: > In table 64, when a vlan tag is set on a packet > destined to a container running inside a VM, we currently > don't revert it. This has an unintended consequence for > broadcast traffic when one endpoint of the braodcast > traffic is a plain VM (without containers running inside) where > the previously set tag would remain in the packets sent to the VM. > > This commit fixes the above problem by popping the VLAN > and resetting the input port after outputting the packet > with a vlan tag to a container logical port. > > Signed-off-by: Gurucharan Shetty <[email protected]> > --- > ovn/controller/physical.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c > index 9e7f2f4..8a63ee9 100644 > --- a/ovn/controller/physical.c > +++ b/ovn/controller/physical.c > @@ -241,6 +241,19 @@ physical_run(struct controller_ctx *ctx) > sf->mask.be16 = OVS_BE16_MAX; > } > ofpact_put_OUTPUT(&ofpacts)->port = ofport; > + if (tag) { > + /* Revert the tag added to the packets headed to containers > + * in the previous step. If we don't do this, the packets > + * that are to be broadcasted to a VM in the same logical > + * switch will also contain the tag. Also revert the zero'd > + * in_port. */ > + ofpact_put_STRIP_VLAN(&ofpacts); > + > + struct ofpact_set_field *sf = ofpact_put_SET_FIELD(&ofpacts); > + sf->field = mf_from_id(MFF_IN_PORT); > + sf->value.be16 = htons(ofport); > + sf->mask.be16 = OVS_BE16_MAX; > + } > ofctrl_add_flow(64, 50, &match, &ofpacts); > } > > -- > 1.7.9.5 > _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
