On 12 July 2017 at 17:45, Jiannan Ouyang <ouya...@fb.com> wrote: > This patch series depends on the Linux net-next patch set > [PATCH net-next] Flow Based GTP Tunneling > > With flow based GTP tunneling supported in the upstream datapath, we can > create a gtp vport associated with a flow based GTP net_device. This > allows us to program GTP tunnels via ovs-vsctl. > > Example: > > ovs-vsctl add-port br0 gtp-vport -- set interface gtp-vport \ > ofport_request=2 type=gtp option:remote_ip=flow options:key=flow > > ovs-ofctl add-flow br0 > "in_port=2,tun_src=192.168.60.141,tun_id=123, \ > actions=set_field:02:00:00:00:00:00->eth_src, \ > set_field:ff:ff:ff:ff:ff:ff->eth_dst,LOCAL" > > ovs-ofctl add-flow br0 \ > "in_port=LOCAL,actions=set_tunnel:888, \ > set_field:192.168.60.141->tun_dst,2" > > arp -s 10.1.1.122 02:00:00:00:00:00
It's neat to see new tunnel implementations being introduced, and also quite cool that it doesn't require significant code changes to OVS to make this happen. Thanks for looking into this :-) I mentioned on the netdev thread that we should work towards using the rtnetlink interface for using the latest kernel devices, eventually everything should switch over to that configuration path. Do you expect that users will upgrade to the latest kernel to get GTP support? This is certainly the easier method from a development/support perspective. If this is the case, then I don't think we should need many (if any?) changes to the datapath/ directory in OVS. In this case patch #1 could be replaced with a little bit of extra code that pipes the device configuration through lib/dpif-netlink-rtnl.[ch]. I have a broad question with this overall model - Does it assume that the OpenFlow controller is responsible for handling the GTP-C traffic? Then it just programs OVS to match on that GTP-C traffic and forward to the controller? Subsequently, whatever PDP contexts and so on that the controller's GTP-C implementation needs to create, it just sets up equivalent flows for this purpose? _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
