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

[Mark Michelson]

On 07/23/2018 11:33 AM, Anil Venkata wrote:
> 
> 
> On Mon, Jul 23, 2018 at 6:30 PM, Mark Michelson <mmichels at redhat.com 
> <mailto: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
>         <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?

I think I'm missing some information because I don't understand the 
question about ACLs. ACLs are user-defined, and so you can choose which 
ports have ACLs on them.

> 
>     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 
> togateway 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) ?

I think this comes down to what I was stating earlier about the unknown 
nature of localnet ports. OVN can't make the assumption about the 
network. Perhaps if there were some way to indicate that the packet will 
be re-entering br-int on a remote hypervisor, then we could send the 
packet out in table 32 instead? I'm not sure about the implications of 
that though.

> 
> [1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-July/349803.html 
> <https://mail.openvswitch.org/pipermail/ovs-dev/2018-July/349803.html>
> [2] https://patchwork.ozlabs.org/patch/934524/ 
> <https://patchwork.ozlabs.org/patch/934524/>
> 
> 
>         Thanks
>         Anil
> 
> 
> 
> 
>         _______________________________________________
>         discuss mailing list
>         discuss at openvswitch.org <mailto:discuss at openvswitch.org>
>         https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>         <https://mail.openvswitch.org/mailman/listinfo/ovs-discuss>
> 
> 
>