Section 16.12.  The Big Picture

16.12. The Big Picture Figure 16-11 shows the key routines that the bridging code uses to process ingress and egress frames (both data frames and BPDUs). Figure 16-11. The big picture In particular, note that: There are as many hooks as there are at the IP layer (see Figure 18-1 in Chapter 18). One more hook in br_handle_frame (NF_BR_BROUTING), not shown in the figure, is used by ebtables and is described in the section "Data Frames Versus BPDUs." Ingress data frames may go through netif_receive_skb twice. netif_receive_skb is described in Chapter 10. See also the section "Processing Data Frames," later in this chapter. Ingress frames are passed by netif_receive_skb to the bridging subsystem when a call to handle_bridge indicates it is necessary, or to the upper-layer protocol handlers otherwise (as described in Chapter 13). Ingress frames may be dropped by the bridging code, for example, because the port is disabled. Ingress data frames are dropped by br_forward when the receiving port has been blocked by the STP. Egress frames do not need to be transmitted out of any port by br_deliver when the destination address is local to the host. In both cases, unneeded transmissions are filtered by should_deliver. Egress data frames go through dev_queue_xmit twice. dev_queue_xmit is described in Chapter 11. See also the section "Transmitting on a Bridge Device" later in this chapter. The br_flood function floods a frame on the ports of a bridge. Flooding may be necessary for both ingress and egress frames. Regardless of where a frame is generated, when it is addressed to a multicast or broadcast address, or to an address not in the forwarding database, it must be flooded. br_flood knows whether it is handling an ingress or egress frame from its final input parameter, which is the function it calls multiple times to transmit the frame on each bridge port (_ _br_forward for ingress and _ _br_deliver for egress). While looking at the code in the next sections, you need to keep in mind that the bridging code uses the same set of core routines regardless of whether the STP is enabled. Some key differences lie in the subtasks executed. When the STP is enabled: Ingress BPDUs are processed. BPDUs may be generated locally too, depending on the roles of the local bridge ports. Ingress data traffic is either forwarded to the right port or flooded to all bridge ports, according to the rules in Chapter 14. The ports that STP blocks cannot be used to receive and transmit data traffic. When the STP is disabled: Ingress BPDUs are treated as data traffic. No BPDUs are generated locally. Ingress data traffic is still forwarded to the right port or flooded to all bridge ports, according to the rules in Chapter 14. All the bridge ports (unless they're administratively disabled) can be used to receive and transmit data traffic.