I had a fully isolated LAN with two HW switches: 1Gbit and 10Gbit. The old 10Gbit switch could handle 1Gbit, too, hence there were no problem to connect the both switches together. Last week we got new 10Gbit switch which cannot handle 1Gbit. I must immediately connect these suddenly divorced network parts, because on 10Gbit there seeds the servers mainly (including dhcp) and majority of workstations are connected to 1Gbit. Fortunately, I have a debian linux box connected to both parts and I can configure it as 1/10 Gbit switch temporarily. I followed the hints but no bridging observerd – e.g. no efect in arp table, no ping from wks to server. I wrote a script:

ip link add name br0 type bridge
ip link set dev  br0 up
ip link set dev eth0 master br0 #1Gb
ip link set dev eth1 master br0 #XGb

Please can you answer me some question:

  • the eth0 and eth1 can has (the same) IP address ? or the IP address can get the br0 ?
  • the iptables has to be disabled / flushed / deinstall ? (iptables is not in use)
  • is there some „forward“ enable bit to be set?
  • could such software switch realy forward dhcp broadcast ?

I have a runnig tasks on my linux box, hence I did not tested the hints how to configure /etc/network/interfaces – I am glad I disabled the NetworkManager, I cannot reboot.

Any help and hint are welcome, I would be glad to rejoin the LAN before the monday morning.

1 Answer 1


To simplify I will talk only about ethernet and IPv4 (same applies for example to IPv6/ip6tables). I'll try to address each point sometimes with more details than needed, should this question be interesting other persons.

  1. setup

    To be complete, you should add this in your initial setup, in case it wasn't done earlier:

    ip link set eth0 up
    ip link set eth1 up

    If you don't bring up the bridge ports, the bridge while active will not be receiving nor be able to send any frame. This might be the cause of your issues.

  2. bridge ports and layer 3

    TL;DR: for the easiest setting, the IP and routing configuration should be on the bridge interface br0 and only on it. This should affect only the host's IP connectivity, not its bridging ability anyway. So if previously the IP was set on eth0 you should apply them on br0 instead. If you didn't do this, this would have prevented IP connectivity with the system (but not prevented bridging).

    As a side note, ARP is intended for the local system and handled by the ARP protocol and not handled in any special way by a bridge. What is useful on a bridge is to see the FDB (forwarding database entries).

    local system ARP state:

    ip neighbour show

    to monitor changes:

    ip monitor neigh

    Bridge MAC forwarding states:

    bridge fdb show br br0

    to monitor changes:

    bridge monitor fdb

    Other settings are possible, for example using an extra veth pair of interfaces with the IP on one end and the other end as a 3rd bridge port, and no IP on the bridge, leaving the bridge doing only bridging and not involved in layer 3. But it's longer to set up correctly (eg: what with the random MAC address by default? etc.).

    As soon as an interface becomes a bridge port (gets a bridge as master), its layer 3 informations get ignored: IPs configured on it, if any, become unavailable. The notable exception is the special implicit self bridge port having the bridge's name, so here br0. If you assign an IP to it, then the bridge will be working at layer 3 (IP), in addition to switching frames at layer 2. If you don't it will only be able to do switching.

  3. iptables/netfilter and bridge layer interactions

    TL;DR: if you're not using any iptables rules, including in network namespaces (containers), you don't have to do anything, nor have to care if some iptables related modules are loaded. Detailed answer following...

    Filtering (or mangling etc.) frames at layer 2 (ethernet bridge) is supposed to be done by ebtables, while filtering IP packets at layer 3 is supposed to be done by iptables. So iptables should normally not see frames (unless they are destined to the local system and arrive at layer 3 as IP packets) and not have any interaction on bridge's frames, but...

    ebtables is more limited and for example doesn't have direct access to netfilter's conntrack nor all the extensions available to iptables. Without this it would be difficult to implement a good layer 2 firewall (which acts as a switch rather than a router). That's why there's a special mode allowing the bridge code to call iptables (with frames temporarily changed into IP packets for iptables usage) in addition to ebtables. It's described in What's bridge-netfilter? and in ebtables/iptables interaction on a Linux-based bridge , with most prominent interaction examples in 7. Two possible ways for frames/packets to pass through the iptables PREROUTING, FORWARD and POSTROUTING chains. The Packet flow in Netfilter and General Networking schematic's Link Layer side details such handling in blue (ebtables) and green (iptables).

    This mode is enabled by loading the br_netfilter module (eg modprobe br_netfilter), but simply using an iptables rule with the physdev match will auto-load it.

    When this module is loaded (and the default sysctl still present: net.bridge.bridge-nf-call-iptables=1) then iptables will interact with the bridge, especially when the bridge has an IP, because this will be done an additional time from bridge layer, rather than only from network layer. So following the example in previous chapter 7, should you be bridging the LAN and also have a 3rd interface not part of the bridge used for internet access with NAT, this rule, if used alone:

    iptables -t nat -A POSTROUTING -s -j MASQUERADE

    in addition to NATing routed traffic to outside, would also NAT bridged traffic: every system receiving bridged frames would see as source the bridge's IP rather than the original. That's why this is usually written like this instead (you see this set by applications like LXC):

    iptables -t nat -A POSTROUTING -s ! -d -j MASQUERADE

    So yes you can even use iptables but you should be careful to not be using bridge-nf (the br_netfilter module) or else adapt rules. Some applications handling network, especially container related (Docker, Kubernetes...) might activate it.

    Note about network namespaces: bridge-nf will soon become per-namespace, but that's still not the case. It's possible to load the module, deactivate the option, and set a per-bridge option instead, but I think for now it works correctly only in initial namespace. Also triggering module auto-loading from any network namespace (by using physdev) will affect every other network namespace, initial included, that's why rules should always prepare for this.

    Note 2: once bridge connection tracking is made available to nftables, there should be no reason left to use bridge-nf.

  4. forwarding

    By default, without additional options the bridge is forwarding frames (and not handling STP) a few seconds after its ports and itself are brought up. So if you know there can't be any loop, it should be all ready to go.

  5. DHCP

    Yes the bridge should forward DHCP queries and answers, nothing special at the bridge level here.

  6. misc

    • VLAN

      Your setup doesn't seem to have VLAN IDs anywhere, so nothing special related to VLANs is needed. Just letting you know that if VLAN tagged frames were involved, the bridge would need additional settings to handle them properly (starting with ip link set dev br0 type bridge vlan_filtering 1, and then a few adequate bridge vlan ... commands).

    • troubleshooting

      You should run tcpdump on every interface, something like:

      tcpdump -e -l -n -s0 -i eth0
      tcpdump -e -l -n -s0 -i br0
      tcpdump -e -l -n -s0 -i eth1

      simultaneously to help see what's going on.

    • configuration

      if you're using ifupdown's kind of configuration on Debian, installing the bridge-utils package, which contains the obsolete command brctl will also add bridge-utils-interfaces hooks to configure a bridge in an interfaces stanza. It should be good enough for a simple bridge configuration.

  • 1
    Fully operational, like a miracle. I flushed the physical interfaces first, then ran the upgraded script, and the trafic started almost immediately!
    – schweik
    Jul 8, 2019 at 6:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .