On 3/25/22 16:42, Dincer Beken wrote: > [email protected] > > > Hello all, > > I am using OVS 2.14 with the netdev datapath. I was using the older GTP > Kernel Path (inofficial) and now would like to move to Userspace, using the > original patch. > > I have an ETH1 Interface, directly connected to the OVS, and also defined the > OVS-GTPU Interface as in > > "ovs-vsctl add-port dp2 gtpu8 -- set Interface gtpu8 type=gtpu > options:remote_ip=192.168.177.100 options:dst_port=2152" > > I have added an IP address to the Bridge and also the the ETH Interface > (192.168.177.68, as a termination), but neither solved my problem. > > From the code, I see that the "gtp" interface has to be recognized as the > termination interface, in order to add the OVS_ACTION_ATTR_TUNNEL_POP action, > into the action stack. > > I have not created any specific flows for GTP encapsulation. When I create a > flow which matches to the GTPU port, no packets are matched, so I match > against the ETH1 port. > > I did get encapsulation working, but I cannot get decapsulation working. I am > sending a GTP Packet with the dst port to 2152 and and the source_ip is what > I configure as remote_ip, so 192.168.177.100, in this case. > > I am getting very confused here and cannot get forward, I am about to add a > tnl_pop action in OpenFlow to handle this issue. > > Could you please help me to solve this tunnel termination issue?
Hi, Dincer. Did you try following the instructions from this guide: https://docs.openvswitch.org/en/latest/howto/userspace-tunneling/ ? In general, setting up GTP-U tunnel should not be different from setting up any other type of a tunnel. So, you may try setting up VXLAN first and convert it to GTP-U later, when you're sure that setup is working fine. Note: the guide I linked above seems to be not fully correct, as you'll need an IP address on br-int bridge too. In case of that guide the actual IP doesn't matter much, but it should be from the same subnet in which VM is, e.g. 192.168.1.10/24. You need an interface with IP address in the inner packet's subnet for routing to work correctly after decapsulation. Tunnel termination on non-bridge port may work, so technically you may not need two distinct bridges after all, but that is a conventional way to setup tunneling. And in any case, there still should be one interface with the physical network IP and one with the tunnel network IP, otherwise routing will not work. Dumping datapath flows with 'ovs-appctl dpctl/dump-flow' or using 'ovs-appctl ofproto/trace' might be a good debugging option. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
