From: <Dincer Beken> <[email protected]>
My scenario is to implement a PGW via OvS in the Userspace.
My scenario consists basicly of an OvS running in Userspace, in the Default
Namespace, really acting like a bridge, where a single ETH interface is
connected to it (type=system). Additionally, I have an "internal" interface
(ethvlan1000), which is like my SGI interface. It has a /24 address on it, from
the same subnet as the inner packets. Finally, I have a GTP port, which is only
configured with key, remote_ip and port. I did not set the legacy/ptap mode.
I am sending GTP packets (inner & outer are both IPv4) from another VM from the
ETH interface to the OvS.
I want to handle 3 cases:
1. Uplink/Traffic from an UE: GTP Packets, should be decapsulated and
forwarded from the ethvlan1000, if the destination IP is not a UE and does not
exist in OvS as a flow.
1. Downlink/Traffic towards a UE: If I ping a UE (point 1 -> the IP exists in
OvS together with encapsulation information) from the system (the packets are
routed from outside OvS via ethvlan - no special route necessary for that), the
packets should be encapsulated, and sent to the destination UE. If I want to
ping a UE, the OvS gets an ARP request for this UE, this is forwarded to the
OFC which replies with sum dummy MAC address which is not thrown off anyway.
1. GTP Recirculation/Traffic between UEs: If the destination IP is a UE, then
there exists a flow for it (where we add TUN_ID & IP & forward it to a GTP port
- from what I understand, this can be the same GTP port, from which the packet
came in. I call this case GTP recirculation. Here just consider a simplified
scenario, where the packet does not leave the SGi interface (I guess in a
proper core, there would be something like a firewall, which also checks
packets between UEs, but for the sake of simplicity, traffic between UEs are
not going out of the OvS. William described a similar scenario.
Basicly, this is all what I want to do (for 4G/5G, but first 4G).
Point 1 and 2 work. The issue is here point 3. I go bit into the difference
between point 1 and point 3 in the uplink:
In the uplink direction, after the OvS matches the packet to the GTP port, it
decapsulates the packet, leaving only the Inner IP (input port is eth1). This
packet is now recirculated and the input port is now set as the GTP port. It is
processed in Table0. There is an entry in Table0 which resubmits this to
Table1. Where its destination is checked. Here either the traffic leaves the
OvS (if the destination is not a UE) or is encapsulated back and sent to the
destination UE through the GTP tunnel of the target UE.
So how I could initiate the OVS-Assertation:
* After the UL packet has been matched to the GTP port and decapsulated
(only inner IP and inner payload exists), it is recirculated back now with some
metadata.
* Before it enters the datapath, in the output processing, it is recognized
as a L3 packet and an additional encapsulation is requested by the OvS. I
mentioned below where this happens. Until know, this is standard OvS 2.14. I
did not do any changes here. Funnily, here the packet type is set to L2.
* We enter Compose Output Action (I guess, here the problem is)
* Directly at the beginning, I guess, here we again set L3, instad of
L2, but we do not remove the pending encapsulation flag.
* /* Strip Ethernet header for legacy L3 port. */
if (flow->packet_type == htonl(PT_ETH)) {
/* Strip Ethernet header for legacy L3 port. */
if (xport->pt_mode == NETDEV_PT_LEGACY_L3) {
flow->packet_type = PACKET_TYPE_BE(OFPHTN_ETHERTYPE,
ntohs(flow->dl_type));
}
}
* if (flow->packet_type == htonl(PT_ETH)) {
* The TNL find methid is invoked and the destination will be identified
as a GTP tunnel (still standard OvS 2.14).
* Directly afterwards, the xlate_commit_actions(ctx); method is called.
* Here the crash happens, since the packet has the type L3, but the
pending encapsulation flag is still on.
Checking the pending encapsulation flag and unsetting it, if the L3 packet
(holding an L2 status with a pending encapsulation flag) is destined for a L3
output, fixes the issue.
My Configuration:
root@RiduxV4:~/Development/OVS# ovs-vsctl show
3271f3b8-4aa6-40a2-af9b-37353238b104
Bridge dp2
Controller "tcp:127.0.0.1"
datapath_type: netdev
Port gtpu8
Interface gtpu8
type: gtpu
options: {dst_port="2152", key=flow, remote_ip=flow}
Port veth1
Interface veth1
Port eth1
Interface eth1
type: system
Port dp2
Interface dp2
type: internal
Port ethvlan1000
Interface ethvlan1000
type: internal
Port gtpu9
Interface gtpu9
type: gtpu
options: {key="0x01", remote_ip="192.168.177.101"}
ovs_version: "2.14.0-gtp1.5.7"
root@RiduxV4:~/Development/OVS#
root@RiduxV4:~/Development/OVS# ovs-ofctl dump-flows -Oopenflow14 dp2
cookie=0x1234, duration=88.889s, table=0, n_packets=0, n_bytes=0,
priority=1100,ipv6,in_port=veth1
actions=controller(max_len=5000,id=1),clear_actions
cookie=0x1234, duration=88.889s, table=0, n_packets=0, n_bytes=0,
priority=1100,ip,in_port=veth1
actions=controller(max_len=5000,id=1),clear_actions
cookie=0x1234, duration=88.889s, table=0, n_packets=14, n_bytes=1269,
priority=1250,ip,in_port=eth1 actions=output:ethvlan1000
cookie=0x1234, duration=88.889s, table=0, n_packets=116, n_bytes=11268,
priority=1250,ipv6,in_port=eth1 actions=output:ethvlan1000
cookie=0x1234, duration=88.889s, table=0, n_packets=3, n_bytes=102,
priority=1400,ip,in_port=gtpu8 actions=goto_table:1
cookie=0x1234, duration=88.889s, table=0, n_packets=0, n_bytes=0,
priority=1400,ipv6,in_port=gtpu8 actions=goto_table:1
cookie=0x1234, duration=88.929s, 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),clear_actions
cookie=0x1234, duration=88.889s, table=0, n_packets=94, n_bytes=5640,
priority=1100,arp,arp_op=1 actions=controller(max_len=5000,id=1),clear_actions
cookie=0x1234, duration=85.879s, table=0, n_packets=4, n_bytes=420,
priority=1100,ip,nw_dst=192.168.177.100 actions=output:eth1
cookie=0x1234, duration=85.878s, table=0, n_packets=0, n_bytes=0,
priority=1100,ip,nw_dst=192.168.177.101 actions=output:eth1
cookie=0x1234, duration=85.878s, table=0, n_packets=0, n_bytes=0,
priority=1100,ip,nw_dst=192.168.10.10 actions=output:ethvlan1000
cookie=0x1234, duration=85.814s, table=0, n_packets=0, n_bytes=0,
priority=1100,ip,in_port=ethvlan1000,nw_dst=192.168.10.1
actions=set_field:0x55667701->tun_id,set_field:192.168.177.100->tun_dst,output:gtpu8
cookie=0x1234, duration=85.813s, table=1, n_packets=1, n_bytes=34,
priority=1100,ip,in_port=gtpu8,nw_dst=192.168.10.3
actions=set_field:0x55667701->tun_id,set_field:192.168.177.100->tun_dst,output:gtpu9
cookie=0x1234, duration=85.812s, table=1, n_packets=0, n_bytes=0,
priority=1100,ipv6,in_port=gtpu8
actions=set_field:0x55667701->tun_id,set_field:192.168.177.100->tun_dst,output:ethvlan1000
cookie=0x1234, duration=85.812s, table=1, n_packets=2, n_bytes=68,
priority=1100,ip,in_port=gtpu8
actions=set_field:0x55667701->tun_id,set_field:192.168.177.100->tun_dst,output:ethvlan1000
root@RiduxV4:~/Development/OVS#
I just ran 4 tests.
First I sent 2 GTP packets (outer from 192.168.177.100 to 192.168.177.68) to a
UE 192.168.10.6 (from some other UE in same subnet). This packet got correctly
encapsulated, and the encapsulated packet exited over ethvlan1000.
Then I sent 2 GTP packets to the UE 192.168.10.3, these also got decapsulated
and then encapsulated bak and forwarded to 192.168.3.10 (192.168.177.100) over
the correct GTP tunnel.
Signed-off-by: Dincer Beken <[email protected]>
>From 71fe60e768515ae3cb808edaae3c6d0f929f5bcb Mon Sep 17 00:00:00 2001
From: dincer <[email protected]>
Date: Wed, 30 Mar 2022 12:28:40 +0200
Subject: [PATCH] In case a packet is destinated for a L3 output, and the
pending encapsulation (L2) flag is set, unset the flag. Signed-off-by: Dincer
Beken <[email protected]>
Signed-off-by: Dincer Beken <[email protected]>
---
ofproto/ofproto-dpif-xlate.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index cc9c1c628..68192b8aa 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -4195,6 +4195,10 @@ compose_output_action__(struct xlate_ctx *ctx,
ofp_port_t ofp_port,
if (xport->pt_mode == NETDEV_PT_LEGACY_L3) {
flow->packet_type = PACKET_TYPE_BE(OFPHTN_ETHERTYPE,
ntohs(flow->dl_type));
+ if(ctx->pending_encap) {
+ /* The Ethernet header was not added yet. No L2 encapsulation
needed for L3 port. */
+ ctx->pending_encap = false;
+ }
}
}
--
2.25.1
Mit freundlichen Grüßen
Dincer Beken
E-Mail: [email protected]<mailto:[email protected]>
Tel.: +49 8331 9959-852
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten
haben,
informieren Sie bitte sofort den Absender und löschen Sie diese E-Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht
gestattet.
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error)
please notify the
sender immediately and delete this e-mail. Any unauthorized copying, disclosure
or
distribution of the contents in this e-mail is strictly forbidden.
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.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
