On 07/23/2018 11:33 AM, Anil Venkata wrote:
On Mon, Jul 23, 2018 at 6:30 PM, Mark Michelson <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
<https://mail.openvswitch.org/mailman/listinfo/ovs-discuss>
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
