Re: [ovs-dev] 答复: Re: 答复: Re: 答复: [spam可疑邮件]Re: 答复: Re: [PATCH 2/2] ovn-northd: Fix ping failure of vlan networks.

[Russell Bryant]

On Thu, Jul 6, 2017 at 2:15 PM, Han Zhou  wrote:
> Despite the original motivation of this change, I found the patch valuable
> for data-plane performance.
>
> When localnet port is used for communication between 2 ports of same
> lswitch (basic provider network scenario), without the patch, each flow is
> tracked in conntrack table twice. With the patch, it improve the
> performance in 2 ways:
>
> 1) It reduces 50% of conntrack operations
>
> 2) It reduces 50% number of entries in conntrack table, which also helps
> reducing conntrack cost
>
> I had some tests for TCP_CRR, it improves performance for 5 - 10%.
> Discussed in today's ovn meeting and we agreed it is valid optimization
> because localnet port is used as transport, not the real end-point to
> protect.
>
> @Qianyu, would it be good to revise the patch on the commit message to put
> it as an optimization for conntrack performance? The current commit message
> is not true because it is not a supported scenario for now, and the "fix"
> is not complete, either. The new scenaro would worth a separate discussion.
> What do you think?

While the localnet port is not an endpoint, it did seem useful to me
to be able to define security policy there as that is the first place
traffic enters from "outside" of OVN.  We could potentially drop
traffic sooner, before sending it over to the final endpoint on
another chassis.  Based on a quick review of the discussion, it does
seem like dropping it is the better choice for now.

If the security aspect is desired later, perhaps we could solve it
another way by supporting ACLs associated with the L3 gateway sitting
between an OVN logical network and a physical network (localnet
network).

-- 
Russell Bryant
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] 答复: Re: 答复: Re: 答复: [spam可疑邮件]Re: 答复: Re: [PATCH 2/2] ovn-northd: Fix ping failure of vlan networks.

[Han Zhou]

Despite the original motivation of this change, I found the patch valuable
for data-plane performance.

When localnet port is used for communication between 2 ports of same
lswitch (basic provider network scenario), without the patch, each flow is
tracked in conntrack table twice. With the patch, it improve the
performance in 2 ways:

1) It reduces 50% of conntrack operations

2) It reduces 50% number of entries in conntrack table, which also helps
reducing conntrack cost

I had some tests for TCP_CRR, it improves performance for 5 - 10%.
Discussed in today's ovn meeting and we agreed it is valid optimization
because localnet port is used as transport, not the real end-point to
protect.

@Qianyu, would it be good to revise the patch on the commit message to put
it as an optimization for conntrack performance? The current commit message
is not true because it is not a supported scenario for now, and the "fix"
is not complete, either. The new scenaro would worth a separate discussion.
What do you think?

On Wed, Jul 5, 2017 at 9:07 PM, Mickey Spiegel <mickeys@gmail.com>
wrote:

>
> On Tue, Jul 4, 2017 at 6:01 PM, <wang.qia...@zte.com.cn> wrote:
>
>> Hi Mickey,
>>
>> Thanks for your review.
>>
>> If we could do some modifications to avoid the north/south problem you
>> mentioned? Like as follow:
>>
>> When packets send to the localnet-port, if the MAC is router-port MAC, we
>> change the router-port MAC to HV physical NIC MAC. And in gateway node, we
>> make the HV physical NIC MAC and router-port MAC all sense.
>
>
> In OpenStack usage, for public internet access, it is common for one
> logical switch to have many different logical routers connected to it,
> which can reside on the same hypervisor. The MAC address is used to
> identify which logical router the traffic is destined to. So you would need
> a MAC address per (logical router, chassis) pair, or you would have to
> introduce yet another type of router that front ends the distributed
> logical routers, deciding based on destination IP address. Either way, a
> port with a different MAC address on each chassis that hosts the port seems
> different than the logical router ports that exist today.
>
> I am still trying to understand your use case. It sounds like you have
> different regions, with different logical switches in different regions. If
> you just put localnets on each of those logical switches, wouldn't that do
> what you want?
>
> If you need L3 between the different regions, you could use a separate
> router per region, either a gateway router in each region, or a distributed
> logical router with a distributed gateway port in each region. With gateway
> routers, traffic coming in and out of each region goes through one
> centralized chassis. With a distributed logical router, non-NAT traffic
> coming in and out of each region goes through one centralized chassis,
> while NAT traffic coming in and out of each region can be distributed. With
> this type of solution, traffic will go in and out of each localnet
> symmetrically, in both directions.
>
> Mickey
>
>
>>
>> Thanks!
>>
>>
>>
>>
>> *Mickey Spiegel <mickeys@gmail.com <mickeys@gmail.com>>*
>>
>> 2017/06/30 12:31
>>
>>     收件人：        Han Zhou <zhou...@gmail.com>,
>> 抄送：wang.qia...@zte.com.cn, ovs dev <d...@openvswitch.org>,
>> zhou.huij...@zte.com.cn, xurong00037997 <xu.r...@zte.com.cn>
>> 主题：Re: [ovs-dev] 答复: Re: 答复: [spam可疑邮件]Re: 答复: Re: [PATCH
>> 2/2] ovn-northd: Fix ping failure of vlan networks.
>>
>>
>>
>>
>> On Thu, Jun 29, 2017 at 2:19 PM, Han Zhou <*zhou...@gmail.com*
>> <zhou...@gmail.com>> wrote:
>> I learned that this use case is kind of Hierarchical scenario:
>>
>> *https://specs.openstack.org/openstack/neutron-specs/specs/kilo/ml2-hierarchical-port-binding.html*
>> <https://specs.openstack.org/openstack/neutron-specs/specs/kilo/ml2-hierarchical-port-binding.html>
>>
>> In such scenario, user wants to use OVN to manage vlan networks, and the
>> vlan networks is connected via VTEP overlay, which is not managed by OVN
>> itself. VTEP is needed to connect to BM/SRIOV VMs to the same L2 that OVS
>> VIFs are connected to.
>>
>> User don't want to use OVN to manage VTEPs since there will be flooding to
>> many VTEPs. (Mac-learning is not supported yet)
>>
>> So in this scenario, user want to utilize distributed logical router as a
>> way to optimize the datapath. For VM to VM traffic between different
>> vlans,
>> instead of going to a centralized external L3 router, user wants the
&

[ovs-dev] 答复: Re: 答复: Re: 答复: [spam可疑邮件]Re: 答复: Re: [PATCH 2/2] ovn-northd: Fix ping failure of vlan networks.

[wang . qianyu]

Hi Mickey,

Thanks for your review.

If we could do some modifications to avoid the north/south problem you 
mentioned? Like as follow:

When packets send to the localnet-port, if the MAC is router-port MAC, we 
change the router-port MAC to HV physical NIC MAC. And in gateway node, we 
make the HV physical NIC MAC and router-port MAC all sense. 

Thanks!






Mickey Spiegel <mickeys@gmail.com>
2017/06/30 12:31
 
收件人：Han Zhou <zhou...@gmail.com>, 
抄送：  wang.qia...@zte.com.cn, ovs dev <d...@openvswitch.org>, 
zhou.huij...@zte.com.cn, xurong00037997 <xu.r...@zte.com.cn>
        主题：  Re: [ovs-dev] 答复: Re: 答复: [spam可疑邮件]Re: 答复: Re: 
[PATCH 2/2] ovn-northd: Fix ping failure of vlan networks.



On Thu, Jun 29, 2017 at 2:19 PM, Han Zhou <zhou...@gmail.com> wrote:
I learned that this use case is kind of Hierarchical scenario:
https://specs.openstack.org/openstack/neutron-specs/specs/kilo/ml2-hierarchical-port-binding.html


In such scenario, user wants to use OVN to manage vlan networks, and the
vlan networks is connected via VTEP overlay, which is not managed by OVN
itself. VTEP is needed to connect to BM/SRIOV VMs to the same L2 that OVS
VIFs are connected to.

User don't want to use OVN to manage VTEPs since there will be flooding to
many VTEPs. (Mac-learning is not supported yet)

So in this scenario, user want to utilize distributed logical router as a
way to optimize the datapath. For VM to VM traffic between different 
vlans,
instead of going to a centralized external L3 router, user wants the
traffic to be tagged to the destination vlan directly and go straight from
source HV to destination HV through the destination vlan.

L2 and L3 have different semantics and different ways of handling packets.
There is a big difference between:
1) bridging between different VLANs, going through a VTEP overlay
   that connects those VLANs, and
2) routing between different VLANs.
Trying to blur that boundary will lead to unexpected behavior and various
issues.

In the vtep scenario, this is a valuable optimization. Even in a normal
vlan setup without vtep, this can be an optimization too if src and dst 
VMs
are on the same HV (so that the packet doesn't need to go to physical
switch and come back).

So, I agree with Qianyu that connecting VLAN networks with logical router
is reasonable, which means, the transport of logical router can be not 
only
tunnels, but also physical networks (localnet port).

Mixing routers and localnet is dangerous because of interactions with
MAC addresses and L2 learning. The reason it is not a good idea to
transmit packets from a distributed logical router directly to a physical
network through localnet is because the router rewrites the source MAC
to the router MAC. The physical network will learn about the router MAC
based on the last location from which it saw the router send a packet to
the physical network. That may have low correlation with the next
packet from the physical network back to the router MAC, so north/south
packets may end up with an almost random distribution of chassis on
which the distributed logical router resides, independent of where the
destination actually resides.

You are looking only at east west traffic, counting on the asymmetry using
the distributed router instance on the other side so that return traffic
never hits the physical network with the router MAC as the destination
MAC. However, there will be north/south traffic destined to the router
MAC, and this approach will make that bounce all over the place.

Perhaps you can make something work if you have per node per router
MAC addresses, but it still scares me.

To fulfill this
requirement, we need to solve some problems in current OVN code:

1) Since the data path is asymmetric, we need to solve the CT problem of
the localnet port. I agree with the idea of the patch from Qianyu, which
bypasses FW for localnet ports, since localnet port is to connect real
endpoints, so maybe there is not much value to add ACL on localnet ports.
Not sure if there is use case where ACL is really needed for localnet 
ports.

2) When there are ARP requests from vlan network (e.g. from a BM) to
logical router interface IP, the ARP request will reach every HV through
the localnet port and the distributed logical router port will respond 
from
every HV. Shall we disable ARP response from logical router for requests
from localnet port? In this scenario, I would expect the BM/SRIOV VMs on
the same vlan to use a different GW rather than the logical router.

How will north/south traffic work?

Distributed gateway ports limit ARP responses so that only one instance
of the distributed gateway port on one chassis responds.

At the moment distributed gateway ports only allow direct traffic (without
going through the central node) for 1:1 NAT with logical_port and
external_mac specified. This is because of the implications of upstream
L2 learning, and lack of a routing pro