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 >> >> >> > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#8233): https://lists.fd.io/g/vpp-dev/message/8233 View All Messages In Topic (3): https://lists.fd.io/g/vpp-dev/topic/11431817 Mute This Topic: https://lists.fd.io/mt/11431817/21656 New Topic: https://lists.fd.io/g/vpp-dev/post Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656 Group Home: https://lists.fd.io/g/vpp-dev Contact Group Owner: vpp-dev+ow...@lists.fd.io Terms of Service: https://lists.fd.io/static/tos Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub -=-=-=-=-=-=-=-=-=-=-=-
signature.asc
Description: Message signed with OpenPGP
