[ovs-discuss] OVN - VLAN packet duplicate processing on egress pipeline

[Anil Venkata]

On Mon, Jul 23, 2018 at 6:30 PM, Mark Michelson <mmichels at redhat.com> wrote:

> On 07/23/2018 08:03 AM, Anil Venkata wrote:
>
>> Packets destined for VLAN remote logical ports are sent out through
>> physical table 65 rather than physical table 32 (Geneve remote logical
>> ports are sent through table 32). I found below description in ovn
>> architecture documentation.
>>
>> http://www.openvswitch.org//support/dist-docs/ovn-architecture.7.html
>>
>> A  special  case  is  that  when a localnet port exists on the
>> datapath, remote port is connected by switching to the  local‐
>> net  port.  In this case, instead of adding a flow in table 32
>> to reach the remote port, a flow  is  added  in  table  33  to
>> switch  the logical outport to the localnet port, and resubmit
>> to table 33 as if it were unicasted to a logical port  on  the
>> local hypervisor.
>>
>>
>> Any reason for this decision. Because of this, packet is redundantly
>> processed in logical switch's egress pipeline on both local and remote
>> hypervisors.
>>
>
> Keep in mind that from OVN's perspective, a localnet port represents a
> local exit from the logical switch. It doesn't know if the packet will end
> up back in br-int again on another hypervisor. It would be equally valid
> for the packet to be modified by a separate OVS switch and sent out of the
> underlay network entirely once it has gone out the localnet port.


Thanks Mark. Agree, tunnelled packet can only be decapsulated by  br-int on
remote hypervisor. But in case of VLAN packet any one can process it.
But I don't see stages (and tables) in egress pipeline checking against
this localnet port (but I can see checks for other localports). If the
remote port is not a ovs br-int port on other chassis, then why do we need
to apply ACL?

Thus if it does not go through the egress pipeline of the local hypervisor,
> there is the chance that it will not go through the egress pipeline of the
> logical switch at all.
>
> There are potential ways that we could get around this redundant
> processing. However, before suggesting anything concrete or actually
> proposing that anything actually should be done, I'll echo Russell's
> question about whether this is actually causing a noticeable problem.
>
>
Miguel found the issue 1) described in [1] while reviewing the patch [2].
As a solution we wanted to have gateway MAC address as reply packet source
MAC address when the packet is travelling from gateway node to compute node
so that external physical switches can update their FDB.
To implement this solution
1)  Router pipeline in gateway node will set packet  MAC address to gateway
MAC address and then submit to VLAN switch pipeline.
2)  VLAN switch pipeline should replace this with router internal port MAC
address before delivering to VM.
     I want to add below flow in physical table 33 local VM ports for
replacing MAC address
     table=33, priority=<higher priority> metadata=<VLAN
NETWORK>,dl_dst=<Gateway Port MAC> actions=mod_dl_dst:<Router Internal port
MAC>,resubmit(,33)

But VLAN switch pipeline can process the above generic flow for remote
port, thus packet while leaving the gateway node will have router internal
port MAC address.
As a work around I can add a new flow which checks MAC address for each
port i.e (but I prefer the above generic flow in table 33)
table=33, priority=<higher priority> metadata=<VLAN NETWORK>,dl_dst=<Gateway
Port MAC>,*outport=<internal_port>* actions=mod_dl_dst:<Router Internal
port MAC>,resubmit(,33)

Before that I wanted to understand why we are differentiating VLAN
networks( i.e processing differently in table 32 and 33) ?

[1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-July/349803.html
[2] https://patchwork.ozlabs.org/patch/934524/


>
>> Thanks
>> Anil
>>
>>
>>
>>
>> _______________________________________________
>> discuss mailing list
>> discuss at openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20180723/124463a2/attachment.html>