Problem with setting cards correctly in bridge mode.

Hello.

On the router/gateway (separate computer) I have an Intel 82576 Gigabit Network Connection card. This card has 4 Ethenert slots.

Code:
root@router:~ # pciconf -lv | grep -A1 -B3 network
igb0@pci0:3:0:0:        class=0x020000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x10e8 subvendor=0x8086 subdevice=0xa02c
    vendor     = 'Intel Corporation'
    device     = '82576 Gigabit Network Connection'
    class      = network
    subclass   = ethernet
igb1@pci0:3:0:1:        class=0x020000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x10e8 subvendor=0x8086 subdevice=0xa02c
    vendor     = 'Intel Corporation'
    device     = '82576 Gigabit Network Connection'
    class      = network
    subclass   = ethernet
igb2@pci0:4:0:0:        class=0x020000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x10e8 subvendor=0x8086 subdevice=0xa02c
    vendor     = 'Intel Corporation'
    device     = '82576 Gigabit Network Connection'
    class      = network
    subclass   = ethernet
igb3@pci0:4:0:1:        class=0x020000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x10e8 subvendor=0x8086 subdevice=0xa02c
    vendor     = 'Intel Corporation'
    device     = '82576 Gigabit Network Connection'
    class      = network
    subclass   = ethernet
re0@pci0:5:0:0: class=0x020000 rev=0x0c hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x1565 subdevice=0x2400
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet

For a long time, one Ethernet slot was used. Today, I wanted to compare it into bridge mode.
I started with the last slot and I've bundled it with the previous. Appropriately igb3 with igb2 with igb1.

Below is the config:
Code:
cloned_interfaces="bridge0"
ifconfig_bridge0="addm igb3 addm igb2 addm igb1"
ifconfig_bridge0_alias0="inet 10.10.1.1 netmask 255.255.255.0"
ifconfig_igb3="up"
ifconfig_igb2="up"
ifconfig_igb1="up"

First I checked statically on the system on which it runs, hidden behind NAT. By setting the network gateway mask and DNS by hand. It worked. There was and continues to be a connection to sites through the browser from each subsequent slot. The problems started when I wanted to attach the last interface called igb0. On this interface there was a NAT network set up, which I have used until today.

This igb0 interface had an adress
Code:
ifconfig_igb0="inet 10.1.1.1 netmask 255.255.255.0"

Of course, in /etc/rc.conf I binded the entry for the address of this interface. And then I made sure that everything was credited correctly. And whether the network card is added to the bridge.

Code:
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 58:9c:fc:10:41:3c
        inet 10.10.1.1 netmask 0xffffff00 broadcast 10.10.1.255
        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: igb1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 2 priority 128 path cost 2000000
        member: igb2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 3 priority 128 path cost 2000000
        member: igb3 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 4 priority 128 path cost 2000000
        groups: bridge
        nd6 options=9<PERFORMNUD,IFDISABLED>

The definition of the problem is that:
The bridge setting, along with the network card on which the network was previously defined, cuts off the internal network from the Internet. It threw away connections on all slots. The computer behind the nat showed a connection, but no website can be displayed from any slot. It was also impossible to log in from the console via SSH from any slot. It made it all seem as if something was blocking the connections.
 
ifconfig_bridge0_alias0="inet 10.10.1.1 netmask 255.255.255.0"
So you have added an IP for your bridge. It looks set correctly.

ifconfig_igb0="inet 10.1.1.1 netmask 255.255.255.0"
This is a problem. You assign an IP to the bridge. Not the members.
Instead it should be just like the other members.

Consider this:
Code:
cloned_interfaces="bridge0"
ifconfig_bridge0="addm igb3 addm igb2 addm igb1 addm igb0"
ifconfig_bridge0_alias0="inet 10.10.1.1 netmask 255.255.255.0"
ifconfig_igb3="up"
ifconfig_igb2="up"
ifconfig_igb1="up"
ifconfig_igb0="up"

With your original setup using a different subnet on a member than the bridge would certainly cause problems.
igb0=10.1.1.1
bridge0=10.10.1.1
That arrangement will not work.

If the bridge host needs an IP address then the correct place to set this is on the bridge interface itself rather than one of the member interfaces. This can be set statically or via DHCP:
This is from an older version of the manual.
 
For the time of connecting the device called igb0 to the bridge, Subnet belonging to the card having this group of addresses:

Code:
ifconfig_igb0="inet 10.1.1.1 netmask 255.255.255.0"

Has been deactivated by insertion of # sign before the command line. That's why I think it's inactive.
 
Code:
        member: igb1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 2 priority 128 path cost 2000000
        member: igb2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 3 priority 128 path cost 2000000
        member: igb3 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 4 priority 128 path cost 2000000
Note that igb0 is not attached to the bridge here.
 
Funny.
I have rtorrent set up from the guide available at HOW-TOs.
At the beginning it was set to 20 peers per torrent. But since it grew, I scaled it down to 10 peers per torrent.
The problem is similar. After a reboot, the first applied settings load. Only after closing the process and restarting it The correct settings are loaded.

I believe that the cause is the creation of executable files with machine code, based on the daemon or services running in the background, which are not deleted when new settings appear. The problem also applies to things like the firewall shutting down:
 
Last edited:
I can't edit the entry. But the culprit of all the confusion was /etc/pf.conf, it was directing packets to a non-existent port.
But that doesn't explain the rest of the problems.

Code:
ext_if="re0"
#int_if="igb0"
#wifi="wlan0"

#TOR1
#rdr pass on $int_if proto tcp from any to any port 1234 -> $int_if
#rdr pass on $int_if proto tcp from any to any port 8080 -> $int_if
#rdr pass on $int_if proto tcp from any to any port 445 -> $int_if
#rdr pass on $int_if proto tcp from any to any port 139 -> $int_if
#rdr pass on $int_if proto tcp from any to any port 138 -> $int_if
#rdr pass on $int_if proto tcp from any to any port 137 -> $int_if
#rdr pass on $int_if proto tcp from any to any port 631 -> $int_if

#TOR2
#rdr pass on $wifi proto tcp from any to any port 1234 -> $wifi
#rdr pass on $wifi proto tcp from any to any port 8080 -> $wifi
#rdr pass on $wifi proto tcp from any to any port 445 -> $wifi
#rdr pass on $wifi proto tcp from any to any port 139 -> $wifi
#rdr pass on $wifi proto tcp from any to any port 138 -> $wifi
#rdr pass on $wifi proto tcp from any to any port 137 -> $wifi
#rdr pass on $wifi proto tcp from any to any port 631 -> $wifi

#rdr pass on $wifi proto tcp from any to any -> 127.0.0.1 port 9150
#rdr pass on $wifi proto tcp from any to any -> 127.0.0.1 port 9150
#rdr pass on $wifi proto tcp from any to any port 53 -> 127.0.0.1 port 9153
#rdr pass on $wifi proto udp from any to any port 53 -> 127.0.0.1 port 9153

set skip on lo
nat on $ext_if inet from ! ($ext_if) to any -> ($ext_if)
 
Back
Top