Date: Sun, 22 Jul 2018 20:16:39 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 229970] [ipfw] if_bridge(4) with physical denies igb trafiic Message-ID: <bug-229970-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229970 Bug ID: 229970 Summary: [ipfw] if_bridge(4) with physical denies igb trafiic Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: ohartmann@walstatt.org This is related to FreeBSD 12.0-CURRENT #254 r336614: Sun Jul 22 21:33:36 CEST 2018 amd64. The custom kernel is compiled with VIMAGE. The host has igb0 (Intel I350 Gigabit Network Connection) as its own physical device. [...] igb0: <Intel(R) PRO/1000 PCI-Express Network Driver> mem 0xf7900000-0xf79fffff,0xf7a04000-0xf7a07fff irq 16 at device 0.0 on pci1 igb0: attach_pre capping queues at 8 igb0: using 1024 tx descriptors and 1024 rx descriptors igb0: msix_init qsets capped at 8 igb0: pxm cpus: 4 queue msgs: 9 admincnt: 1 igb0: using 4 rx queues 4 tx queues igb0: Using MSIX interrupts with 5 vectors igb0: allocated for 4 tx_queues igb0: allocated for 4 rx_queues igb0: netmap queues/slots: TX 4/1024, RX 4/1024 [...] igb0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=a520b9<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6> ether xx:xx:xx:xx:xx:xx inet 192.168.8.5 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (1000baseT <full-duplex>) status: active igb0 is member of a if_bridge(4) with other epair(4) pseudo NICs: [...] bridge1000: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 03:44:f4:a7:c0:08 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: epair52b flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 10 priority 128 path cost 2000 member: epair3b flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 9 priority 128 path cost 2000 member: igb0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 1 priority 128 path cost 20000 groups: bridge The following settings has been conducted accordingly: [...] net.link.bridge.ipfw: 0 net.link.bridge.allow_llz_overlap: 0 net.link.bridge.inherit_mac: 0 net.link.bridge.log_stp: 1 net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 0 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_bridge: 0 net.link.bridge.pfil_onlyip: 0 On the host (owner of igb0) and on each of the jails IPFW is running, on the jails as OPEN or as WORKSTATION, same for the host. Pinging or ssh from one epair host to another on the bridge1000 or pinging the outside world like freebsd.org works well. Pinging the host associated with igb0 doesn't work! It doesn't work from any host on that specific if_bridge(4) igb0 is member of. Weird: if I ping from the host owning igb0 any of the jails within the bridge1000 works and after this "init" pinging igb0's IP from the jails on bridge1000 also worls like a charme as any other network traffic as expected! I have a very similar setup on a host with Broadcom bcm NICs. I do not see the problem there. I do not know whether this is igb, ipfw related. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-229970-227>