Bug 1630523

Summary: L2 Networking with Linux Bridge firewall issue
Product: Container Native Virtualization (CNV) Reporter: Joseph Callen <jcallen>
Component: NetworkingAssignee: Petr Horáček <phoracek>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Meni Yakove <myakove>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 1.1.1CC: cnv-qe-bugs, danken, jcallen, phoracek
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-23 12:35:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
skylake - lsmod and bridge-nf
none
broadwell - lsmod and bridge-nf none

Description Joseph Callen 2018-09-18 20:21:18 UTC
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:

Comment 1 Joseph Callen 2018-09-18 20:25:37 UTC
Created attachment 1484498 [details]
broadwell - lsmod and bridge-nf

Comment 2 Joseph Callen 2018-09-18 20:31:26 UTC
Another important note.  To assist in troubleshooting we assigned an address to the bridge interface via dhclient which succeeded normally.

Comment 3 Petr Horáček 2018-09-19 17:37:18 UTC
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`.

Comment 5 Dan Kenigsberg 2018-10-23 12:35:34 UTC
Please reopen this bug when you have the requested information.