Hi Andreas, Actually thanks for the link! Noticed you guys keep a set of vpp patches and some of them have not been merged yet. In particular, this [1] looked really useful and subsequently realized it was submitted but not merged because it failed checkstyle. Feel free to insist when that happens! :-)
Regards, Florin [1] https://gerrit.fd.io/r/c/vpp/+/30099 > On Jul 16, 2021, at 9:07 AM, Andreas Schultz <andreas.schu...@travelping.com> > wrote: > > > > Am Fr., 16. Juli 2021 um 17:04 Uhr schrieb Venumadhav Josyula > <vjosy...@gmail.com <mailto: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 > <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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 <mailto:i...@travelping.com> > w: https://www.travelping.com/ <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 (#19817): https://lists.fd.io/g/vpp-dev/message/19817 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] -=-=-=-=-=-=-=-=-=-=-=-
