0

I have the following topology which I configured to run a GRE tunnel between my Desktop and the wireless router. enter image description here

On the PC:

ip link add l2gre0 type gretap remote 192.168.0.103 local 192.168.0.10

On the Router:

ip link add l2gre0 type gretap remote 192.168.0.10 local 192.168.0.103

My client obtained an IP address of 10.10.10.102 from the DHCP server on PC. I try to ping the gateway IP 10.10.10.1 from my client. The ping succeeds.

What I want to understand is how the software routes this Ping packet across from lan0 to l2gre0 (both under bridge br0) and then crossing over to eth0 over the wire to enp3s0 (on the PC).

I took packet captures on lan0 and I could see that capture showed an ethernet frame. Then I took packet capture on l2gre0 (on Wireless router). I could see the same frame as seen in lan0. which means br0 repeated the frame from lan0 to l2gre0.

If I take packet capture on eth0 interface, GRE encapsulation has already happened, which means between l2gre0 and eth0 the software stack attached to l2gre0 might have encapsulated the frame. But l2gre0 has only the idea about remote 192.168.0.10 and local 192.168.0.103 endpoints, so how did it decide that this packet (dest IP: 10.10.10.1) need to be encapsulated ?

Routes on the Wireless router:

/ # ip r
default via 192.168.0.10 dev eth0
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.32.107
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.103
1
  • I am not sure if this is the correct site to post this question, will wait for few days else post on unix stackexchange. or superuser
    – Haswell
    Jun 16, 2023 at 13:28

2 Answers 2

1

But l2gre0 has only the idea about remote 192.168.0.10 and local 192.168.0.103 endpoints, so how did it decide that this packet (dest IP: 10.10.10.1) need to be encapsulated ?

It didn't. The endpoints you're talking about are tunnel source address (192.168.0.103) and tunnel destination address (192.168.0.10). These are addresses that are used by kernel to send and receive encapsulated payload, they do not participate in kernel routing as such.

What exactly happens here is that your kernel IP stack routes packets destined to 10.10.10.1 out of your GRE tunnel just because it is a directly connected IP interface l2gre0 with this address assigned as it's remote peer tunnel remote address. Likewise your l2gre0 interface has tunnel local address, these are addresses assigned to the tunnel interface itself, think of them as "names for the local and remote side inside the tunnel", you can get them with ip a l on most modern distributions.

Whatever gets routed into the GRE tunnel by the kernel gets encapsulated and sent to the tunnel destination address, the interface doesn't check what payload it was given (just like any other interface doesn't) and send that out for the remote side to deal with it.

2
  • "ip a l" shows only this: 23: l2gre0@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UNKNOWN group default qlen 1000 link/ether f6:56:9d:b0:b5:77 brd ff:ff:ff:ff:ff:ff
    – Haswell
    Jun 18, 2023 at 15:49
  • "kernel IP stack routes packets destined to 10.10.10.1 out of your GRE tunnel" but there is no route specifying this. How does kernel know that it is directly connected next-hop via l2gre0
    – Haswell
    Jun 26, 2023 at 4:17
0

since the lan0 and l2gre0 are bridged, packet is forwarded from lan0 to l2gre0, and it would be internally (by the kernel "br_flood/br_forward") pushed on the l2gre0 transmit path via "ipgre_xmit" where first encapsulation will happen and then the route lookup will happen for outer destination IP address which will push the packet out of eth0 interface.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .