Hello Ilya,
No problem. But I am still facing issues here.
After I have decapsulated the packet, if it is addressed towards another UE, I
want to encapsulate it back with another correct GTP header, without routing
the packet first out of the OvS and then back in.
When I try to do that, OvS is crashing and I don't have any core dumps to
analyse.
It reaches "compose_output_action__" and the destination (192.168.177.101) is
recognized. The is_native_tunnel flag is set. But afterwards, the DP crashes.
The inner packet is sent from 192.168.10.15 -> 192.168.10.2
It is encapsulated in GTP Header src: 192.168.177.100 , dst:192.168.177.68.
According to the flows, I want to encapsulate it back with src:192.168.177.68 &
dst : 192.168.177.101, to match the last flow rule.
This was no problem with the kernel patch. Is this also possible with the
userplane gtp implementation?
# ovs-ofctl dump-flows dp2
cookie=0x1234, duration=27.474s, table=0, n_packets=3, n_bytes=180,
priority=1250,ip,in_port=eth1 actions=output:ethvlan1000
cookie=0x1234, duration=27.474s, table=0, n_packets=7, n_bytes=682,
priority=1250,ipv6,in_port=eth1 actions=output:ethvlan1000
cookie=0x1234, duration=27.514s, table=0, n_packets=0, n_bytes=0,
priority=1100,dl_src=99:99:99:99:99:99 actions=controller(max_len=5000,id=1)
cookie=0x1234, duration=24.482s, table=0, n_packets=0, n_bytes=0,
priority=1100,ip,nw_dst=192.168.177.100 actions=output:eth1
cookie=0x1234, duration=24.481s, table=0, n_packets=0, n_bytes=0,
priority=1100,ip,nw_dst=192.168.177.101 actions=output:eth1
cookie=0x1234, duration=24.424s, table=0, n_packets=0, n_bytes=0,
priority=1100,ip,nw_dst=192.168.10.1
actions=load:0x55667701->NXM_NX_TUN_ID[],load:0xc0a8b164->NXM_NX_TUN_IPV4_DST[],output:gtpu8
cookie=0x1234, duration=24.423s, table=0, n_packets=0, n_bytes=0,
priority=1100,ip,nw_dst=192.168.10.2
actions=load:0x55667702->NXM_NX_TUN_ID[],load:0xc0a8b165->NXM_NX_TUN_IPV4_DST[],output:gtpu9
root@RiduxV4:~/Development/OVS#
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
1(gtpu9): addr:6e:58:d5:73:00:34
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
2(ethvlan1000): addr:ba:25:97:72:f0:45
config: 0
state: 0
current: 10MB-FD COPPER
speed: 10 Mbps now, 0 Mbps max
6(eth1): addr:00:50:56:a7:9f:b9
config: 0
state: 0
current: 1GB-FD COPPER AUTO_NEG
advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
supported: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
speed: 1000 Mbps now, 1000 Mbps max
7(gtpu8): addr:f2:fd:59:ce:00:45
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
LOCAL(dp2): addr:00:50:56:a7:9f:b9
config: 0
state: 0
current: 10MB-FD COPPER
speed: 10 Mbps now, 0 Mbps max
root@RiduxV4:~/Development/OVS# ovs-vsctl show
3271f3b8-4aa6-40a2-af9b-37353238b104
Bridge dp2
Controller "tcp:127.0.0.1:6653"
is_connected: true
datapath_type: netdev
Port eth1
Interface eth1
type: system
Port gtpu8
Interface gtpu8
type: gtpu
options: {dst_port="2152", key="0x08",
remote_ip="192.168.177.100"}
Port ethvlan1000
Interface ethvlan1000
type: internal
Port dp2
Interface dp2
type: internal
Port gtpu9
Interface gtpu9
type: gtpu
options: {dst_port="2152", key="0x09",
remote_ip="192.168.177.101"}
ovs_version: "2.14.0-gtp1.5.7"
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: Montag, 28. März 2022 13:52
An: Dincer Beken <[email protected]>
Cc: [email protected] <[email protected]>
Betreff: Re: AW: [EXTERNAL] Re: [ovs-dev] OVS GTP-U Tunnel Termination
On 3/26/22 00:41, Dincer Beken wrote:
> 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.
There is a fix for GTP-U/Geneve opts, but it's currently released
only in v2.17.0, will be part of the future v2.14.5 release.
Forgot to mention that, sorry.
>
> 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!
Good to know that it worked!
>
> Thank you again,
> Dincer
>
>
>
>
>
> *Dincer Beken*
> Software Developer
>
> t: +49 8331 99 59-852 <tel:+49 8331 99 59-852>
>
> e: [email protected] <mailto:[email protected]>
> w: https://blackned.de <https://blackned.de>
>
>
>
>
> <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/
> <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
