[vpp-dev] GTPU tunnel - teid and tteid use case

[Archana Sampath]

Hi Team,

I am trying GTP-U in VPP. I followed the link below
https://docs.fd.io/vpp/19.01/clicmd_src_plugins_gtpu.html .

I have few clarifications
1) With the above configuration ,gtpu_tunne0 is configured with an IP from
subnet  [11.9.0.0/16] which is the peer side network [loop0 -
11.9.0.0/16].In real use case scenario , all UE traffic needs to be passed
via GTPU tunnel . We may not be able to configure peer network's IP on
gtpu .How is it done ?
2) "create gtpu tunnel command has teid and tteid . With this i assume ,
for each User , a separate gtpu tunnel has to created. Is my understanding
correct?
3)Can someone please help me with modification of the above  configuration
for GTPU  multiple users?

 I hope I have searched topics related to GTPU in vpp-dev . WIth latest
addition of teid and tried I assume GTPU tunnels can be used for 3GPP use
case as well and not only for tunnelling (similar to gre).
Kindly advise me on the above points .


Regards,
Archana


-- 

*One* World *One* WiFi

*Archana *
Senior Software Engineer
Mobile: +971 521092016

[image: LinkedIn]

 [image: Facebook]  [image:
Instagram]  [image:
WKHUWISViRFXtgW6eW+QAlAl9vIHAh58+j37yvvtDz4Dyz9gggPGs44wh4cCT5qOoBwvK5pigAADAD69A5LjIG37AElFTkSuQmCC]



Business Bay | Bay Square | Building 6
Off: 105 | Dubai | UAE | P.O. Box 111581
Tel: +971 4 277 1131
*www.ezelink.com* 

[image: signature_778892893] 

*DISCLAIMER:* This message and attached document(s) may contain information
of confidential nature and/or legally protected. if you have received this
message by mistake, please reply to sender, eliminate it from your system
and do not disclose or use.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21768): https://lists.fd.io/g/vpp-dev/message/21768
Mute This Topic: https://lists.fd.io/mt/92830470/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] GTPU Tunnel dst ip update like update tteid support

[Akash S R]

Hey Mates,

I have a requirement in updating the dest IP of the GTPU Tunnel. There is
support on VPP to update the tteid but is there any code patch to update
the dest IP of the GTPU Tunnel?

Please respond if anything known.

/Akash

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20305): https://lists.fd.io/g/vpp-dev/message/20305
Mute This Topic: https://lists.fd.io/mt/86210031/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] GTPu Question

[Govindarajan Mohandoss]

Thanks Andreas !!


From: Andreas Schultz 
Sent: Tuesday, May 26, 2020 4:14 PM
To: Govindarajan Mohandoss 
Cc: vpp-dev@lists.fd.io; nd 
Subject: Re: [vpp-dev] GTPu Question

Hi Govind,

I'm NOT one of the GTPu maintainers, but I do work on a UPF implementation 
based on VPP.

The GTPu plugin is IMHO mostly useless and broken by design in its current 
state. It assumes that TEIDs are symmetric which they never are in real 3GPP 
settings.
There is an outdated change in gerrit (https://gerrit.fd.io/r/c/vpp/+/13134) 
that corrects that and other deficits.

AFAIK there is no GTP-C control interface that can control the GTP-U plugin 
through VPPs binaries API. Only static tunnels through the CLI are doable (I 
have not tested that myself). A real PGW/GGSN is therefore not doable.

The plugin also has no support for 3GPP compliant charging and QoS. This would 
be a major problem in case you want to evaluate performance as those areas are 
the ones that introduce the highest complexity. Performance tests on pure GTP 
encap/decap are IMHO useless for real world GTP use cases.

Regards,
Andreas

Am Di., 26. Mai 2020 um 05:18 Uhr schrieb Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>>:

Dear GTPu Owners,

   I need some help in creating GTPu Origination and Termination config in DUT 
(Running VPP) as described below.



GTPu Origination:



[cid:image005.png@01D63420.3CBD6010]



GTPu Termination:



[cid:image006.png@01D63420.3CBD6010]

Whether GTPu plugin has the support to do such mapping (or) I need to write a 
test plugin to do such mapping ?



I found some information in the below link explaining about GTPu Tunneling.

https://wiki.fd.io/view/VPP/Per-feature_Notes#VRF.2C_Table_Ids_and_Routing

As per the example, foll. are the VPP CLI commands to create a GTPu Tunnel.  
But I don’t follow the commands. Please see inline.



“

loop create

set int state loop0 up

set int ip addr loop0 1.1.1.1/32<http://1.1.1.1/32>   << Can the IP address be 
created on a physical interface connecting the next node in GTPu Origination 
Topology mentioned above ?

create gtpu tunnel src 1.1.1.1 dst 10.6.6.6 teid  decap-next ip4 << What 
does “decap-next” mean ?

set int ip addr gptu_tunnel0 1.1.1.2/31<http://1.1.1.2/31> << Why the IP 
address is assigned to GTPu Tunnel interface ?

“



For the GTPu origination case:

How can I associate the incoming Ethernet traffic to GTPu Tunnel config ?



It will be great if you can share some document / CLI config (or) test case 
which is similar to Origination & Termination topology.



Thanks

Govind



--

Andreas Schultz
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16537): https://lists.fd.io/g/vpp-dev/message/16537
Mute This Topic: https://lists.fd.io/mt/74471469/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] GTPu Question

[Andreas Schultz]

Hi Govind,

I'm NOT one of the GTPu maintainers, but I do work on a UPF implementation
based on VPP.

The GTPu plugin is IMHO mostly useless and broken by design in its current
state. It assumes that TEIDs are symmetric which they never are in real
3GPP settings.
There is an outdated change in gerrit (https://gerrit.fd.io/r/c/vpp/+/13134
) that corrects that and other deficits.

AFAIK there is no GTP-C control interface that can control the GTP-U plugin
through VPPs binaries API. Only static tunnels through the CLI are doable
(I have not tested that myself). A real PGW/GGSN is therefore not doable.

The plugin also has no support for 3GPP compliant charging and QoS. This
would be a major problem in case you want to evaluate performance as those
areas are the ones that introduce the highest complexity. Performance tests
on pure GTP encap/decap are IMHO useless for real world GTP use cases.

Regards,
Andreas

Am Di., 26. Mai 2020 um 05:18 Uhr schrieb Govindarajan Mohandoss <
govindarajan.mohand...@arm.com>:

> Dear GTPu Owners,
>
>I need some help in creating GTPu Origination and Termination config in
> DUT (Running VPP) as described below.
>
>
>
> GTPu Origination:
>
>
>
>
>
> GTPu Termination:
>
>
>
> Whether GTPu plugin has the support to do such mapping (or) I need to
> write a test plugin to do such mapping ?
>
>
>
> I found some information in the below link explaining about GTPu
> Tunneling.
>
> https://wiki.fd.io/view/VPP/Per-feature_Notes#VRF.2C_Table_Ids_and_Routing
>
> As per the example, foll. are the VPP CLI commands to create a GTPu
> Tunnel.  But I don’t follow the commands. Please see inline.
>
>
>
> “
>
> loop create
>
> set int state loop0 up
>
> set int ip addr loop0 1.1.1.1/32   << Can the IP address be created on a
> physical interface connecting the next node in GTPu Origination Topology
> mentioned above ?
>
> create gtpu tunnel src 1.1.1.1 dst 10.6.6.6 teid  decap-next ip4 <<
> What does “decap-next” mean ?
>
> set int ip addr gptu_tunnel0 1.1.1.2/31 << Why the IP address is assigned
> to GTPu Tunnel interface ?
>
> “
>
>
>
> For the GTPu origination case:
>
> How can I associate the incoming Ethernet traffic to GTPu Tunnel config ?
>
>
>
> It will be great if you can share some document / CLI config (or) test
> case which is similar to Origination & Termination topology.
>
>
>
> Thanks
>
> Govind
> 
>


-- 

Andreas Schultz
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16511): https://lists.fd.io/g/vpp-dev/message/16511
Mute This Topic: https://lists.fd.io/mt/74471469/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] GTPu Question

[pashinho1990]

Hi,

I had more or less the same question something like 2 years ago, and guess 
what, to date still no reply whatsoever. I'd think the plugin's developer is 
untraceable and/or "out of duty".
Now back to the question, if I didn't misunderstood this GTPU plugin's 
semantics (by reading the code), this plugin doesn't operate as you'd expect 
from a mobile 3GPP point of view, it actually operates very similarly to how 
VXLAN does.
What this plugin does is mainly implementing a *VTEP (Virtual Tunnel Endpoint)* 
, so its tunnel interface (i.e. gtpu_tunnelX ) needs an IP address on the same 
subnet of the actual destination of the encapped packet (i.e. the T-PDU).
I know, it's somewhat confusing, but I studied and tried it, and I can confirm 
that it works this way. If you still want to really understand and use it, I'd 
suggest you to learn how VXLAN works and its terminology (if you don't know it 
yet), it'll be a lot easier for you to grasp this plugin's operation.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16497): https://lists.fd.io/g/vpp-dev/message/16497
Mute This Topic: https://lists.fd.io/mt/74471469/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] GTPu Question

[Govindarajan Mohandoss]

Dear GTPu Owners,

   I need some help in creating GTPu Origination and Termination config in DUT 
(Running VPP) as described below.



GTPu Origination:



[cid:image002.png@01D632DC.1A086500]



GTPu Termination:



[cid:image004.png@01D632DD.4A324CE0]

Whether GTPu plugin has the support to do such mapping (or) I need to write a 
test plugin to do such mapping ?



I found some information in the below link explaining about GTPu Tunneling.

https://wiki.fd.io/view/VPP/Per-feature_Notes#VRF.2C_Table_Ids_and_Routing

As per the example, foll. are the VPP CLI commands to create a GTPu Tunnel.  
But I don't follow the commands. Please see inline.



"

loop create

set int state loop0 up

set int ip addr loop0 1.1.1.1/32   << Can the IP address be created on a 
physical interface connecting the next node in GTPu Origination Topology 
mentioned above ?

create gtpu tunnel src 1.1.1.1 dst 10.6.6.6 teid  decap-next ip4 << What 
does "decap-next" mean ?

set int ip addr gptu_tunnel0 1.1.1.2/31 << Why the IP address is assigned to 
GTPu Tunnel interface ?

"



For the GTPu origination case:

How can I associate the incoming Ethernet traffic to GTPu Tunnel config ?



It will be great if you can share some document / CLI config (or) test case 
which is similar to Origination & Termination topology.



Thanks

Govind


image001.emz
Description: image001.emz


oledata.mso
Description: oledata.mso


image003.emz
Description: image003.emz
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16484): https://lists.fd.io/g/vpp-dev/message/16484
Mute This Topic: https://lists.fd.io/mt/74471469/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] gtpu: breaking changes proposal: support different source and destination TEIDs

[Nick Zavaritsky]

Hi,

According to 3gpp 29.281, TEIDs used in a GTPU tunnel could be different in 
"up" and "down" direction. At EMnify we depend on this feature.

We developed a patch but it changes API in incompatible ways, excerpt:

@@ -38,8 +39,9 @@ define gtpu_add_del_tunnel
vl_api_interface_index_t mcast_sw_if_index;
u32 encap_vrf_id;
u32 decap_next_index;
-  u32 teid;
-  option vat_help = "src  { dst  | group  { 
 | mcast_sw_if_index  } } teid  [encap-vrf-id ] 
[decap-next ] [del]";
+  u32 src_teid;
+  u32 dst_teid;
+  option vat_help = "src  { dst  | group  { 
 | mcast_sw_if_index  } } src-teid  dst-teid  
[encap-vrf-id ] [decap-next ] [del]";
};

Prior to submitting the patch I'd like to find out if it affects other people 
using GTPU and what would be the preferred way forward.

Best,
Nick
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15561): https://lists.fd.io/g/vpp-dev/message/15561
Mute This Topic: https://lists.fd.io/mt/71569677/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] GTPu

[Kingwel Xie]

Hi,

My colleague Liu Anhua has done the patch:

https://gerrit.fd.io/r/#/c/13134/

Couldn’t add Chengqiang as reviewer, gerrit says he/she can not be identified.

Regards,
Kingwel

From: Ni, Hongjun 
Sent: Friday, June 08, 2018 5:54 PM
To: Edward Warnicke ; Kingwel Xie 
; vpp-dev@lists.fd.io
Cc: Yao, Chengqiang 
Subject: RE: [vpp-dev] GTPu

Thanks Kingwei for your effort on improving GTPU plugin.

Please submit some patches and add 
chengqiang@intel.com<mailto:chengqiang@intel.com> as one of reviewers.

Thanks,
Hongjun

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Edward Warnicke
Sent: Friday, June 8, 2018 10:18 AM
To: Kingwel Xie mailto:kingwel@ericsson.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] GTPu

Please do push a patch :)

Ed


On June 8, 2018 at 4:16:19 AM, Kingwel Xie 
(kingwel@ericsson.com<mailto:kingwel@ericsson.com>) wrote:
Hi all,

We are working on improving gtpu plugin, to make it better comply with 3GPP 
standard.

Here is the brief of what we have done:


  1.  Path management – gtpu-process was added
  2.  Error indication
  3.  Bi-direction TEID
  4.  Some bug fixes

I’m thinking of pushing up-stream the improvement. We can make the patch soon. 
Any comments?

Regards,
Kingwel


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9649): https://lists.fd.io/g/vpp-dev/message/9649
Mute This Topic: https://lists.fd.io/mt/21792620/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] GTPu

[Balaji Shankaran]

@Kingwel
Please add me as one of the reviewer for the patch balajiha...@gmail.com



On Mon, 11 Jun 2018 at 08:09, Kingwel Xie  wrote:

> Well, it would take a dew days. Just realized we have to pass the review
> process in Ericsson…
>
>
>
> Will get it done asap.
>
>
>
> *From:* Ni, Hongjun 
> *Sent:* Friday, June 08, 2018 5:54 PM
> *To:* Edward Warnicke ; Kingwel Xie <
> kingwel@ericsson.com>; vpp-dev@lists.fd.io
> *Cc:* Yao, Chengqiang 
> *Subject:* RE: [vpp-dev] GTPu
>
>
>
> Thanks Kingwei for your effort on improving GTPU plugin.
>
>
>
> Please submit some patches and add chengqiang@intel.com as one of
> reviewers.
>
>
>
> Thanks,
>
> Hongjun
>
>
>
> *From:* vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io
> ] *On Behalf Of *Edward Warnicke
> *Sent:* Friday, June 8, 2018 10:18 AM
> *To:* Kingwel Xie ; vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] GTPu
>
>
>
> Please do push a patch :)
>
>
>
> Ed
>
>
>
> On June 8, 2018 at 4:16:19 AM, Kingwel Xie (kingwel@ericsson.com)
> wrote:
>
> Hi all,
>
>
>
> We are working on improving gtpu plugin, to make it better comply with
> 3GPP standard.
>
>
>
> Here is the brief of what we have done:
>
>
>
>1. Path management – gtpu-process was added
>2. Error indication
>3. Bi-direction TEID
>4. Some bug fixes
>
>
>
> I’m thinking of pushing up-stream the improvement. We can make the patch
> soon. Any comments?
>
>
>
> Regards,
>
> Kingwel
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9580): https://lists.fd.io/g/vpp-dev/message/9580
Mute This Topic: https://lists.fd.io/mt/21792620/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Leave: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] GTPu

[Kingwel Xie]

Well, it would take a dew days. Just realized we have to pass the review 
process in Ericsson…

Will get it done asap.

From: Ni, Hongjun 
Sent: Friday, June 08, 2018 5:54 PM
To: Edward Warnicke ; Kingwel Xie 
; vpp-dev@lists.fd.io
Cc: Yao, Chengqiang 
Subject: RE: [vpp-dev] GTPu

Thanks Kingwei for your effort on improving GTPU plugin.

Please submit some patches and add 
chengqiang@intel.com<mailto:chengqiang@intel.com> as one of reviewers.

Thanks,
Hongjun

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Edward Warnicke
Sent: Friday, June 8, 2018 10:18 AM
To: Kingwel Xie mailto:kingwel@ericsson.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] GTPu

Please do push a patch :)

Ed


On June 8, 2018 at 4:16:19 AM, Kingwel Xie 
(kingwel@ericsson.com<mailto:kingwel@ericsson.com>) wrote:
Hi all,

We are working on improving gtpu plugin, to make it better comply with 3GPP 
standard.

Here is the brief of what we have done:


  1.  Path management – gtpu-process was added
  2.  Error indication
  3.  Bi-direction TEID
  4.  Some bug fixes

I’m thinking of pushing up-stream the improvement. We can make the patch soon. 
Any comments?

Regards,
Kingwel


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9579): https://lists.fd.io/g/vpp-dev/message/9579
Mute This Topic: https://lists.fd.io/mt/21792620/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Leave: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] GTPu

[Ni, Hongjun]

Thanks Kingwei for your effort on improving GTPU plugin.

Please submit some patches and add 
chengqiang@intel.com<mailto:chengqiang@intel.com> as one of reviewers.

Thanks,
Hongjun

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Edward 
Warnicke
Sent: Friday, June 8, 2018 10:18 AM
To: Kingwel Xie ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] GTPu

Please do push a patch :)

Ed


On June 8, 2018 at 4:16:19 AM, Kingwel Xie 
(kingwel@ericsson.com<mailto:kingwel@ericsson.com>) wrote:
Hi all,

We are working on improving gtpu plugin, to make it better comply with 3GPP 
standard.

Here is the brief of what we have done:


  1.  Path management – gtpu-process was added
  2.  Error indication
  3.  Bi-direction TEID
  4.  Some bug fixes

I’m thinking of pushing up-stream the improvement. We can make the patch soon. 
Any comments?

Regards,
Kingwel


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9570): https://lists.fd.io/g/vpp-dev/message/9570
Mute This Topic: https://lists.fd.io/mt/21792620/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Leave: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] GTPu

[Edward Warnicke]

Please do push a patch :)

Ed

On June 8, 2018 at 4:16:19 AM, Kingwel Xie (kingwel@ericsson.com) wrote:

Hi all,



We are working on improving gtpu plugin, to make it better comply with 3GPP
standard.



Here is the brief of what we have done:



   1. Path management – gtpu-process was added
   2. Error indication
   3. Bi-direction TEID
   4. Some bug fixes



I’m thinking of pushing up-stream the improvement. We can make the patch
soon. Any comments?



Regards,

Kingwel


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9569): https://lists.fd.io/g/vpp-dev/message/9569
Mute This Topic: https://lists.fd.io/mt/21792620/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Leave: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] GTPu

[Kingwel Xie]

Hi all,

We are working on improving gtpu plugin, to make it better comply with 3GPP 
standard.

Here is the brief of what we have done:


  1.  Path management – gtpu-process was added
  2.  Error indication
  3.  Bi-direction TEID
  4.  Some bug fixes

I’m thinking of pushing up-stream the improvement. We can make the patch soon. 
Any comments?

Regards,
Kingwel

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9568): https://lists.fd.io/g/vpp-dev/message/9568
Mute This Topic: https://lists.fd.io/mt/21792620/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Leave: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] gtpu ipv4 decap issue

[Andreas Schultz]

Just a note about GTP-U. The implementation uses GTP-U headers to create a
tunnel, it is in no way compatible with "real" 3GPP GTP nodes.
If you just need a tunnel, don't use GTP. There are plenty of other tunnel
protocols (e.g. GRE, VXLAN)  that are more widely used.

If you want to play with GTP, you have to be aware that it makes assumtions
that are not in line with many of the requirements in the 3GPP
specifications, e.g. TEID's are not bidirectional, ingress GTP-U should not
be filtered by source IP, GTP-U endpoints can't be multicast addresses,
Error Indication's and End Markers are unsupported, ... just to name a few.
Getting it to talk to a real EPC GTP node would be really really hard.

Andreas

Ole Troan <otr...@employees.org> schrieb am Do., 15. Feb. 2018 um 12:58 Uhr:

> Instead of assigning the tunnel endpoint address to an interface, it is
> also possible to reserve an IP address to a particular tunnel function, by
> setting the next-index in the corresponding FIB entry/adjacency.
> We typically do this for the mesh type tunnel solutions, were on some of
> the we don't even use interfaces to represent them. Downside is that you
> cannot run any other services on those IP addresses, and e.g. you will not
> respond to ping.
>
> Cheers,
> Ole
>
> > On 15 Feb 2018, at 12:04, Neale Ranns <nra...@cisco.com> wrote:
> >
> > Hi Jakub,
> >
> > A quick refresher on IP Addressing J
> >
> > In the world or tunnels we typically talk about the underlay and the
> overlay. The underlay will contain the addresses that form the tunnel’s
> source and destination address (the addresses one sees in the outer IP
> header) – i.e. the address in ‘create gtpu tunnel …’. The overlay contains
> the address configured on the tunnel interface, that is used for routing
> via the tunnel – i.e. the address in ‘set int ip addr gtpu_tunnel0 …’.
> > The tunnel’s source address and interface address should not be the
> same, if they were then if the tunnel were to go down (say a keep-alive
> mechanism failed) then the tunnel’s interface address is removed from the
> FIB and hence the tunnel’s source address is no longer reachable and hence
> it can never receive more packets and consequently never come back up.
> > Instead one chooses the tunnel’s source address to be an address
> configured on another interface in the underlay. This could be a physical
> interface, usually the interface over which the tunnel destination is
> reachable, or a loopback. The downside of using a physical interface is if
> that physical goes down, then again the tunnel is unreachable, despite
> perhaps there being an alternate from the peer to VPP. The benefit of using
> a loopback is that these never go down. So, to configure the underlay do;
> >   loop create
> >   set int sate loop0 up
> >   set int ip addr loop0 1.1.1.1/32
> > note my use of a /32 as the loopback’s interface address. This is
> possible since one cannot connect peers to a loopback, hence the network
> comprises only one device.
> >
> > Next create some tunnels using the loopback’s interface address as the
> tunnel source;
> >   create gtpu tunnel src 1.1.1.1 dst 10.6.6.6 teid  decap-next ip4
> >   create gtpu tunnel src 1.1.1.1 dst 10.6.6.6 teid 1112 decap-next ip4
> >   create gtpu tunnel src 1.1.1.1 dst 10.6.6.6 teid 1113 decap-next ip4
> >
> > Now for the overlay addressing. Here we have choices. Firstly, we can
> assign each of the tunnel’s their own overlay address:
> >   set int ip addr gptu_tunnel0 1.1.1.2/31
> >   set int ip addr gptu_tunnel1 1.1.1.4/31
> >   set int ip addr gptu_tunnel2 1.1.1.6/31
> > note the use of a /31. GTPU tunnels are point-to-point, so we only need
> 2 address, one for us, one for the peer.
> > Or secondly, we can use the same address for each of the tunnels, if we
> make them unnumbered.
> >   loop create
> >   set int sate loop1 up
> >   set int ip addr loop1 1.1.1.2/31
> >   set int unnumbered gtpu_tunnel0 use loop1
> >   set int unnumbered gtpu_tunnel1 use loop1
> >   set int unnumbered gtpu_tunnel2 use loop1
> >
> > hope that helps,
> > neale
> >
> >
> >> From: <vpp-dev@lists.fd.io> on behalf of "Jakub Horn (jakuhorn)" <
> jakuh...@cisco.com>
> >> Date: Wednesday, 14 February 2018 at 23:35
> >> To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
> >> Subject: [vpp-dev] gtpu ipv4 decap issue
> >>
> >> Hi,
> >>
> >> To assign ipv4 decap for GTPu tunnel we need to assign IPv4 address to
> the tunnel:
> >> set interface ip address gtpu_tunnel0 10.9.9.9/24
> >>
> >> but we cann

Re: [vpp-dev] gtpu ipv4 decap issue

[Neale Ranns]

Hi Jakub,

A quick refresher on IP Addressing ☺

In the world or tunnels we typically talk about the underlay and the overlay. 
The underlay will contain the addresses that form the tunnel’s source and 
destination address (the addresses one sees in the outer IP header) – i.e. the 
address in ‘create gtpu tunnel …’. The overlay contains the address configured 
on the tunnel interface, that is used for routing via the tunnel – i.e. the 
address in ‘set int ip addr gtpu_tunnel0 …’.
The tunnel’s source address and interface address should not be the same, if 
they were then if the tunnel were to go down (say a keep-alive mechanism 
failed) then the tunnel’s interface address is removed from the FIB and hence 
the tunnel’s source address is no longer reachable and hence it can never 
receive more packets and consequently never come back up.
Instead one chooses the tunnel’s source address to be an address configured on 
another interface in the underlay. This could be a physical interface, usually 
the interface over which the tunnel destination is reachable, or a loopback. 
The downside of using a physical interface is if that physical goes down, then 
again the tunnel is unreachable, despite perhaps there being an alternate from 
the peer to VPP. The benefit of using a loopback is that these never go down. 
So, to configure the underlay do;
  loop create
  set int sate loop0 up
  set int ip addr loop0 1.1.1.1/32
note my use of a /32 as the loopback’s interface address. This is possible 
since one cannot connect peers to a loopback, hence the network comprises only 
one device.

Next create some tunnels using the loopback’s interface address as the tunnel 
source;
  create gtpu tunnel src 1.1.1.1 dst 10.6.6.6 teid  decap-next ip4
  create gtpu tunnel src 1.1.1.1 dst 10.6.6.6 teid 1112 decap-next ip4
  create gtpu tunnel src 1.1.1.1 dst 10.6.6.6 teid 1113 decap-next ip4

Now for the overlay addressing. Here we have choices. Firstly, we can assign 
each of the tunnel’s their own overlay address:
  set int ip addr gptu_tunnel0 1.1.1.2/31
  set int ip addr gptu_tunnel1 1.1.1.4/31
  set int ip addr gptu_tunnel2 1.1.1.6/31
note the use of a /31. GTPU tunnels are point-to-point, so we only need 2 
address, one for us, one for the peer.
Or secondly, we can use the same address for each of the tunnels, if we make 
them unnumbered.
  loop create
  set int sate loop1 up
  set int ip addr loop1 1.1.1.2/31
  set int unnumbered gtpu_tunnel0 use loop1
  set int unnumbered gtpu_tunnel1 use loop1
  set int unnumbered gtpu_tunnel2 use loop1

hope that helps,
neale


From: <vpp-dev@lists.fd.io> on behalf of "Jakub Horn (jakuhorn)" 
<jakuh...@cisco.com>
Date: Wednesday, 14 February 2018 at 23:35
To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: [vpp-dev] gtpu ipv4 decap issue

Hi,

To assign ipv4 decap for GTPu tunnel we need to assign IPv4 address to the 
tunnel:
set interface ip address gtpu_tunnel0 10.9.9.9/24

but we cannot assign same address to more than one GTPu tunnel.
But if there are more than one tunnel (same SRC, same DST) differs but only by 
TEID we cannot do that

Then secondary tunnels does not decapsulate GTP packets!!!


create gtpu tunnel src 10.9.9.9 dst 10.6.6.6 teid  decap-next ip4
ip route add 10.1.1.1/32 via gtpu_tunnel0
set interface ip address gtpu_tunnel0 10.9.9.9/24

create gtpu tunnel src 10.9.9.9 dst 10.6.6.6 teid  decap-next ip4
ip route add 10.2.2.1/32 via gtpu_tunnel1


Is there any other way to make GTP tunnel to decapsulate packet based on DST IP 
address of outer packet?

Thanks a lot in advance

Jakub

[vpp-dev] gtpu ipv4 decap issue

[Jakub Horn (jakuhorn)]

Hi,

To assign ipv4 decap for GTPu tunnel we need to assign IPv4 address to the 
tunnel:
set interface ip address gtpu_tunnel0 10.9.9.9/24

but we cannot assign same address to more than one GTPu tunnel.
But if there are more than one tunnel (same SRC, same DST) differs but only by 
TEID we cannot do that

Then secondary tunnels does not decapsulate GTP packets!!!


create gtpu tunnel src 10.9.9.9 dst 10.6.6.6 teid  decap-next ip4
ip route add 10.1.1.1/32 via gtpu_tunnel0
set interface ip address gtpu_tunnel0 10.9.9.9/24

create gtpu tunnel src 10.9.9.9 dst 10.6.6.6 teid  decap-next ip4
ip route add 10.2.2.1/32 via gtpu_tunnel1


Is there any other way to make GTP tunnel to decapsulate packet based on DST IP 
address of outer packet?

Thanks a lot in advance

Jakub

Re: [vpp-dev] gtpu tunneling decap-next ip4 issue

[Ryota Yushina]

Hi, Neale-san,

Thank you for your great advice.
Once I configured IPv4 address at both gtpu_tunnels, it worked with "ip4" 
option.

---
Best Regards,

Ryota Yushina,


> -Original Message-
> From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
> Sent: Monday, November 06, 2017 6:57 PM
> To: Yushina Ryota(油科 亮太) <r-yush...@ce.jp.nec.com>; Ni, Hongjun 
> <hongjun...@intel.com>; vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] gtpu tunneling decap-next ip4 issue
> 
> 
> Hi Ryota-san,
> 
> I glad it works now. I couple of comments, marked [nr], on your setup are 
> inline below.
> 
> Regards,
> neale
> 
> -Original Message-
> From: Ryota Yushina <r-yush...@ce.jp.nec.com>
> Date: Monday, 6 November 2017 at 10:12
> To: "Ni, Hongjun" <hongjun...@intel.com>, "Neale Ranns (nranns)" 
> <nra...@cisco.com>, "vpp-dev@lists.fd.io"
> <vpp-dev@lists.fd.io>
> Subject: RE: [vpp-dev] gtpu tunneling decap-next ip4 issue
> 
> 
> To Hongjon-san, Neale-san
> 
> Thank you so much for your great help. This patch solved the problem!
> ICMP packets were encapped and routed to target.
> As your discussion, vpp crashed at accessing gtpu_tunnel soruce mac 
> address pointer(=null).
> 
> 
> Below is just my memo.
> 
> I faced a new issue.
> An decapped IP4 packet(inner ip4 packet) was through to "ip4-drop" via 
> "ip4-input" from "gtpu4-input" on
> GTPu-endpoint(recv).
> My expected graph flow was "gtpu4-input" -> "ip4-input" -> "ip4-lookup" 
> -> ...
> 
> So I created gtpu tunnel with following uses "node ip4-lookup" option 
> instead of "ip4".
> # create gtpu tunnel src 192.168.152.70 dst 192.168.152.40 teid  
> encap-vrf-id 152 decap-next node ip4-lookup
> 
> It worked fine.
> 
> Followngs are my final configurations. Ping from vpp#3 returned from 
> vpp#4 via vpp#7.
> <vpp#3>
>   set interface ip address TenGigabitEthernet82/0/1 10.9.0.3/16
>   ip route 11.9.0.0/16 via 10.9.0.1
>   set interface state TenGigabitEthernet82/0/1 up
> 
> <vpp#7>
>   set interface ip address TenGigabitEthernet82/0/1 10.9.0.1/16
>   set interface ip table TenGigabitEthernet82/0/0 152
>   set interface ip address TenGigabitEthernet82/0/0 192.168.152.70/24
>   create gtpu tunnel src 192.168.152.70 dst 192.168.152.40 teid  
> encap-vrf-id 152 decap-next node ip4-lookup
>   set interface ip address gtpu_tunnel0 11.9.0.1/16
>   ip route 11.9.0.0/16 via gtpu_tunnel0
> 
> [nr] Having applied the subnet 11.9.0.0/16 to the GTPu interface, this route 
> is unnecessary and in fact unused, since
> the interface configuration takes precedence. If you do ‘sh ip fib 
> 11.9.0.0/16’ you should see both the ‘src:interface’
> and ‘src:CLI’.
> 
>   ip route 10.9.0.0/16 via TenGigabitEthernet82/0/1
>   set interface state TenGigabitEthernet82/0/1 up
>   set interface state TenGigabitEthernet82/0/0 up
> 
> <vpp#4>
>   set interface ip table TenGigabitEthernet82/0/0 152
>   set interface ip address TenGigabitEthernet82/0/0 192.168.152.40/24
>   create gtpu tunnel src 192.168.152.40 dst 192.168.152.70 teid  
> encap-vrf-id 152 decap-next node ip4-lookup
>   create loopback interaface
>   set interface ip address loop0 11.9.0.0.4/16
> 
> [nr] because you applied the 11.9.0.0/16 subnet to the loopback interface, 
> there is no subnet configured on the GTP-u
> interface. Any interface type that does not have a configured IPv4 address 
> cannot accept IPv4 traffic – that’s a basic
> security feature. Packets arriving on such an interface will be dropped just 
> after ip4-input. If you were to apply the
> subnet on the GTP-u interface instead, then you would be able to revert your 
> GTP-u tunnel decap-node configuration to
> perform ip4-input. This would be preferred since the decapsulated IP packets 
> would then be subject to the usual input
> checks (i.e. TTL, chksum, etc).
> 
>   ip route 10.9.0.0/16 via gtpu_tunnel0
>   set interface state TenGigabitEthernet82/0/0 up
>   set interface state loop0 up
> 
> > +- VPP#3 -
> > |
> > | [TenGigabitEthernet82/0/1: 10.9.0.3]
> > +-- | 
> > |
> > +-VPP#7 | 
> > | [TenGigabitEthernet82/0/1: 10.9.0.1]
> > |
> > | [gtpu_tunnel0: 11.9.0.1]
> > |   |
> > | [TenGi

Re: [vpp-dev] gtpu tunneling decap-next ip4 issue

[Neale Ranns (nranns)]

Hi Ryota-san,

I glad it works now. I couple of comments, marked [nr], on your setup are 
inline below.

Regards,
neale

-Original Message-
From: Ryota Yushina <r-yush...@ce.jp.nec.com>
Date: Monday, 6 November 2017 at 10:12
To: "Ni, Hongjun" <hongjun...@intel.com>, "Neale Ranns (nranns)" 
<nra...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: RE: [vpp-dev] gtpu tunneling decap-next ip4 issue


To Hongjon-san, Neale-san

Thank you so much for your great help. This patch solved the problem!
ICMP packets were encapped and routed to target. 
As your discussion, vpp crashed at accessing gtpu_tunnel soruce mac address 
pointer(=null).


Below is just my memo.

I faced a new issue.
An decapped IP4 packet(inner ip4 packet) was through to "ip4-drop" via 
"ip4-input" from "gtpu4-input" on GTPu-endpoint(recv).
My expected graph flow was "gtpu4-input" -> "ip4-input" -> "ip4-lookup" -> 
...

So I created gtpu tunnel with following uses "node ip4-lookup" option 
instead of "ip4".
# create gtpu tunnel src 192.168.152.70 dst 192.168.152.40 teid  
encap-vrf-id 152 decap-next node ip4-lookup

It worked fine.

Followngs are my final configurations. Ping from vpp#3 returned from vpp#4 
via vpp#7.
<vpp#3>
set interface ip address TenGigabitEthernet82/0/1 10.9.0.3/16
ip route 11.9.0.0/16 via 10.9.0.1
set interface state TenGigabitEthernet82/0/1 up

<vpp#7>
set interface ip address TenGigabitEthernet82/0/1 10.9.0.1/16
set interface ip table TenGigabitEthernet82/0/0 152
set interface ip address TenGigabitEthernet82/0/0 192.168.152.70/24
create gtpu tunnel src 192.168.152.70 dst 192.168.152.40 teid  
encap-vrf-id 152 decap-next node ip4-lookup
set interface ip address gtpu_tunnel0 11.9.0.1/16
ip route 11.9.0.0/16 via gtpu_tunnel0

[nr] Having applied the subnet 11.9.0.0/16 to the GTPu interface, this route is 
unnecessary and in fact unused, since the interface configuration takes 
precedence. If you do ‘sh ip fib 11.9.0.0/16’ you should see both the 
‘src:interface’ and ‘src:CLI’.

ip route 10.9.0.0/16 via TenGigabitEthernet82/0/1
set interface state TenGigabitEthernet82/0/1 up
set interface state TenGigabitEthernet82/0/0 up

<vpp#4>
set interface ip table TenGigabitEthernet82/0/0 152
set interface ip address TenGigabitEthernet82/0/0 192.168.152.40/24
create gtpu tunnel src 192.168.152.40 dst 192.168.152.70 teid  
encap-vrf-id 152 decap-next node ip4-lookup
create loopback interaface
set interface ip address loop0 11.9.0.0.4/16

[nr] because you applied the 11.9.0.0/16 subnet to the loopback interface, 
there is no subnet configured on the GTP-u interface. Any interface type that 
does not have a configured IPv4 address cannot accept IPv4 traffic – that’s a 
basic security feature. Packets arriving on such an interface will be dropped 
just after ip4-input. If you were to apply the subnet on the GTP-u interface 
instead, then you would be able to revert your GTP-u tunnel decap-node 
configuration to perform ip4-input. This would be preferred since the 
decapsulated IP packets would then be subject to the usual input checks (i.e. 
TTL, chksum, etc).

ip route 10.9.0.0/16 via gtpu_tunnel0
set interface state TenGigabitEthernet82/0/0 up
set interface state loop0 up

> +- VPP#3 -
> |
> | [TenGigabitEthernet82/0/1: 10.9.0.3]
> +-- | 
> |
> +-VPP#7 | 
> | [TenGigabitEthernet82/0/1: 10.9.0.1]
> |
> | [gtpu_tunnel0: 11.9.0.1]
> |   |
> | [TenGigabitEthernet82/0/0: 192.168.152.70] --> vrf:152
> +-- || ---
> ||
> +-- || ---
> | [TenGigabitEthernet82/0/0: 192.168.152.40] --> vrf:152
> |
> | [loop0: 11.9.0.4]
> +- VPP#4 -

---
Best Regards,

Ryota Yushina,
NEC




> -Original Message-
> From: Ni, Hongjun [mailto:hongjun...@intel.com]
> Sent: Friday, November 03, 2017 10:50 AM
> To: Neale Ranns (nranns) <nra...@cisco.com>; Yushina Ryota(油科 亮太) 
<r-yush...@ce.jp.nec.com>; vpp-dev@lists.fd.io
> Subject: RE: [vpp-dev] gtpu tunneling decap-next ip4 issue
> 
> To Neale,
> Thank you for reminding. Have submitted a patch to fix it. 
https://gerrit.fd.io/r/#/c/9207/
> 
> To Ryota,
&g

Re: [vpp-dev] gtpu tunneling decap-next ip4 issue

[Ryota Yushina]

To Hongjon-san, Neale-san

Thank you so much for your great help. This patch solved the problem!
ICMP packets were encapped and routed to target. 
As your discussion, vpp crashed at accessing gtpu_tunnel soruce mac address 
pointer(=null).


Below is just my memo.

I faced a new issue.
An decapped IP4 packet(inner ip4 packet) was through to "ip4-drop" via 
"ip4-input" from "gtpu4-input" on GTPu-endpoint(recv).
My expected graph flow was "gtpu4-input" -> "ip4-input" -> "ip4-lookup" -> ...

So I created gtpu tunnel with following uses "node ip4-lookup" option instead 
of "ip4".
# create gtpu tunnel src 192.168.152.70 dst 192.168.152.40 teid  
encap-vrf-id 152 decap-next node ip4-lookup

It worked fine.

Followngs are my final configurations. Ping from vpp#3 returned from vpp#4 via 
vpp#7.
<vpp#3>
set interface ip address TenGigabitEthernet82/0/1 10.9.0.3/16
ip route 11.9.0.0/16 via 10.9.0.1
set interface state TenGigabitEthernet82/0/1 up

<vpp#7>
set interface ip address TenGigabitEthernet82/0/1 10.9.0.1/16
set interface ip table TenGigabitEthernet82/0/0 152
set interface ip address TenGigabitEthernet82/0/0 192.168.152.70/24
create gtpu tunnel src 192.168.152.70 dst 192.168.152.40 teid  
encap-vrf-id 152 decap-next node ip4-lookup
set interface ip address gtpu_tunnel0 11.9.0.1/16
ip route 11.9.0.0/16 via gtpu_tunnel0
ip route 10.9.0.0/16 via TenGigabitEthernet82/0/1
set interface state TenGigabitEthernet82/0/1 up
set interface state TenGigabitEthernet82/0/0 up

<vpp#4>
set interface ip table TenGigabitEthernet82/0/0 152
set interface ip address TenGigabitEthernet82/0/0 192.168.152.40/24
create gtpu tunnel src 192.168.152.40 dst 192.168.152.70 teid  
encap-vrf-id 152 decap-next node ip4-lookup
create loopback interaface
set interface ip address loop0 11.9.0.0.4/16
ip route 10.9.0.0/16 via gtpu_tunnel0
set interface state TenGigabitEthernet82/0/0 up
set interface state loop0 up

> +- VPP#3 -
> |
> | [TenGigabitEthernet82/0/1: 10.9.0.3]
> +-- | 
> |
> +-VPP#7 | 
> | [TenGigabitEthernet82/0/1: 10.9.0.1]
> |
> | [gtpu_tunnel0: 11.9.0.1]
> |   |
> | [TenGigabitEthernet82/0/0: 192.168.152.70] --> vrf:152
> +-- || ---
> ||
> +-- || ---
> | [TenGigabitEthernet82/0/0: 192.168.152.40] --> vrf:152
> |
> | [loop0: 11.9.0.4]
> +- VPP#4 -

---
Best Regards,

Ryota Yushina,
NEC




> -Original Message-
> From: Ni, Hongjun [mailto:hongjun...@intel.com]
> Sent: Friday, November 03, 2017 10:50 AM
> To: Neale Ranns (nranns) <nra...@cisco.com>; Yushina Ryota(油科 亮太) 
> <r-yush...@ce.jp.nec.com>; vpp-dev@lists.fd.io
> Subject: RE: [vpp-dev] gtpu tunneling decap-next ip4 issue
> 
> To Neale,
> Thank you for reminding. Have submitted a patch to fix it. 
> https://gerrit.fd.io/r/#/c/9207/
> 
> To Ryota,
> Now below arp configuration for gtpu tunnel is not needed:
> set ip arp gtpu_tunnel0 192.168.50.70 90e2.ba48.7a70
> 
> -Hongjun
> 
> -Original Message-----
> From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
> Sent: Thursday, November 2, 2017 8:36 PM
> To: Ni, Hongjun <hongjun...@intel.com>; Ryota Yushina 
> <r-yush...@ce.jp.nec.com>; vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] gtpu tunneling decap-next ip4 issue
> 
> 
> Hi Hongjun,
> 
> We need an ARP entry on the tunnel interface? That’s not great. If a GTPu 
> interface is point to point we should set the
> flags:
> 
> VNET_HW_INTERFACE_CLASS (gtpu_hw_class) = { …
>   .flags = VNET_HW_INTERFACE_CLASS_FLAG_P2P, };
> 
> A P2P interface is expected to provide a ‘complete’, i.e. a fully formed, 
> rewrite string, hence there’s no need for ARP.
> 
> /neale
> 
> -Original Message-
> From: <vpp-dev-boun...@lists.fd.io> on behalf of "Ni, Hongjun" 
> <hongjun...@intel.com>
> Date: Thursday, 2 November 2017 at 12:46
> To: Ryota Yushina <r-yush...@ce.jp.nec.com>, "vpp-dev@lists.fd.io" 
> <vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] gtpu tunneling decap-next ip4 issue
> 
> Hi Ryota,
> 
> Below is my configuration to test GTP-U encapsulation for your reference:
> 
> set int state TenGigabitEthernet5/0/0 up
> set int ip table TenGigabitEthernet5/0/0 0
> set int ip address TenGigabitEthernet5/0/0 192.168.50.72/24
> i

Re: [vpp-dev] gtpu tunneling decap-next ip4 issue

[Ni, Hongjun]

To Neale,
Thank you for reminding. Have submitted a patch to fix it. 
https://gerrit.fd.io/r/#/c/9207/

To Ryota,
Now below arp configuration for gtpu tunnel is not needed:
set ip arp gtpu_tunnel0 192.168.50.70 90e2.ba48.7a70

-Hongjun

-Original Message-
From: Neale Ranns (nranns) [mailto:nra...@cisco.com] 
Sent: Thursday, November 2, 2017 8:36 PM
To: Ni, Hongjun <hongjun...@intel.com>; Ryota Yushina 
<r-yush...@ce.jp.nec.com>; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] gtpu tunneling decap-next ip4 issue


Hi Hongjun,

We need an ARP entry on the tunnel interface? That’s not great. If a GTPu 
interface is point to point we should set the flags:

VNET_HW_INTERFACE_CLASS (gtpu_hw_class) = { …
  .flags = VNET_HW_INTERFACE_CLASS_FLAG_P2P, };

A P2P interface is expected to provide a ‘complete’, i.e. a fully formed, 
rewrite string, hence there’s no need for ARP.

/neale

-Original Message-
From: <vpp-dev-boun...@lists.fd.io> on behalf of "Ni, Hongjun" 
<hongjun...@intel.com>
Date: Thursday, 2 November 2017 at 12:46
To: Ryota Yushina <r-yush...@ce.jp.nec.com>, "vpp-dev@lists.fd.io" 
<vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] gtpu tunneling decap-next ip4 issue

Hi Ryota,

Below is my configuration to test GTP-U encapsulation for your reference:

set int state TenGigabitEthernet5/0/0 up
set int ip table TenGigabitEthernet5/0/0 0
set int ip address TenGigabitEthernet5/0/0 192.168.50.72/24
ip route add 192.168.50.71/24 via 192.168.50.72 TenGigabitEthernet5/0/0
set ip arp TenGigabitEthernet5/0/0 192.168.50.71 90e2.ba48.7a71

set int state TenGigabitEthernet5/0/1 up
set int ip table TenGigabitEthernet5/0/1 0
set int ip address TenGigabitEthernet5/0/1 192.168.50.73/24
ip route add 192.168.50.74/24 via 192.168.50.73 TenGigabitEthernet5/0/1
set ip arp TenGigabitEthernet5/0/1 192.168.50.74 90e2.ba48.7a74

create gtpu tunnel src 192.168.50.72 dst 192.168.50.71 teid 9 encap-vrf-id 0

set int ip address gtpu_tunnel0 192.168.50.75/24
ip route add 192.168.50.70/24 via gtpu_tunnel0
set ip arp gtpu_tunnel0 192.168.50.70 90e2.ba48.7a70

-Hongjun

-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Ryota Yushina
Sent: Thursday, November 2, 2017 1:04 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] gtpu tunneling decap-next ip4 issue

Hi, all

Let me ask about a GTPu issue.

Although I tried to overlay IPv4 packets with GTP-u, it didn't work by 
17.10.
Actually vpp was rebooted silently when I sent ping.

Could someone help or provide GTPu IPv4 sample configuration ?

My situation:
By following diagram, when I sent ping from 10.9.0.3 to 11.9.0.4 on VPP#3, 
VPP#7 was rebooted(or crashed?).
I've expected icmp echo request would be routed and encapped on VPP#4 via 
gtpu_tunnel0, but it didn't.


+- VPP#3 -
|
| [TenGigabitEthernet82/0/1: 10.9.0.3]
+-- | 
|
+-VPP#7 | 
| [TenGigabitEthernet82/0/1: 10.9.0.1]
|
| [gtpu_tunnel0: 11.9.0.1]
|   |
| [TenGigabitEthernet82/0/0: 192.168.152.70] --> vrf:152
+-- || ---
||
+-- || ---
| [TenGigabitEthernet82/0/0: 192.168.152.40] --> vrf:152
|
| [loop0: 11.9.0.4]
+- VPP#4 -

My cli configurations:
<<VPP#3>>
set interface ip address TenGigabitEthernet82/0/1 10.9.0.3/16 ip route 
11.9.0.0/16 via 10.9.0.1 set interface state TenGigabitEthernet82/0/1 up

<<VPP#7>>
set interface ip address TenGigabitEthernet82/0/1 10.9.0.1/16

ip table add 152
set interface ip table TenGigabitEthernet82/0/0 152 set interface ip 
address TenGigabitEthernet82/0/0 192.168.152.70/24

create gtpu tunnel src 192.168.152.70 dst 192.168.152.40 teid  
encap-vrf-id 152 decap-next ip4 set interface ip address gtpu_tunnel0 
11.9.0.1/16

ip route 11.9.0.0/16 via gtpu_tunnel0
ip route 10.9.0.0/16 via TenGigabitEthernet82/0/1

set interface state TenGigabitEthernet82/0/0 up set interface state 
TenGigabitEthernet82/0/1 up set interface state loop0 up


Thanks.
---
Best Regards,

Ryota Yushina,

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] gtpu tunneling decap-next ip4 issue

[Ni, Hongjun]

Hi Ryota,

Below is my configuration to test GTP-U encapsulation for your reference:

set int state TenGigabitEthernet5/0/0 up
set int ip table TenGigabitEthernet5/0/0 0
set int ip address TenGigabitEthernet5/0/0 192.168.50.72/24
ip route add 192.168.50.71/24 via 192.168.50.72 TenGigabitEthernet5/0/0
set ip arp TenGigabitEthernet5/0/0 192.168.50.71 90e2.ba48.7a71

set int state TenGigabitEthernet5/0/1 up
set int ip table TenGigabitEthernet5/0/1 0
set int ip address TenGigabitEthernet5/0/1 192.168.50.73/24
ip route add 192.168.50.74/24 via 192.168.50.73 TenGigabitEthernet5/0/1
set ip arp TenGigabitEthernet5/0/1 192.168.50.74 90e2.ba48.7a74

create gtpu tunnel src 192.168.50.72 dst 192.168.50.71 teid 9 encap-vrf-id 0

set int ip address gtpu_tunnel0 192.168.50.75/24
ip route add 192.168.50.70/24 via gtpu_tunnel0
set ip arp gtpu_tunnel0 192.168.50.70 90e2.ba48.7a70

-Hongjun

-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Ryota Yushina
Sent: Thursday, November 2, 2017 1:04 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] gtpu tunneling decap-next ip4 issue

Hi, all

Let me ask about a GTPu issue.

Although I tried to overlay IPv4 packets with GTP-u, it didn't work by 17.10.
Actually vpp was rebooted silently when I sent ping.

Could someone help or provide GTPu IPv4 sample configuration ?

My situation:
By following diagram, when I sent ping from 10.9.0.3 to 11.9.0.4 on VPP#3, 
VPP#7 was rebooted(or crashed?).
I've expected icmp echo request would be routed and encapped on VPP#4 via 
gtpu_tunnel0, but it didn't.


+- VPP#3 -
|
| [TenGigabitEthernet82/0/1: 10.9.0.3]
+-- | 
|
+-VPP#7 | 
| [TenGigabitEthernet82/0/1: 10.9.0.1]
|
| [gtpu_tunnel0: 11.9.0.1]
|   |
| [TenGigabitEthernet82/0/0: 192.168.152.70] --> vrf:152
+-- || ---
||
+-- || ---
| [TenGigabitEthernet82/0/0: 192.168.152.40] --> vrf:152
|
| [loop0: 11.9.0.4]
+- VPP#4 -

My cli configurations:
<<VPP#3>>
set interface ip address TenGigabitEthernet82/0/1 10.9.0.3/16 ip route 
11.9.0.0/16 via 10.9.0.1 set interface state TenGigabitEthernet82/0/1 up

<<VPP#7>>
set interface ip address TenGigabitEthernet82/0/1 10.9.0.1/16

ip table add 152
set interface ip table TenGigabitEthernet82/0/0 152 set interface ip address 
TenGigabitEthernet82/0/0 192.168.152.70/24

create gtpu tunnel src 192.168.152.70 dst 192.168.152.40 teid  encap-vrf-id 
152 decap-next ip4 set interface ip address gtpu_tunnel0 11.9.0.1/16

ip route 11.9.0.0/16 via gtpu_tunnel0
ip route 10.9.0.0/16 via TenGigabitEthernet82/0/1

set interface state TenGigabitEthernet82/0/0 up set interface state 
TenGigabitEthernet82/0/1 up set interface state loop0 up


Thanks.
---
Best Regards,

Ryota Yushina,

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] gtpu tunneling decap-next ip4 issue

[Ryota Yushina]

Hi, all

Let me ask about a GTPu issue.

Although I tried to overlay IPv4 packets with GTP-u, it didn't work by 17.10.
Actually vpp was rebooted silently when I sent ping.

Could someone help or provide GTPu IPv4 sample configuration ?

My situation:
By following diagram, when I sent ping from 10.9.0.3 to 11.9.0.4 on VPP#3, 
VPP#7 was rebooted(or crashed?).
I've expected icmp echo request would be routed and encapped on VPP#4 via 
gtpu_tunnel0, but it didn't.


+- VPP#3 -
|
| [TenGigabitEthernet82/0/1: 10.9.0.3] 
+-- | 
|
+-VPP#7 | 
| [TenGigabitEthernet82/0/1: 10.9.0.1]
|
| [gtpu_tunnel0: 11.9.0.1]
|   |
| [TenGigabitEthernet82/0/0: 192.168.152.70] --> vrf:152 
+-- || ---
||
+-- || ---
| [TenGigabitEthernet82/0/0: 192.168.152.40] --> vrf:152 
|
| [loop0: 11.9.0.4]
+- VPP#4 -

My cli configurations:
<>
set interface ip address TenGigabitEthernet82/0/1 10.9.0.3/16
ip route 11.9.0.0/16 via 10.9.0.1
set interface state TenGigabitEthernet82/0/1 up

<>
set interface ip address TenGigabitEthernet82/0/1 10.9.0.1/16

ip table add 152
set interface ip table TenGigabitEthernet82/0/0 152
set interface ip address TenGigabitEthernet82/0/0 192.168.152.70/24

create gtpu tunnel src 192.168.152.70 dst 192.168.152.40 teid  encap-vrf-id 
152 decap-next ip4
set interface ip address gtpu_tunnel0 11.9.0.1/16

ip route 11.9.0.0/16 via gtpu_tunnel0
ip route 10.9.0.0/16 via TenGigabitEthernet82/0/1

set interface state TenGigabitEthernet82/0/0 up
set interface state TenGigabitEthernet82/0/1 up
set interface state loop0 up


Thanks.
---
Best Regards,

Ryota Yushina,



smime.p7s
Description: S/MIME cryptographic signature
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev