Hi Venu,

>From your points, I understand that your GTPU packet must not be
decapsulated and fired out to Phys once the packet reaches VPP. If your
requirement is on Forwarding the packet via tunnel then include some code
in gtpu_input so that the packet is not decapsulated and the forwarding
also happens as you need. Search for the keyword "enqueue" inside the
gtpu_input which puts the packet to queue for egress of the same. Reach
that call without decapsulated .Mostly a goto variable would do the job
with some if checks.

Hope this helps.

Thanks and Regards,
Akash

On Fri, Jul 16, 2021, 8:34 PM Venumadhav Josyula <vjosy...@gmail.com> wrote:

> Hi Akash,
>
> >From your requirement , keeping vpp support in mind, you shall send the
> complete GTPU
> >packet from your device which you use to fire packets. The packet shall
> be marked with the >exact destination so that it reaches the GTPU Tunnel
> created via Phys and the >Decapsulated packet shall egress out via Phys on
> which it was received. But I have no idea >how encap comes into picture in
> this . Anyways, if you need to mark the packet with the >correct teid,
> tteid and make the packet as type GTPU then you shall fire an IP packet to
> the >Tunnel so that it is encapsulated and fired out of interface.
>
> Ok let me explain, we are recieve GTPU packets from DU and want to send
> gtp packet to the UPF. Now for that our node receives GTP-U packet and send
> the GTP-U using tried. The dst ip passed as part of CLI will be going the
> dest ip.
>
> So once the packet enter gtpu_input ( i am talking existing GTPU Plugin
> code ), it uses the configured tied to match tied in the received packet.
> Now does it not strip GTP-U header. ?? This is my understanding. please
> correct me if i am wrong/
>
> If strips the GTP-U header we need to put back GTP-U which happens in the
> gtpu4-encap ? and send it out on interface.
>
> Or my understanding is totally misplaced ??? then what is the purpose
> gtpu4-encap ?
>
> Thanks,
> Regards,
> Venu
>
>
>
> On Fri, 16 Jul 2021 at 20:11, Akash S R <akashsr.akas...@gmail.com> wrote:
>
>> Hi Venu,
>>
>> From your requirement , keeping vpp support in mind, you shall send the
>> complete GTPU packet from your device which you use to fire packets. The
>> packet shall be marked with the exact destination so that it reaches the
>> GTPU Tunnel created via Phys and the Decapsulated packet shall egress out
>> via Phys on which it was received. But I have no idea how encap comes into
>> picture in this . Anyways, if you need to mark the packet with the correct
>> teid, tteid and make the packet as type GTPU then you shall fire an IP
>> packet to the Tunnel so that it is encapsulated and fired out of interface.
>>
>> Hope this helps.
>>
>> Regards,
>> Akash
>>
>> On Fri, Jul 16, 2021, 7:46 PM Venumadhav Josyula <vjosy...@gmail.com>
>> wrote:
>>
>>> Hi Akash,
>>>
>>> Our requirement is simple we will get gtpu packet and send gtpu packet
>>> by properly replacing with proper tied and ip
>>>
>>> Thanks
>>> Regards
>>> Venu
>>>
>>> On Fri, 16 Jul, 2021, 7:25 pm Akash S R, <akashsr.akas...@gmail.com>
>>> wrote:
>>>
>>>> Hi Venu,
>>>>
>>>> decap-next supports only 3 parameters I guess .So, If you need an
>>>> support like reaching gtpu4_encap-node, you might need to have a look on
>>>> the gtpu_input API where the next0 fields can be set internally with some
>>>> checks and enqueue the packet to gtpu4-encap.
>>>>
>>>> Also, Please add your requirement view so that I may help you out on it.
>>>>
>>>> Regards,
>>>> Akash
>>>>
>>>> On Fri, Jul 16, 2021, 2:42 PM Venumadhav Josyula <vjosy...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Akash,
>>>>>
>>>>> While creating tunnels there if I set decap-next gtpu4-encap will it
>>>>> not work, it use the tried for the same right ?
>>>>> create gtpu tunnel src 10.21.58.142 dst 10.21.58.140 teid 13 tteid 14
>>>>> encap-vrf-id 0 decap-next ip4 // instead of ip4, gtpu4-encap
>>>>>
>>>>> Thanks,
>>>>> Regards,
>>>>> Venu
>>>>>
>>>>>
>>>>> On Fri, 16 Jul 2021 at 14:22, Akash S R <akashsr.akas...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Venumadhav,
>>>>>>
>>>>>> Sharing my knowledge nuggets as below:
>>>>>> * gtpu_input is an API which processes the gtpu packet for
>>>>>> decapsulation and fire out the packet as an IP packet. You cannot reach
>>>>>> gtpu_encap_inline with the same. But if you wish to send the Decapsulated
>>>>>> IP packet to encap, you can using the next0 variable which enqueues your
>>>>>> packet to the next node you wish to reach.
>>>>>>
>>>>>> I don't guarantee that your packet will be encapsulated without any
>>>>>> error but you can reach the next node you wish to reach in this way.
>>>>>>
>>>>>> Thanks and Regards,
>>>>>> Akash S R
>>>>>>
>>>>>> On Fri, Jul 16, 2021, 2:03 PM Venumadhav Josyula <vjosy...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi vpp gtpu experts,
>>>>>>>
>>>>>>> We have requirement where
>>>>>>>
>>>>>>>    - we create gtpu tunnel
>>>>>>>    - Now, we will hit gtpu input, where we will receive gtpu packet
>>>>>>>    and when we send it out on the interface replace the tied with tried 
>>>>>>> and
>>>>>>>    massage the ip address of src and destination and send the packet out
>>>>>>>
>>>>>>> vpp# show vlib graph gtpu4-input
>>>>>>>            Name                      Next                    Previous
>>>>>>> gtpu4-input                     error-drop [0]
>>>>>>>  ip4-gtpu-bypass
>>>>>>>                                  l2-input [1]
>>>>>>> ip4-udp-lookup
>>>>>>>                                  ip4-input [2]
>>>>>>>                                  ip6-input [3]
>>>>>>> vpp#
>>>>>>>
>>>>>>> vpp# show vlib graph gtpu4-encap
>>>>>>>            Name                      Next                    Previous
>>>>>>> gtpu4-encap                     error-drop [0]
>>>>>>>  ip4-dvr-dpo
>>>>>>>                                 ip4-lookup [1]                ip4-arp
>>>>>>>                                 ip6-lookup [2]
>>>>>>> ip4-midchain
>>>>>>>                              ip4-load-balance [3]
>>>>>>> ip4-mcast-midchain
>>>>>>>
>>>>>>>  ip4-rewrite-mcast
>>>>>>>
>>>>>>>  ip4-rewrite-bcast
>>>>>>>
>>>>>>> ip4-rewrite
>>>>>>>
>>>>>>>  interface-output
>>>>>>>
>>>>>>>   vpp# show vlib graph gtpu4-input
>>>>>>>            Name                      Next                    Previous
>>>>>>> gtpu4-input                     error-drop [0]
>>>>>>>  ip4-gtpu-bypass
>>>>>>>                                  l2-input [1]
>>>>>>> ip4-udp-lookup
>>>>>>>                                   gtpu4-encap [2]
>>>>>>>                                   gtpu6-encap [3]
>>>>>>>
>>>>>>> Now we want next gtpu-input to be gtpu4-encap and the next of that
>>>>>>> to ip4-load-balance or directly send it out. Is such thing possible.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Regards,
>>>>>>> Venu
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19809): https://lists.fd.io/g/vpp-dev/message/19809
Mute This Topic: https://lists.fd.io/mt/84244683/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to