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