Created attachment 1484497 [details] skylake - lsmod and bridge-nf Description of problem: Experienced an issue with a customer while using L2 w/Linux Bridge. The virtual machine using the bridge (red) was unable to pass traffic to the outside network including receiving a DHCP address. Config: phydev - bridge (red) - eth1 (instance) ip link add name red type bridge ip link set red up ip link set em3 master red We used tcpdump on bridge interface and the uplink. No virtual machine traffic could be seen on phydev. There was virtual machine traffic on the bridge interface. The fix was to: iptables-save > /tmp/iptables.txt remove rule -A FORWARD -j REJECT --reject-with icmp-host-prohibited iptables-restore < /tmp/iptables.txt Version-Release number of selected component (if applicable): How reproducible: Unable to reproduce. Multiple clusters in the lab (using either cri-o or docker) do not experience this issue. From investigation our clusters and the customers are similarly configured. sysctl -a | grep bridge net.bridge.bridge-nf-call-arptables = 0 net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-filter-pppoe-tagged = 0 net.bridge.bridge-nf-filter-vlan-tagged = 0 net.bridge.bridge-nf-pass-vlan-input-dev = 0 [root@jcallen-node4 bridge]# lsmod | grep -E 'bridge|br|filter|table' ebtable_filter 12827 0 ebtables 35009 1 ebtable_filter iptable_nat 12875 1 nf_nat_ipv4 14115 2 openvswitch,iptable_nat br_netfilter 22256 0 iptable_filter 12810 1 ip_tables 27126 2 iptable_filter,iptable_nat bridge 146976 1 br_netfilter stp 12976 1 bridge llc 14552 2 stp,bridge Actual results: Customer unable to pass traffic on bridge without removing FORWARD -j REJECT. Expected results: Network traffic should be able to traverse bridge and exit phydev without removing the firewall rule. Additional info:
Created attachment 1484498 [details] broadwell - lsmod and bridge-nf
Another important note. To assist in troubleshooting we assigned an address to the bridge interface via dhclient which succeeded normally.
Hello Joseph, thanks for reporting this. Could you please share VMI specification you used? Also it would be handy if you shared `ip a` output on the host machine. `ip a` output on the VMI. `ip a` output on the pod that runs the VMI. To do so, use `oc get pod -l special=$NAME_OF_THE_VMI` to find the pod name and then `oc exec $POD_NAME ip l`.
Please reopen this bug when you have the requested information.