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] [day] [month] [year] [list]

Message-ID: <CABTgHBvV=dv-W2N7Jxqp3AWqq+XC3majN2oqdd26bBu4WrobHg@mail.gmail.com>
Date: Mon, 3 Jul 2023 11:14:57 +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

On Thu, Jun 29, 2023 at 10:29 PM Ido Schimmel <idosch@...sch.org> wrote:
>
> (Please avoid top-posting).
>
> On Thu, Jun 29, 2023 at 09:00:21PM +0530, Nayan Gadre wrote:
> > 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.
>
> That's OK. It's meaningless to assign an IP address to a bridge port.
>
> > 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.
>
> The overlay IP address is irrelevant. System A does not inspect it, it
> simply forwards Ethernet frames (based on DMAC) between both bridge
> ports - eth0 and l2gre0.
>
> As to whether it gets flooded or not, it depends on the DMAC of the
> frame received via eth0 and the FDB of br0. I expect the DMAC to be the
> MAC of l2gre0 on system B. You can dump the FDB on system A using the
> following command:
>
> # bridge fdb show br br0 | grep master
>
> > Is this the behavior in case of a bridged tunnel interface ?.
>
> This is the encapsulation flow on system A as I understand it from your
> data:
>
> 1. Ethernet packet is forwarded by br0 from eth0 to l2gre0.
>
> 2. l2gre encapsulates the Ethernet packet with
> {sip=192.168.0.103,dip=192.168.0.10,ip_proto=0x2f,gre (proto=0x6558)}
>
> 3. Encapsulated packet is routed out of br.1 that has the most specific
> route of 192.168.0.0/24 towards 192.168.0.10

Ok, so packet is forwarded from eth0 to l2gre0, and it would be internally
(by the kernel "br_flood/br_forward") pushed on the l2gre0 transmit
path via  "ipgre_xmit"