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.
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 192.168.22.0/24 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 192.168.22.0/24 -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 192.168.22.0/24 ! -d 192.168.22.0/24 -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.