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 1111 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 1111 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 2222 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 > >> > >> > >> > > > > > > >
