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 (#19811): https://lists.fd.io/g/vpp-dev/message/19811 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] -=-=-=-=-=-=-=-=-=-=-=-
