Question about GTP support

[imehrdad2012]

Hello,

The README says that the code supports GTP. I would like to be able to add and remove GTP headers on traffic. Are these operations supported? Thanks!

[hibitomo]

Hi,

GTP-U is supported with extended ryu.
Could you use the ryu controller of the following branch?
https://github.com/lagopus/ryu-lagopus-ext/tree/lagopus-general-tunnel-ext

Thanks

[junkich]

Hi,

ryu-lagopus-ext/ryu/app/tunnel_gre.py and tunnel_vxlan.py are sample applications.
You can add or remove tunneling protocol header by using 'OFPActionEncap' or 'OFPActionDecap'.

Thanks

[imehrdad2012]

@hibitomo @ichi1229 I cannot see the GTP-U encapsulation and decapsulation code (GRE implementation is in the extended RYU but not GTP). Is it the case that you have not pushed it there yet?

[junkich]

GTP-U encap/decap testcases are ryu/tests/switch/of13/tunnel/08_ENCAP_GTPU.json or 09_DECAP_GTPU.json (maybe they are not be useful...)

Now ryu/app/tunnel_gtpu.py is pushed. This is same content as above testcases.
https://github.com/lagopus/ryu-lagopus-ext/blob/lagopus-general-tunnel-ext/ryu/app/tunnel_gtpu.py

[imehrdad2012]

@ichi1229 Thanks for pushing the GTP implementation. I am going to try it today. One more question: is the current implementation support GTPv1, GTPV2 or both of them? I am interested in leveraging the GTPv2 capability of Lagopus if possible.

[junkich]

Current implemention support only GTPv2.
In OFPActionSetField, the following fields can be used: gtpu_flags, gtpu_ver, gtpu_msgtype, gtpu_teid
Thanks

[imehrdad2012]

Thanks for the clarification. When I send a single GTP packet through the switch, it stops silently without sending the packet to the controller. At this step, I get the following:
Lagosh> show bridge
Socket connection refused. Lagopus is not running?
Any idea how to solve this? Thanks

[junkich]

I often get the message when I have syntax error on DSL config file... Then Lagopus is not running.
Please run in debug-mode with "-d" and check the debug message (or syslog message)
$ sudo lagopus -d -C {your-dsl-config-file}

In rawsock-mode, debug message is nothing. If it has anything errors, above command will be terminated immediately.

[imehrdad2012]

It successfully runs before sending GTP packet and stops right after the first packet arrives at the ingress port. The following is the output of syslog:

Sep 22 00:49:02 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:02 UTC 2017][INFO ][2764:0x00007f05ceccb740:lagopus]:./bridge_cmd.c:734:bri_bridge_start: start bridge. name = :bridge01.
Sep 22 00:49:02 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:02 UTC 2017][INFO ][2764:0x00007f05ceccb740:lagopus]:./mainloop.c:348:s_prologue: lagopus: All the modules are initialized.
Sep 22 00:49:02 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:02 UTC 2017][INFO ][2764:0x00007f05ceccb740:lagopus]:./mainloop.c:360:s_prologue: lagopus: Starting all the modules.
Sep 22 00:49:02 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:02 UTC 2017][INFO ][2764:0x00007f05ceccb740:lagopus]:./ofp_handler.c:164:ofp_handler_start: called.
Sep 22 00:49:02 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:02 UTC 2017][INFO ][2764:0x00007f05ceccb740:lagopus]:./mainloop.c:367:s_prologue: lagopus: All the modules are started and ready to go.
Sep 22 00:49:02 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:02 UTC 2017][INFO ][2764:0x00007f05ceccb740:lagopus]:./mainloop.c:546:s_callout_mainloop: lagopus is a go.
Sep 22 00:49:02 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:02 UTC 2017][DEBUG][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_handler.c:907:s_ofph_thread_main: waiting for the world changes to GLOBAL_STATE_STARTED ...
Sep 22 00:49:02 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:02 UTC 2017][INFO ][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_role.c:209:ofp_role_write: Channel is not alive, drop asynchronous message(OFPT_PORT_STATUS)
Sep 22 00:49:02 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:02 UTC 2017][INFO ][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_role.c:209:ofp_role_write: Channel is not alive, drop asynchronous message(OFPT_PORT_STATUS)
Sep 22 00:49:02 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:02 UTC 2017][INFO ][2764:0x00007f05cbad6700:dp_rawsock]:./mgr/sock_io.c:499:rawsock_port_stats: Physical Port 0: link up
Sep 22 00:49:02 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:02 UTC 2017][INFO ][2764:0x00007f05cbad6700:dp_rawsock]:./mgr/sock_io.c:499:rawsock_port_stats: Physical Port 1: link up
Sep 22 00:49:02 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:02 UTC 2017][INFO ][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_role.c:209:ofp_role_write: Channel is not alive, drop asynchronous message(OFPT_PORT_STATUS)
Sep 22 00:49:02 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:02 UTC 2017][INFO ][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_role.c:209:ofp_role_write: Channel is not alive, drop asynchronous message(OFPT_PORT_STATUS)
Sep 22 00:49:03 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:03 UTC 2017][INFO ][2764:0x00007f05c92d1700:c.o.worker:0]:./channel.c:572:channel_start: Connecting to OpenFlow controller (null):6633
Sep 22 00:49:03 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:03 UTC 2017][DEBUG][2764:0x00007f05ca2d3700:agent]:./ofp_handler.c:253:ofp_handler_get_channelq: called. (retptr: 0x7f05ca2cec80)
Sep 22 00:49:03 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:03 UTC 2017][DEBUG][2764:0x00007f05ca2d3700:agent]:./ofp_handler.c:253:ofp_handler_get_channelq: called. (retptr: 0x7f05ca2cec80)
Sep 22 00:49:03 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:03 UTC 2017][DEBUG][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_handler.c:645:s_process_channelq_entry: RECV: OFPT_HELLO (xid=1313003279)
Sep 22 00:49:03 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:03 UTC 2017][INFO ][2764:0x00007f05c9ad2700:ofp_handler]:./channel.c:716:channel_hello_confirm: channel_hello_confirm in
Sep 22 00:49:03 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:03 UTC 2017][DEBUG][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_handler.c:645:s_process_channelq_entry: RECV: OFPT_FEATURES_REQUEST (xid=1313003280)
Sep 22 00:49:03 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:03 UTC 2017][DEBUG][2764:0x00007f05ca2d3700:agent]:./ofp_handler.c:253:ofp_handler_get_channelq: called. (retptr: 0x7f05ca2cec80)
Sep 22 00:49:03 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:03 UTC 2017][DEBUG][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_handler.c:645:s_process_channelq_entry: RECV: OFPT_MULTIPART_REQUEST (xid=1313003281)
Sep 22 00:49:03 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:03 UTC 2017][DEBUG][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_handler.c:645:s_process_channelq_entry: RECV: OFPT_FLOW_MOD (xid=1313003282)
Sep 22 00:49:03 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:03 UTC 2017][DEBUG][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_handler.c:645:s_process_channelq_entry: RECV: OFPT_FLOW_MOD (xid=1313003283)
Sep 22 00:49:03 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:03 UTC 2017][DEBUG][2764:0x00007f05ca2d3700:agent]:./ofp_handler.c:253:ofp_handler_get_channelq: called. (retptr: 0x7f05ca2cec80)
Sep 22 00:49:03 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:03 UTC 2017][DEBUG][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_handler.c:645:s_process_channelq_entry: RECV: OFPT_ECHO_REPLY (xid=101)
Sep 22 00:49:04 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:04 UTC 2017][DEBUG][2764:0x00007f05ca2d3700:agent]:./ofp_handler.c:253:ofp_handler_get_channelq: called. (retptr: 0x7f05ca2cec80)
Sep 22 00:49:04 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:04 UTC 2017][DEBUG][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_handler.c:645:s_process_channelq_entry: RECV: OFPT_ECHO_REPLY (xid=102)
Sep 22 00:49:05 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:05 UTC 2017][DEBUG][2764:0x00007f05ca2d3700:agent]:./ofp_handler.c:253:ofp_handler_get_channelq: called. (retptr: 0x7f05ca2cec80)
Sep 22 00:49:05 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:05 UTC 2017][DEBUG][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_handler.c:645:s_process_channelq_entry: RECV: OFPT_ECHO_REPLY (xid=103)
Sep 22 00:49:06 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:06 UTC 2017][DEBUG][2764:0x00007f05ca2d3700:agent]:./ofp_handler.c:253:ofp_handler_get_channelq: called. (retptr: 0x7f05ca2cec80)
Sep 22 00:49:06 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:06 UTC 2017][DEBUG][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_handler.c:645:s_process_channelq_entry: RECV: OFPT_ECHO_REPLY (xid=104)
Sep 22 00:49:07 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:07 UTC 2017][DEBUG][2764:0x00007f05ca2d3700:agent]:./ofp_handler.c:253:ofp_handler_get_channelq: called. (retptr: 0x7f05ca2cec80)
Sep 22 00:49:07 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:07 UTC 2017][DEBUG][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_handler.c:645:s_process_channelq_entry: RECV: OFPT_ECHO_REPLY (xid=105)
Sep 22 00:49:08 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:08 UTC 2017][DEBUG][2764:0x00007f05ca2d3700:agent]:./ofp_handler.c:253:ofp_handler_get_channelq: called. (retptr: 0x7f05ca2cec80)
Sep 22 00:49:08 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:08 UTC 2017][DEBUG][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_handler.c:645:s_process_channelq_entry: RECV: OFPT_ECHO_REPLY (xid=106)
Sep 22 00:49:09 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:09 UTC 2017][DEBUG][2764:0x00007f05ca2d3700:agent]:./ofp_handler.c:253:ofp_handler_get_channelq: called. (retptr: 0x7f05ca2cec80)
Sep 22 00:49:09 vagrant-ubuntu-trusty-64 lagopus: [Fri Sep 22 00:49:09 UTC 2017][DEBUG][2764:0x00007f05c9ad2700:ofp_handler]:./ofp_handler.c:645:s_process_channelq_entry: RECV: OFPT_ECHO_REPLY (xid=107)
Sep 22 00:49:09 vagrant-ubuntu-trusty-64 kernel: [ 6794.991902] dp_rawsock[2767]: segfault at 34 ip 00007f05ce88369d sp 00007f05cbad5cc0 error 4 in liblagopus_dataplane.so.0.0.0[7f05ce875000+44000]

[junkich]

Thank you for the log report !
We are investigating this issue, so please kindly wait until we have checked.

And please let me correct what the GTP version is supported by current Lagopus and extended-ryu.
It's not GTPv2 but GTPv1.

Thanks

[imehrdad2012]

Thanks! I will wait to hear back from you. I am trying to connect Lagopus to an actual base station. Previously, I thought it was supporting GTPUv2 but after testing it today, I noticed it only supports GTPUv1 so I am happy with its compatibility with Lagopus. Best Regards, ---Mehrdad

…

On Fri, Sep 22, 2017 at 1:25 PM, ichi1229 ***@***.***> wrote: Thank you for the log report ! We are investigating this issue, so please kindly wait until we have checked. And please let me correct what the GTP version is supported by current Lagopus and extended-ryu. It's not GTPv2 but GTPv1. Thanks — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#127 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACicEIVz-G9tkaCKxvM7JP0crh-6RkgVks5sk-2kgaJpZM4PVQaK> .

-- ----- Mehrdad Moradi ‌Research Assistant University of Michigan- Ann Arbor

[imehrdad2012]

@ichi1229 I am wondering if you had a chance to investigate the issue with GTP-enabled lagopus
Thanks!

[junkich]

@imehrdad2012 Sorry for late reply.

We fixed this issue by the PullReq #129 "Fix the return value of rawsock OS_M_ADJ".
(This PullReq has not been merged to master branch yet.)
Please checkout "sock-os_m_adj" branch and try this fix.

Thanks!

[imehrdad2012]

@ichi1229 Thanks for fixing the issue. Actually, I was able to run the basic code and saw the encapsulation and decapsulation of the GTP packets. However, I faced two issues that would be great if you can comment on them:
1- I would like to add other match fields to the code when decapsulating the packets into GTP-u header. Packets from different sources must be encapsulated into the proper packet header. However, when I change to match = parser.OFPMatch(in_port=2) to match = parser.OFPMatch(in_port=2, ipv4_src = '192.168.3.100') in the RYU code, I get the following error:
move onto main mode
EventOFPErrorMsg received.
version=0x4, msg_type=0x1, msg_len=0x4c, xid=0x4e0d77c0
-- msg_type: OFPT_ERROR(1) OFPErrorMsg(type=0x4, code=0x9, data=b'\x04\x0e\x01\x00\x4e\x0d\x77\xc0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x14\x80\x00\x00\x04\x00\x00\x00\x02\x80\x00\x16\x04') |-- type: OFPET_BAD_MATCH(4) |-- code: OFPBMC_BAD_PREREQ(9) -- data: version=0x4, msg_type=0xe, msg_len=0x100, xid=0x4e0d77c0
-- msg_type: OFPT_FLOW_MOD(14) EventOFPErrorMsg received. version=0x4, msg_type=0x1, msg_len=0x4c, xid=0x4e0d77c1 -- msg_type: OFPT_ERROR(1)
Do you have any idea on how to fix this issue? I would like to be able to add the match fields on the gtp_u tunnel id when decapsulating packets.

2- When decapsulating packets, I comment out the following two lines in the ryu source code as I do not know the source and destination mac addresses in advance. When I comment them out, I see that the switch sets the source and destination mac addresses to somehow random values. Is this an expected behaviour? Thanks

parser.OFPActionSetField(eth_src='cc:cc:cc:cc:cc:cc'),
parser.OFPActionSetField(eth_dst='dd:dd:dd:dd:dd:dd'),

3- The third question is that do you have any idea on the performance of the switch when DPDK enabled in the VM environment VS the simple raw socket version?

[junkich]

@imehrdad2012

1- It's OpenFlow match field prerequisite.
You must insert "eth_type=2048" to the match field when you use ipv4_src field.
For example, match = parser.OFPMatch(in_port=2, eth_type=2048, ipv4_src = '192.168.3.100')
Please refer to the following document.
(ONF) OpenFlow Switch Specification v1.3.5
p.45 ofp_error_msg with OFPET_BAD_MATCH type and OFPBMC_BAD_PREREQ code
p.61 7.2.3.6 Flow Match Field Prerequisite

2- Yes, it is expected action in Lagopus encapulation function.
Lagopus set a basic ethernet header when encap(ethernet) action is called, and you can set specific mac address by using OFPActionSetField.

3- Of course, dpdk-mode has better performance than rawsock-mode.
If you want to get better performance, please try "gcc-full-opt" make target.
It enables some optimization options for gcc.

$ ./configure
$ make gcc-full-opt

Thanks.

[imehrdad2012]

@ichi1229 Thanks a lot for the comment.
Actually, I am using this format now: parser.OFPMatch(in_port=2, eth_type=2048, ipv4_src = '192.168.3.100').
There is no error now but the problem is that by adding eth_type and ipv4_src fields, the switch no longer forwards the packet. I tried with different IP packets and observed the same behaviour. The attached is my IP traffic that you can reply it using TCPReplay.
sink.zip.

The following is the output when I make the following change to the RYU GTP application (note the issue does not appear when I only use the in_port field):
match = parser.OFPMatch(in_port =2 , eth_type=2048, ipv4_src = '192.168.3.100')
#match = parser.OFPMatch(in_port=2)

TCPdump on the ingress interface:
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
21:17:03.365263 IP 192.168.3.100.37521 > 192.168.1.31.webmin: Flags [.], ack 1200594957, win 457, options [nop,nop,TS val 11745266 ecr 11745272], length 0
21:17:03.365275 IP 192.168.3.100.37521 > 192.168.1.31.webmin: Flags [.], ack 1, win 457, options [nop,nop,TS val 11745266 ecr 11745272], length 0
21:17:03.365277 IP 192.168.3.100.37521 > 192.168.1.31.webmin: Flags [.], ack 1, win 457, options [nop,nop,TS val 11745266 ecr 11745272], length 0
21:17:03.365278 IP 192.168.3.100.37521 > 192.168.1.31.webmin: Flags [.], ack 1, win 457, options [nop,nop,TS val 11745266 ecr 11745272], length 0
21:17:03.365279 IP 192.168.3.100.37521 > 192.168.1.31.webmin: Flags [.], ack 1, win 457, options [nop,nop,TS val 11745266 ecr 11745272], length 0
21:17:03.365308 IP 192.168.3.100.37521 > 192.168.1.31.webmin: Flags [.], ack 1, win 457, options [nop,nop,TS val 11745266 ecr 11745272], length 0
21:17:03.365331 IP 192.168.3.100.37521 > 192.168.1.31.webmin: Flags [.], ack 1, win 457, options [nop,nop,TS val 11745266 ecr 11745272], length 0

TCPdump at the egress interface:
vagrant@vagrant-ubuntu-trusty-64:/srv$ sudo tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Lagosh> show bridge
[
{
"name": "bridge01",
"packet-inq-entries": 0,
"up-streamq-entries": 0,
"down-streamq-entries": 0,
"flowcache-entries": 0,
"flowcache-hit": 0,
"flowcache-miss": 0,
"flow-entries": 2,
"flow-lookup-count": 20,
"flow-matched-count": 0,
"tables": [
{
"table-id": 0,
"flow-entries": 2,
"flow-lookup-count": 20,
"flow-matched-count": 0
}
],
"is-enabled": true
}
]

[imehrdad2012]

@ichi1229 @hibitomo Do you guys have any comment on the above issue? Thanks!

[junkich]

@imehrdad2012

It looks like there are two possible causes.

1- Lagopus supports only GTPv1-U, and GTPv1 is used only on UDP.
So you must send the GTPv1-U encapsulated UDP(dst:2152) packet to Lagopus, but you use TCP as ingress packet to testing decapsulation in sink.zip.
The following is the ingress packet of extended-ryu testcase.
09_ingress.zip
Please see the test config of extended-ryu
(ryu-lagopus-ext/ryu/tests/switch/of13/tunnel/09_DECAP_GTPU.json)

2- You must specify the packet type for packet classification.

match = parser.OFPMatch(in_port=2, eth_type=2048, ip_proto=17, udp_dst=2125)

Because Lagopus do not support the validation of Decapsulation and Encapsulation.
For example, when non-GTPv1-U packet arrives at Lagopus, Lagopus decapsulate the packet as GTPv1-U.

And you can use OFPInstructionGoToTable() if it is difficult to set both of packet classification rule and your flow rule to single table.

Thanks.

[imehrdad2012]

For the reference of others:
match = parser.OFPMatch(in_port=1) is not sufficient for decapsulation because there are other types of incoming traffic entering any real interface and the causes lagopus to crash ( segfault at 0 ip 00007fcfbfb144d0 sp 00007fcfbcd66cc0 error 4 in liblagopus_dataplane.so.0.0.0[7fcfbfb06000+44000]). Therefore, the following is necessary for the match fields: match = parser.OFPMatch(in_port=1,eth_type=2048, ip_proto=17, udp_dst=2152) for real experiments.

[junkich]

Sorry, the following match fields in the decapsulation testcase was wrong.

match = parser.OFPMatch(in_port=2, eth_type=2048, ip_proto=17, udp_dst=2125)

UDP destination port for GTPv1-U is 2152. So match fields should be the following...

match = parser.OFPMatch(in_port=2, eth_type=2048, ip_proto=17, udp_dst=2152)

We fixed the testcase and sample applications in extended-ryu.

[imehrdad2012]

@ichi1229
One issue that I experienced is that although packets are forwarded through the GTP-enabled switch, the statistics for matched rules are not updated.

[imehrdad2012]

@ichi1229 @hibitomo is it possible to further improve the performance of raw socket Lagopus? (e.g., by modifying the queue size for ports and buffers? or increasing number of threads?) Currently, I am not getting beyond 80Mbps. Any pointer or suggested configuration is appreciated. Thanks

[fr6nco]

@imehrdad2012 is there a particular reason, why you used the raw version instead of DPDK? I would like to try this switch out, but first I want to make it sure, it supports GTP properly and is fast. BTW since kernel version 4.7, GTP tunneling is supported, so for GTP encap/decap you could use a linux box in-front of this switch. Even with the kernel support, I believe DPDK will be however faster.

[GinesGarcia]

Is possible to perform snat when decapsulating?
I have been trying to add a OFPActionSetField(ipv4_src=xx.xx.xx.xx) before encapsulate ethernet:

actions = [ # decap ether-ip parser.OFPActionDecap(type_eth, type_ip), # decap ip-udp parser.OFPActionDecap(type_ip, type_udp), # decap udp-gtpu parser.OFPActionDecap(type_udp, type_gtpu), # decap gtpu-ip parser.OFPActionDecap(type_gtpu, type_ip), parser.OFPActionSetField(ipv4_src=self.PUBLIC_IP), # encap ether parser.OFPActionEncap(type_eth), parser.OFPActionSetField(eth_src=self.SWITCH_MAC_ADDR), parser.OFPActionSetField(eth_dst=self.dst_mac_addr), # output parser.OFPActionOutput(2, ofproto.OFPCML_NO_BUFFER) ]

But lagopus stops right after the arrival of a packet.

Any suggestions?