Understanding Linux Network Internals

netdevice Notification Chain

Because the virtual bridge device is defined as an abstraction on top of real (enslaved) devices, the bridge device is likely to be affected when any of its enslaved devices change status. For this reason, the bridging subsystem's initialization routine, briefly described in the section "Initialization of Bridging Code," registers the br_device_event callback with the netdevice notification chain. The bridging code is interested only in enslaved devices, so any notification regarding a nonenslaved device is of no interest and does not need attention.

Here is how each received event notification is processed:

NETDEV_CHANGEMTU

The MTU for the bridge device is updated to reflect the minimum MTU among the ones configured on the enslaved devices.

NETDEV_CHANGEADDR

When an enslaved device changes its MAC address, its entry in the forwarding database is updated with br_fdb_changeaddr and the bridge ID is updated with br_stp_recalculate_bridge_id to reflect the rule we saw in the section "Bridge IDs and Port IDs."

NETDEV_CHANGE

This notification can be used for various purposes. The bridging subsystem is interested only in changes to the carrier status.

When an enslaved device loses or detects its carrier status, the associated bridge port is enabled and disabled with br_stp_enable_port and br_stp_disable_port, respectively. When the bridge device this device is associated with is left down by the administrator (i.e., IFF_UP is not set), the notification is ignored. ...