Hi Andreas, > If you are already using an UPF, why don't you use another UPF for this purpose?
We do not have UPF, we are working CU where incoming packet are DU ( GTP-U) and outgoing packets towards UPF ( GTP-U ). Our requirement is to 1. receive GTP-U packet from DU 2. Replace the tied with tried and put the proper source and destination ip and send to UPF. The dest ip is ip of UPF and source ip the ip of our node interface. If you open-source code, if there is such example code, i will refer.. Please let me know. Thanks, Regards, Venu On Fri, 16 Jul 2021 at 21:37, Andreas Schultz < andreas.schu...@travelping.com> wrote: > > > Am Fr., 16. Juli 2021 um 17:04 Uhr schrieb Venumadhav Josyula < > vjosy...@gmail.com>: > >> 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. >> > > If you are already using an UPF, why don't you use another UPF for this > purpose? The PDR/FAR combination to change TEIDs and destination IPs is not > too hard. If you can write a tool to drive the VPP cli or API, doing the > same with a simple PFCP protocol layer is not too hard. > > Shameless plug: in case you want to use a VPP based, Open Source UPF, have > a look at https://github.com/travelping/upg-vpp > > Regards > Andreas > > > 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >> >> >> > > -- > > Andreas Schultz > > -- > > Principal Engineer > > t: +49 391 819099-224 > > ------------------------------- enabling your networks > ----------------------------- > > Travelping GmbH > Roentgenstraße 13 > 39108 Magdeburg > Germany > > t: +49 391 819099-0 > f: +49 391 819099-299 > > e: i...@travelping.com > w: https://www.travelping.com/ > Company registration: Amtsgericht Stendal > Managing Director: Holger Winkelmann > Reg. No.: HRB 10578 > VAT ID: DE236673780 >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19813): https://lists.fd.io/g/vpp-dev/message/19813 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] -=-=-=-=-=-=-=-=-=-=-=-
