2

I have some scripts working with bridge & ip netns. It used to forward packets on layer2, but after upgrading my kernel, it seems the kernel forwarding the packets on layer3. In a newer kernel, It will trigger iptables table filter & chain FORWARD. If I add a rule in forward chain, it will match the packets; Or if I disable ip_forward by sysctl, it will not forward any IP packets. But it seems arp packets are still forwarded.

Then I built a centos7 in virtual box and simplified my scripts. I found it forwarded IP packets on layer2 on kernel 5.2.14, but on layer3 on kernel 5.3.13. I got the kernel rpm from 193.49.22.109 . I noticed that there was something changed in kernel 5.2 from kernel newbies , but the behavior of forwarding was not mentioned. I'm wondering what happened. Or perhaps I should report a bug?

Sample scripts:

#!/bin/bash

DEVICE=enp0s8

date
uname -a
ip net del ns &> /dev/null
ip net add ns
ip l a v1 type veth peer name v2
ip l s v2 netns ns
ip l s ${DEVICE} netns ns
ip a a 192.168.56.22/24 dev v1
ip l s v1 up
ip net exec ns ip l a name br type bridge
ip net exec ns ip l s dev ${DEVICE} master br
ip net exec ns ip l s dev v2 master br
ip net exec ns ip l s dev br up
ip net exec ns ip l s dev ${DEVICE} up
ip net exec ns ip l s dev v2 up
ip net exec ns ip a a 192.168.56.23/24 dev br
ip net exec ns iptables -A FORWARD -j DROP
echo 1 | ip net exec ns tee /proc/sys/net/ipv4/ip_forward > /dev/null
ip nei flush dev v1
ping 192.168.56.1 -c1 &> /dev/null
ping 192.168.56.1 -i1 -c5 
ip net exec ns iptables -L FORWARD -nv
maybeonly
  • 21
  • 2
  • Shot in the dark: Did you have a look at `ebtables` output? – dirkt Sep 15 '20 at 07:36
  • Both filter and broute tables are empty. – maybeonly Sep 15 '20 at 07:53
  • 2
    I think I'm describing the behaviour and what changed in 5.3: https://unix.stackexchange.com/questions/572022/linux-bridge-for-virtual-machines-not-forwarding-ip-packets-but-is-forwarding-a . – A.B Sep 15 '20 at 08:32

0 Answers0