0

Linux now support lightweight tunnels https://lwn.net/Articles/650778/ which means tunnel configured on the routes (so no need to set up one interface by tunnel).

But unfortunately I did not manage to find much documentation on them. In the patch series linked above, the syntax is ip route add 40.1.1.1/32 encap vxlan id 10 dst 50.1.1.2 dev vxlan0.

But on my current iproute-5.2.0, there is no encap vxlan, only encap ip id ... (with mpls, bpf, seg6...). It looks like the encap type is detected automatically according to the device. So instead of doing

   $ ip link add dev vxlan1 type vxlan id 30001 remote 20.1.1.2 dstport 4789
   $ ip link set dev vxlan1 up
   $ ip addr add 20.1.1.1/24 dev vxlan1
   $ ip route add 10.1.1.1 dev vxlan1

we can do instead

   $ ip link add vxlan1 type vxlan dstport 4789 external
   $ ip link set dev vxlan1 up
   $ ip addr add 20.1.1.1/24 dev vxlan1
   $ ip route add 10.1.1.1 encap ip id 30001 dst 20.1.1.2 dev vxlan1

This gives the following route:

10.1.1.1  encap ip id 30001 src 0.0.0.0 dst 20.1.1.2 ttl 0 tos 0 dev vxlan1 scope link

(I am not sure what the src 0.0.0.0 means in this case.)

So the advantage here is that we can set up one vxlan interface, and configure different routes with different vxlan id and enpoints (but unfortunately there does not seem a way to change the dstport by route).

But what I don't quite understand how this is supposed to work for ipip and gre/gretap tunnels. The only documentation I managed to find, is in chinese https://linux.cn/article-10672-1.html where they use these commands for a gre-tap:

    $ ip l add dev tun type gretap external
    $ ifconfig tun 1.1.1.7/24 up
    $ ip r r 2.2.2.11 via 1.1.1.11 dev tun encap ip id 1000 dst 172.168.0.1 key

So I can guess that the 'remote ADDR' is 172.168.0.1, but what will be the 'local ADDR' of the route lightweight gre-tunnel in this case? What does the ip id means for a gre or an ipip tunnel?

A gre can have a key, and the patches to add the key keyword to the ip route encap are here https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=0fb4d21956f4a9af225594a46857ccf29bd747bc but this only set up a flag, there is no argument to the key keyword here.

Also I tested and I can add an 'encap ip' route to a standard ethernet inteface. What does the encap does in this case, how does it guess which kind of encapsulation to use?

Damien Robert
  • 101
  • 3

2 Answers2

1

(I am not sure what the src 0.0.0.0 means in this case.)

In networking typically this notation serves as unspecified/non-restricted parameter.

It's used when binding listening sockets host wide, w/o particular network interface limitation.

It's also used for default route numerical representation.

So back to this very case I'm 99% sure that would mean using node's route table for looking up appropriate source address for local side of tunnel's encapsulation, since it's not explicitly given otherwise.

So I can guess that the 'remote ADDR' is 172.168.0.1, but what will be the 'local ADDR' of the route lightweight gre-tunnel in this case?

Should be very same 0.0.0.0 with the same meaning as explained above.

What does the ip id means for a gre or an ipip tunnel?

Just distinguishable tunnel's id, that would be filled into route's info under LWTUNNEL_IP_ID and later used for tunnel lookup.

poige
  • 9,171
  • 2
  • 24
  • 50
  • For 0/0 I know it means the full ipv4 range, but usually for the 'src' address is determined automatically in `ip route`, the `src` keywords does not show up, as in `default via 1.2.3.4 dev eth0`. So I don't understand what `src 0/0` means compared to no `src`. – Damien Robert Sep 30 '19 at 21:17
  • For the 'local ADDR', you mean that it would be automatically set to the src address of the outgoing (non tunnel) interface? I guess this would make sense yes. Thanks for your answer! By the way, looking at the source code of `iproute2` I found that there was a `src` keyword in `encap ip`, it just was not documented in the man page. I sent a patch to add it. – Damien Robert Sep 30 '19 at 21:20
0

in the patch series linked above, the syntax is ip route add 40.1.1.1/32 encap vxlan id 10 dst 50.1.1.2 dev vxlan0.

…

But on my current iproute-5.2.0, there is no encap vxlan

Patch series is dated Fri, 10 Jul 2015 16:19:02 +0200, meanwhile 5.2.0 commit

tag v5.2.0
Tagger: Stephen Hemminger <stephen@networkplumber.org>
Date:   Mon Jul 8 11:11:36 2019 -0700

clearly tells us it's 2019. — 4 years have passed. I think it explains the contradiction you're seeing.

Community
  • 1
poige
  • 9,171
  • 2
  • 24
  • 50
  • Yes, I guessed that the api changed, but I could not find new documentation about the new api (even looking at the commit messages of the linux kernel and iproute2)... – Damien Robert Sep 30 '19 at 21:14