[Bug 229970] [ipfw] if_bridge(4) with physical denies igb trafiic

[bugzilla-noreply at freebsd.org]

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 at FreeBSD.org
          Reporter: ohartmann at 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.