[vpp-dev] Encapsulated IPv6 packet fragmentation issue #vnet #vpp
[Edited Message Follows] Hi everyone, I have an use-case where I need to fragment an encapsulated IPv6 packet. I'm doing it using the ip6_frag_do_fragment() routine, like so: encap_size = sizeof(some_encap_tunnel_t); ip6_frag_do_fragment(vm, pi0, vnet_buffer(p0)->ip_frag.mtu - encap_size, encap_size, &frags); Looking at the implementation of ip6_frag_do_fragment() I notice that l2unfragmentablesize bytes, which here is encap_size , are getting overwritten after they were first copied into the newly allocated fragment, which makes no sense imho because what's the whole point of l2unfragmentablesize then? Let me elaborate. This correctly copies the tunnel headers stack from the original packet into the fragment: clib_memcpy_fast(to_b->data, org_from_packet, l2unfragmentablesize + sizeof(ip6_header_t)); But right after: to_ip6 = vlib_buffer_get_current(to_b); // (potentially offending line) this points into the just copied tunnel headers stack, to_frag_hdr = (ip6_frag_hdr_t*)(to_ip6 + 1); // also this, to_data = (void*)(to_frag_hdr + 1); // and this one too.. ... // not good, this overwrites the tunnel headers stack that were previously copied // from_data correctly points to the encapsulated IPv6 payload (from the original to be fragmented packet) clib_memcpy_fast(to_data + to_ptr=0, from_data + ptr=0, bytes_to_copy); | v +-+--+-+ | some_encap_tunnel_t | ipv6 | ... | +-+--+-+ Whereas ip4_frag_do_fragment() , with the same use-case (i.e. encapsulated ipv4 packet fragmentation), works just fine as it copies and keeps untouched the l2unfragmentablesize bytes from the original to be fragmented packet on every produced fragment. Hope this makes sense. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17146): https://lists.fd.io/g/vpp-dev/message/17146 Mute This Topic: https://lists.fd.io/mt/76011077/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Encapsulated IPv6 packet fragmentation issue #vnet #vpp
Hi everyone, I have an use-case where I need to fragment an encapsulated IPv6 packet. I'm doing it using the ip6_frag_do_fragment() routine, like so: encap_size = sizeof(some_encap_tunnel_t); ip6_frag_do_fragment(vm, pi0, vnet_buffer(p0)->ip_frag.mtu - encap_size, encap_size, &frags); Looking at the implementation of ip6_frag_do_fragment() I notice that l2unfragmentablesize bytes, which here is encap_size , are getting overwritten after they were first copied into the newly allocated fragment, which makes no sense imho because what's the whole point of l2unfragmentablesize then? Let me elaborate. This correctly copies the tunnel headers stack from the original packet into the fragment: clib_memcpy_fast(to_b->data, org_from_packet, l2unfragmentablesize + sizeof(ip6_header_t)); But right after: to_ip6 = vlib_buffer_get_current(to_b); // (potentially offending line) this points into the just copied tunnel headers stack, to_frag_hdr = (ip6_frag_hdr_t*)(to_ip6 + 1); // also this, to_data = (void*)(to_frag_hdr + 1); // and this one too.. ... // not good, this overwrites the tunnel headers stack that were previously copied // from_data correctly points to the encapsulated IPv6 payload (from the original to be fragmented packet) clib_memcpy_fast(to_data + to_ptr=0, from_data + ptr=0, bytes_to_copy); | v +-+--+-+ | some_encap_tunnel_t | ipv6 | ... | +-+--+-+ Whereas ip4_frag_do_fragment() , with the same use-case (i.e. encapsulated ipv4 packet fragmentation), works just fine as it copies and keeps untouched the l2unfragmentablesize bytes from the original to be fragmented packet on every produced fragment. Hope this makes sense. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17146): https://lists.fd.io/g/vpp-dev/message/17146 Mute This Topic: https://lists.fd.io/mt/76011077/21656 Mute #vnet: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vnet Mute #vpp: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Some inconsistencies in API installed header files #vpp #vapi #vnet
I confirm the fix. Thank you -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16570): https://lists.fd.io/g/vpp-dev/message/16570 Mute This Topic: https://lists.fd.io/mt/74479551/21656 Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452 Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=1480452 Mute #vapi: https://lists.fd.io/mk?hashtag=vapi&subid=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Segfault in 'vapi_type_msg_header1_t_ntoh()' with a C++ api client #vpp #vapi
Hi Klement,
Thanks for your reply and clarification. I found the issue on my end, my bad.
On the dataplane plugin side of the api message handler:
>
>
> vl_api_session_add_t_handler(vl_api_session_add_t *mp)
I was making use of the endian generated functions in order to convert to host
byte order the whole received api message request, right before processing it.
Endian functions included like so:
>
> #define vl_endianfun
> #include "sample/sample.api.h"
> #undef vl_endianfun
Using the generated endian functions like so:
>
> vl_api_session_add_t_handler(vl_api_session_add_t *mp)
> {
> ...
> vl_api_session_add_t_endian(mp);
> ...
> REPLY_MACRO(VL_API_SESSION_ADD_REPLY);
> }
But I wasn't careful enough in that the generated
'vl_api_session_add_t_endian()' isn't converting to host byte order the message
payload only, but the header fields also (i.e. '_vl_msg_id', 'client_index',
and 'context' fields, not good).
As you explained, again thanks for that, 'context' field especially shall not
be touched, but I unknowingly was swapping its endianness, and that's the
actual root cause if I understood correctly.
The fix, just verified, is obviously by swapping the endianness of the payload
only.
Thanks
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16569): https://lists.fd.io/g/vpp-dev/message/16569
Mute This Topic: https://lists.fd.io/mt/74526467/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452
Mute #vapi: https://lists.fd.io/mk?hashtag=vapi&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Segfault in 'vapi_type_msg_header1_t_ntoh()' with a C++ api client #vpp #vapi
[Edited Message Follows]
Hi all,
So, the problem is encountered with my C++ client when receiving a reply. The
strange thing is that this happens only with a specific type of api
request-reply.
Follows the segfault stack trace:
>
> Thread 1 "sample_plugin_client" hit Breakpoint 1,
> vapi_type_msg_header1_t_ntoh (h=0x0)
> at /usr/include/vapi/vapi_internal.h:63
> 63 h->_vl_msg_id = be16toh (h->_vl_msg_id);
> (gdb) bt
> #0 vapi_type_msg_header1_t_ntoh (h=0x0) at
> /usr/include/vapi/vapi_internal.h:63
> #1 0x00406bff in vapi_msg_sample_plugin_session_add_reply_ntoh
> (msg=0x0) at /usr/include/vapi/sample_plugin.api.vapi.h:1215
> #2 0x00419869 in
> vapi::vapi_swap_to_host
> (msg=0x0)
> at /usr/include/vapi/sample_plugin.api.vapi.hpp:260
> #3 0x00419ad3 in
> vapi::Msg::assign_response
> (this=0x7fffe1b8,
> resp_id=49, shm_data=0x0) at /usr/include/vapi/vapi.hpp:614
> #4 0x00419797 in
> vapi::Request vapi_msg_sample_plugin_session_add_reply>::assign_response (
> this=0x7fffe170, id=49, shm_data=0x0) at
> /usr/include/vapi/vapi.hpp:684
> #5 0x00410b1b in vapi::Connection::dispatch (this=0x7fffe2c0,
> limit=0x7fffe170, time=5)
> at /usr/include/vapi/vapi.hpp:289
> #6 0x00410d9a in vapi::Connection::dispatch (this=0x7fffe2c0,
> limit=...)
> at /usr/include/vapi/vapi.hpp:324
> #7 0x00410ddc in vapi::Connection::wait_for_response
> (this=0x7fffe2c0, req=...)
> at /usr/include/vapi/vapi.hpp:340
> #8 0x0040ba58 in sample_plugin_session_add (vpp_conn=...,
> msg_pload=...)
> at
> /root/tmp/vpp/src/plugins/sample_plugin/rubbish/client/src/sample_plugin_client.cpp:213
>
> #9 0x0040c485 in main () at
> /root/tmp/vpp/src/plugins/sample_plugin/rubbish/client/src/sample_plugin_client.cpp:388
>
Here's the kaboom " h->_vl_msg_id = be16toh (h->_vl_msg_id)", where 'h' is
NULL, yikes :O.
I traced the root cause in the 'vapi::Connection::dispatch()' method,
specifically here:
>
>
> u32 context = *reinterpret_cast((static_cast (shm_data) +
> vapi_get_context_offset (id))); // context' here is 218103808 in my case,
> for example
> const auto x = requests.front();
> matching_req = x;
> if (context == x->context) // while 'x->context' here is 13, i.e.
> htonl(13) is 218103808 (endianness inconsistency), so this branch here is
> not taken
> {
> std::tie (rv, break_dispatch) = x->assign_response (id, shm_data);
> }
> else // this one is taken, i.e. by passing 'nullptr' and subsequently
> being dereferenced ==> BOOM!
> {
> std::tie (rv, break_dispatch) = x->assign_response (id, nullptr);
> }
Also, I see REPLY_MACRO doing:
>
> rmp->_vl_msg_id = htons(REPLY_MSG_ID_BASE + VL_API_blablabla_REPLY);
> rmp->context = mp->context;
So '_vl_msg_id' gets network byte order, but not so with 'context', why's that?
Does this have something to do with the client's resulting segfault?
Oh, and I'm on top of the latest 'stable/2005'.
Thank you
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16559): https://lists.fd.io/g/vpp-dev/message/16559
Mute This Topic: https://lists.fd.io/mt/74526467/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Segfault in 'vapi_type_msg_header1_t_ntoh()' with a C++ api client #vpp #vapi
Hi all,
So, the problem is encountered with my C++ client when receiving a reply. The
strange thing is that this happens only with a specific type of api
request-reply.
Follows the segfault stack trace:
>
> Thread 1 "sample_plugin_client" hit Breakpoint 1,
> vapi_type_msg_header1_t_ntoh (h=0x0)
> at /usr/include/vapi/vapi_internal.h:63
> 63 h->_vl_msg_id = be16toh (h->_vl_msg_id);
> (gdb) bt
> #0 vapi_type_msg_header1_t_ntoh (h=0x0) at
> /usr/include/vapi/vapi_internal.h:63
> #1 0x00406bff in vapi_msg_sample_plugin_session_add_reply_ntoh
> (msg=0x0) at /usr/include/vapi/sample_plugin.api.vapi.h:1215
> #2 0x00419869 in
> vapi::vapi_swap_to_host
> (msg=0x0)
> at /usr/include/vapi/sample_plugin.api.vapi.hpp:260
> #3 0x00419ad3 in
> vapi::Msg::assign_response
> (this=0x7fffe1b8,
> resp_id=49, shm_data=0x0) at /usr/include/vapi/vapi.hpp:614
> #4 0x00419797 in vapi::Request vapi_msg_sample_plugin_pfcp_add_reply>::assign_response (
> this=0x7fffe170, id=49, shm_data=0x0) at
> /usr/include/vapi/vapi.hpp:684
> #5 0x00410b1b in vapi::Connection::dispatch (this=0x7fffe2c0,
> limit=0x7fffe170, time=5)
> at /usr/include/vapi/vapi.hpp:289
> #6 0x00410d9a in vapi::Connection::dispatch (this=0x7fffe2c0,
> limit=...)
> at /usr/include/vapi/vapi.hpp:324
> #7 0x00410ddc in vapi::Connection::wait_for_response
> (this=0x7fffe2c0, req=...)
> at /usr/include/vapi/vapi.hpp:340
> #8 0x0040ba58 in sample_plugin_pfcp_add (vpp_conn=...,
> msg_pload=...)
> at
> /root/tmp/vpp/src/plugins/sample_plugin/rubbish/client/src/sample_plugin_client.cpp:213
>
> #9 0x0040c485 in main () at
> /root/tmp/vpp/src/plugins/sample_plugin/rubbish/client/src/sample_plugin_client.cpp:388
>
Here's the kaboom " h->_vl_msg_id = be16toh (h->_vl_msg_id)", where 'h' is
NULL, yikes :O.
I traced the root cause in the 'vapi::Connection::dispatch()' method,
specifically here:
>
>
> u32 context = *reinterpret_cast((static_cast (shm_data) +
> vapi_get_context_offset (id))); // context' here is 218103808 in my case,
> for example
> const auto x = requests.front();
> matching_req = x;
> if (context == x->context) // while 'x->context' here is 13, i.e.
> htonl(13) is 218103808 (endianness inconsistency), so this branch here is
> not taken
> {
> std::tie (rv, break_dispatch) = x->assign_response (id, shm_data);
> }
> else // this one is taken, i.e. by passing 'nullptr' and subsequently
> being dereferenced ==> BOOM!
> {
> std::tie (rv, break_dispatch) = x->assign_response (id, nullptr);
> }
Also, I see REPLY_MACRO doing:
>
> rmp->_vl_msg_id = htons(REPLY_MSG_ID_BASE + VL_API_blablabla_REPLY);
> rmp->context = mp->context;
So '_vl_msg_id' gets network byte order, but not so with 'context', why's that?
Does this have something to do with the client's resulting segfault?
Oh, and I'm on top of the latest 'stable/2005'.
Thank you
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16559): https://lists.fd.io/g/vpp-dev/message/16559
Mute This Topic: https://lists.fd.io/mt/74526467/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452
Mute #vapi: https://lists.fd.io/mk?hashtag=vapi&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] RPM packaging on "stable/2005" branch maybe broken on suse leap 15.1 #vpp
Hi all, All worked just fine as I was on top of "stable/2001" branch, but today I rebased my work on top of "stable/2005" and did a "make pkg-rpm" which breaks right at the end at the "vpp-papi" build stage. Specifically: > > ... > running install_egg_info > running egg_info > creating vpp_papi.egg-info > writing requirements to vpp_papi.egg-info/requires.txt > writing vpp_papi.egg-info/PKG-INFO > writing top-level names to vpp_papi.egg-info/top_level.txt > writing dependency_links to vpp_papi.egg-info/dependency_links.txt > writing manifest file 'vpp_papi.egg-info/SOURCES.txt' > reading manifest file 'vpp_papi.egg-info/SOURCES.txt' > writing manifest file 'vpp_papi.egg-info/SOURCES.txt' > Copying vpp_papi.egg-info to > /root/tmp/vpp/build-root/rpmbuild/BUILDROOT/vpp-20.05-rc2~10_g31ba8e8cb.x86_64/usr/lib/python2.7/site-packages/vpp_papi-1.6.2-py2.7.egg-info > > running install_scripts > + mkdir -p -m755 > /root/tmp/vpp/build-root/rpmbuild/BUILDROOT/vpp-20.05-rc2~10_g31ba8e8cb.x86_64/usr/lib/python2.7/site-packages/vpp_papi > > ++ find > '/root/tmp/vpp/build-root/rpmbuild/BUILDROOT/vpp-20.05-rc2~10_g31ba8e8cb.x86_64/../../BUILD/vpp-20.05/build-root/install-vpp-native//*/lib/python2.7/site-packages/' > -type f -print > ++ grep -v pyc > find: > ‘/root/tmp/vpp/build-root/rpmbuild/BUILDROOT/vpp-20.05-rc2~10_g31ba8e8cb.x86_64/../../BUILD/vpp-20.05/build-root/install-vpp-native//*/lib/python2.7/site-packages/’: > No such file or directory Apparently, the "find" cmd is trying to watch into "/build-root/rpmbuild/BUILD/vpp-20.05/build-root/install-vpp-native/[external|vom|vpp]/lib/" where, in fact, I don't see any "python2.7" folder. Is this an issue on my end, or how can I understand this? Please someone do let me know. The system is an openSUSE Leap 15.1 Thank you -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16533): https://lists.fd.io/g/vpp-dev/message/16533 Mute This Topic: https://lists.fd.io/mt/74503879/21656 Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Some inconsistencies in API installed header files #vpp #vapi #vnet
Hi, That might actually be the fix :). It so happens that I was on top of "stable/2001" which doesn't have this commit, but I see "master" and "stable/2005" do have it, dammit. However, I'll give it a try and let u know if you want to. Thank you -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16501): https://lists.fd.io/g/vpp-dev/message/16501 Mute This Topic: https://lists.fd.io/mt/74479551/21656 Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452 Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=1480452 Mute #vapi: https://lists.fd.io/mk?hashtag=vapi&subid=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Some inconsistencies in API installed header files #vpp #vapi #vnet
Hi all, I don't know if this is the right place to ask and if the "issue" here is really an expected one, or if I'm just doing something really stupid. So, someone please do let me know. I found some inconsistencies in some API header files installed under "/usr/include/" , in my case specifically "/usr/include/vnet/ip/ip_types.api_types.h" and "/usr/include/vapi/ip_types.api.vapi.h". For example, "vl_api_ip_dscp_t" is defined in "/usr/include/vnet/ip/ip_types.api_types.h" header file as a packed enum, while "vapi_enum_ip_dscp" (the one used by a e.g. C++ client) defined in "/usr/include/vapi/ip_types.api.vapi.h" as a non-packed enum. This is a problem because, as in my case, the C++ client sends a big message which in the middle it happens to have a vapi_enum_ip_dscp field which is 4 bytes long, while VPP receives this message where it sees the same dscp field as "vapi_enum_ip_dscp" which is 1 byte long, so there you have it, I leave to your imagination the consequences. I may apply some workarounds, but I really wanted to know if this was expected (although I wouldn't know the sense of it). Thank you -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16499): https://lists.fd.io/g/vpp-dev/message/16499 Mute This Topic: https://lists.fd.io/mt/74479551/21656 Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452 Mute #vapi: https://lists.fd.io/mk?hashtag=vapi&subid=1480452 Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] GTPu Question
Hi, I had more or less the same question something like 2 years ago, and guess what, to date still no reply whatsoever. I'd think the plugin's developer is untraceable and/or "out of duty". Now back to the question, if I didn't misunderstood this GTPU plugin's semantics (by reading the code), this plugin doesn't operate as you'd expect from a mobile 3GPP point of view, it actually operates very similarly to how VXLAN does. What this plugin does is mainly implementing a *VTEP (Virtual Tunnel Endpoint)* , so its tunnel interface (i.e. gtpu_tunnelX ) needs an IP address on the same subnet of the actual destination of the encapped packet (i.e. the T-PDU). I know, it's somewhat confusing, but I studied and tried it, and I can confirm that it works this way. If you still want to really understand and use it, I'd suggest you to learn how VXLAN works and its terminology (if you don't know it yet), it'll be a lot easier for you to grasp this plugin's operation. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16497): https://lists.fd.io/g/vpp-dev/message/16497 Mute This Topic: https://lists.fd.io/mt/74471469/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] How to direct traffic destined to a given subnet to a specific node of my choice? #vpp
Hi all, would there be anyone kind enough to illustrate how and what to do in order to forward a given subnet traffic (e.g. IPv4 traffic destined to 192.168.0.0/24) to a specific node of my choice, rather than the predefined "ip[4|6]-rewrite"? I know it may have something to do with DPOs, as per this ( https://www.asumu.xyz/blog/2018/11/14/data-path-objects-in-vpp/ ) nice online article? But still, I'd really like to know what the minimum required APIs would be to make this work. Also, some specific code to watch on would be very much appreciated. Thanks -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15696): https://lists.fd.io/g/vpp-dev/message/15696 Mute This Topic: https://lists.fd.io/mt/71769498/21656 Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] GTP-U base usage setup
Hi all,
I'm trying to use VPP as a GTP-U dataplane, I have already read
https://wiki.fd.io/view/VPP/Per-feature_Notes and
https://docs.fd.io/vpp/19.01/clicmd_src_plugins_gtpu.html , but still can't
understand how the appropriate configuration should be done (please pardon my
ignorance). The ascii-art scheme below shows how my testbed looks like. I'd
like to GTP-decap in the VPP machine the GTP-U traffic sent by the Gen1
machine. The GTP-U packets sent by Gen1 are of the following format: {src-ip
172.26.124.233, dst-ip 172.26.124.241}||{dst-udp 2152}||{gtp-teid 2}||{src-ip
10.0.0.1, dst-ip 172.26.125.153} ||{udp}||{"valar morghulis"} where || stands
for concatenation. What should be the correct configuration for doing GTP-decap
and performing routing over decapsulated UE data-packets, thus forwarding via
the right port (i.e em1 --> em3) ?
What a bout the GTP-encap direction, in another use-case? Say Gen1 sending
normal data-packets as UE's IP data-packet = {src-ip 172.26.124.233, dst-ip
10.0.0.1}||{udp}||{"valar dohaeris"} to the VPP dataplane which should
GTP-encapsulate them as {src-ip 172.26.125.241, dst-ip 172.26.125.153}
||{dst-udp 2152}||{gtp-teid 3}|| performing IP routing and
forwarding via the right port (i.e. em1 --> em3) ?
I'm pretty desperate with this, so any help is very appreciated.
Gen1
+-+
| |
| UE: 10.0.0.1 |
| |
+-+--++
| eth5 |
+--+---+
|.233
|
| 172.26.124.0/24
|
|.241
+--+--+
| em1 |
+-+-+-+
| |
| VPP |
| |
+-+-+-+
| em3 |
+--+--+
|.241
|
| 172.26.125.0/24
|
|.153
+--+---+
| eth4 |
+-+--+---++
| |
| Recv1 |
| |
+-+
Thank you
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12161): https://lists.fd.io/g/vpp-dev/message/12161
Mute This Topic: https://lists.fd.io/mt/29653968/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
