netdev - Re: Routing in case of GRE interface under a bridge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABTgHBu24rSvuECSAHRtLj21fzwzWnYpKd5M9uL-z-_tTT0THA@mail.gmail.com>
Date: Thu, 29 Jun 2023 21:00:21 +0530
From: Nayan Gadre <beejoy.nayan@...il.com>
To: Ido Schimmel <idosch@...sch.org>
Cc: netdev@...r.kernel.org
Subject: Re: Routing in case of GRE interface under a bridge

Yes, the l2gre0 on System A and System B is a gretap created using
following command

ip link add l2gre0 type gretap remote 192.168.0.10 local 192.168.0.103
            --> and vice versa on System B.

On system A, l2gre0 and eth0 are under a bridge br0. l2gre0 does not
have an IP address.
On system B, l2gre0 is independent but has IP address 10.10.10.1, and
a DHCP server is running on it providing IP to clients connected
through the tunnel.
                      System A
 |                               System B
                                            192.168.0.103            |
                     br0                         br1
    |                        eth0
l2gre0
           eth0           l2gre0            eth1                     |
                  192.168.0.10                        10.10.10.1

On system A:
/ # ip r
default via 192.168.0.10 dev br1.1
169.254.0.0/16 dev br1.1 proto kernel scope link src 169.254.32.107
192.168.0.0/24 dev br1.1 proto kernel scope link src 192.168.0.103

On system B:
ngadre@...1-7h4wrf3:~$ ip r
default via 10.110.234.254 dev eno1 proto dhcp metric 100
10.10.10.0/24 dev l2gre0 proto kernel scope link src 10.10.10.1
192.168.0.0/24 dev enp3s0 proto kernel scope link src 192.168.0.10

As we can see, on System B there is a route pointing at l2gre0.
However, there is no such route on System A. Yet the packet gets
encapsulated
A client connected to eth0 on System A sends packet with destination
10.10.10.1 (def gateway). So I am guessing l2gre0 receives this packet
since it gets flooded by br0 and even though System A not having a
route to 10.10.10.0/24 it will encapsulate. Is this the behavior in
case of a bridged tunnel interface ?.

On Thu, Jun 29, 2023 at 4:42 PM Ido Schimmel <idosch@...sch.org> wrote:
>
> On Wed, Jun 28, 2023 at 07:06:45PM +0530, Nayan Gadre wrote:
> > I have a "l2gre0" and "eth0" interface under the bridge "br0".
>
> I assume "l2gre0" is a gretap, not ipgre.
>
> > If a packet comes to eth0 interface with a destination IP address say
> > 10.10.10.1 which is not known on the Linux system, as there is no
> > route for 10.10.10.1, will the l2gre0 interface encapsulate this
> > packet and send it across the tunnel ?
>
> The bridge doesn't care about IP addresses when forwarding unicast
> packets. Forwarding happens based on DMAC. Packet will be transmitted
> through "l2gre0" if the bridge has a matching FDB entry for the DMAC
> with "l2gre0" as the destination bridge port or if there is no FDB entry
> at all, in which case the packet will be flooded.
>
> One of the attributes of the GRE device is the remote address, which is
> the encapsulating destination IP. Linux needs to have a route telling it
> how to reach this destination address or the packet will be dropped.
>
> > The other endpoint is on a different Linux system with another l2gre0
> > interface having IP address 10.10.10.1
> >
> > Thanks
> > N Gadre
> >