Section 15.11.  Processing Ingress Frames

15.11. Processing Ingress Frames We saw in Chapter 14 how a simple bridge handles ingress traffic. Let's now see how a bridge running the STP handles ingress traffic. Ingress traffic now includes not only data traffic, but BPDUs as well. Bridges handle data traffic the same way, regardless of whether STP is enabled. The only difference is that ports blocked by STP cannot forward any data traffic because they are not considered part of the tree. 15.11.1. Ingress BPDUs Unlike data traffic, ingress BPDUs are accepted on any port that has not been administratively disabled, including those in the blocking state. Configuration BPDUs and TCN BPDUs can be distinguished thanks to the BPDU type field, as shown in Figure 15-7. In the section "Letting All Bridges Know About a Topology Change," we already saw how ingress TCN BPDUs are handled. In the next section, we will see how configuration BPDUs are processed. 15.11.2. Ingress Configuration BPDUs Figure 15-22 shows how ingress configuration BPDUs are processed. The handling of an ingress BPDU depends on whether its priority vector is: Better than the one currently known to the receiving bridge's port In this case, the BPDU triggers a configuration update that includes the new root port, the designated ports, and the new state for all ports. Figure 15-22. Processing ingress configuration BPDUs The same as the one already known to the receiving bridge's port This is what would be received on the root port when the topology has already converged. Worse than the one known to the receiving bridge's port In this case, the bridge replies by sending a configuration BPDU with its own (better) information. This is a common case that happens when a new bridge is added to the topology: initially the bridge does not know anything about the other bridges and therefore advertises its information. It can also happen in numerous other cases, such as when a bridge configuration is changed. When an ingress BPDU claims a better priority vector than the one known to the receiver port, there is one special case to handle: when the receiving bridge was the root bridge it must lay down its crown. As we mentioned in the section "Topology Changes," this is one of the events that is considered a topology change. In such a case, the bridge that lost the root role must stop the Hello timer (because it is to be run only on the root bridge), send a TCN BPDU out its root port toward the new root bridge, and start the TCN timer to notify the root bridge about the topology change (which will take care of notifying all other bridges). When the BPDU is received on the root port, the bridge saves the timers from the BPDU (which it will use in its egress BPDUs) and transmits a configuration BPDU out all of its designated ports. When the TCA flag is set, the TCN timer can be stopped.