Hello Ilya,
Thank you very much for your response. I did not thought, that the issue would be related to routing the inner packet, before it has been decapsulated. I spent a day for this. Once, I set the routes and target right for the inner packet, I also got the proper decapsulation. I also fixed an issue with the GTP-Opts, which was somehow configured as Geneve, but I don't know if that helped. Right afterwards, after the packet has been decapsulated, it was sent back to the pipeline, as if it was a new packet, this time with an additional "flow" information as metadata. I got the receive port not found error, but could fix it, by setting remote_ip & key to "flow", so I hope I don't have to set CLI command for every new port which i need to open and can do this with openflow, as I am doing this in the kernel (with some changes in the tunnel.c file). Using the official GTP, userspace, (and in our case no additional namespace, just running the ovs as a bridge in the default namespace), is amazing. Such a relief! Thank you again, Dincer Dincer Beken Software Developer t: +49 8331 99 59-852<tel:+49%208331%2099%2059-852> e: [email protected]<mailto:[email protected]> w: https://blackned.de [cid:blackned_d1650eb0-ca34-4593-90da-c73d0e84f2cd.png] [cid:linkedin_d8fe2332-efbd-461a-923a-3153732a489e.png]<https://www.linkedin.com/company/8960382> blackned GmbH · zugspitzstraße 1 · 87751 heimertingen geschäftsführer: timo haas · hrb memmingen 17319 Diese eMail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese eMail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und löschen Sie diese eMail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser eMail ist nicht gestattet. This eMail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this eMail in error) please notify the sender immediately and delete this eMail. Any unauthorized copying, disclosure or distribution of the contents in this eMail is strictly forbidden. Von: Ilya Maximets <[email protected]> Gesendet: Freitag, 25. März 2022 17:35 An: Dincer Beken <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]> Betreff: [EXTERNAL] Re: [ovs-dev] OVS GTP-U Tunnel Termination 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
