Hi Venu,
If you need to switch teid with tried/tteid you may do it on code and
ensure that decapsulation is not happening and you directly fire the packet
out/enqueue .
Regards,
Akash
On Fri, Jul 16, 2021, 9:52 PM Venumadhav Josyula wrote:
> Hi Akash,
>
> You are more or less right, but there
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 hap
Hi Akash,
You are more or less right, but there is an exception, we want to replace
tried, the src ip, dst ip and then forward it.
1. receive GTP-U packet from DU
1. 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
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
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 desti
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
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 egr
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
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, wrote:
> Hi Venu,
>
> decap-next supports only 3 parameters I guess .So, If you need an support
> like rea
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 require
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
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 n
12 matches
Mail list logo
