[ovs-discuss] 答复: ovs dpdk layer 3 port with neighbour protocol stack support
majieyue at huawei.com
Tue Nov 29 06:25:29 UTC 2016
Well, I am afraid I don't need VPN things. It is just a simple scenario in this requirement.
发件人: aenertia at aenertia.net [mailto:aenertia at aenertia.net] 代表 Joel Wirāmu Pauling
发送时间: 2016年11月29日 14:21
收件人: majieyue <majieyue at huawei.com>
抄送: ovs-discuss at openvswitch.org
主题: Re: [ovs-discuss] ovs dpdk layer 3 port with neighbour protocol stack support
This is what EVPN is for.
On 28 November 2016 at 22:16, majieyue <majieyue at huawei.com> wrote:
When we deploy OVS as NAT node, I am afraid only flow rules is not enough if you don't know the next hop mac address, e.g.
VM (192.168.1.1 -> 10.1.1.10) => OVS (192.168.1.1 snat to 10.1.1.1) => Server (10.1.1.1 -> 10.1.1.10)
In most situations, admin can't know (and should not know) the mac address of 10.1.1.10, and switches in traditional way always
learn this info by sending ARP request. But in OVS, I don't know if there is another way except for inserting a flow rule that has mac
addresses of 10.1.1.1 and 10.1.1.10 and using such actions as mod_dl_src and mod_dl_dst
What I am asking for is adding a layer 3 port, which has some ability similar with current tunnel port, and such layer 3 port can query
route cache which OVS maintained for tunnel, and neigh tables, w/o asking for kernel (especially it runs in DPDK context). Such layer 3 port
is not tunnel port so its behavior only relies on forwarding and modifying l2 headers
I've searched previous mails and there is indeed some work on layer 3 port, but such port doesn't have all I asked above. I am wondering if there
is a plan on this in future OVS roadmap, What you maintainer guys think about the requirement I proposed.
I am yearning for your advices, and maybe I can contribute to such things if you think it is worth of doing. Correct me if anything wrong, thank you.
discuss mailing list
discuss at openvswitch.org
More information about the discuss