1111.1111, FRED’S MAC ADDRESS, ASSOCIATED WITH INTERFACE E0. WHEN...
0200.1111.1111, Fred’s MAC address, associated with interface E0. When Barney replies at
Step 2, the bridge adds a second entry, this one for 0200.2222.2222, Barney’s MAC address.
Learning always occurs by looking at the source MAC address in the frame.
Forwarding Unknown Unicasts and Broadcasts
What do you suppose the bridge did with Fred’s first frame in Figure 9-4, the one that
occurred when there were no entries in the bridging table? As it turns out, when there is no
matching entry in the table, bridges forward the frame out all interfaces. Bridges were
designed to forward what are called unknown unicast frames (frames whose destination
MAC addresses are not yet in the bridging table), with the hope that the unknown device will
be on some other Ethernet segment and will reply, and the bridge will build a correct entry
in the bridging table. For instance, in Figure 9-4, the bridge forwards the first frame over to
the right-side Ethernet, even though Barney is not on the right side of the bridge. Later, the
bridge will filter a frame sent from Fred to Barney because the bridge would have an entry in
the bridging table telling the bridge that Barney is also off port E0.
Bridges also forward LAN broadcasts. LAN broadcasts, by definition, need to be received by
all devices on the same LAN. So, the bridge simply forwards broadcasts. Generally, bridges
also forward LAN multicast frames out all ports, just like they do for broadcasts. However,
a few multicast features in switches limit the flooding of multicasts, such as Internet Group
Management Protocol (IGMP) snooping. Bridges never forward traffic out the same interface
it came in—so, broadcast, multicast, and unkown unicast frames are actually sent out all
interfaces except the incoming interface.
LAN Switching
Before bridges were created, a 10BASE-T network might have begun to suffer from
performance problems. As described in the previous section, to improve performance, you
might have added a two-port bridge, created two LAN segments, doubled the bandwidth,
reduced collisions, and improved performance.
Now take a step back and think about what might happen to that network with the bridge
6 months later. More devices have been added to the segments on each side of the bridge.
More bandwidth-hungry applications have been added. Eventually, both LAN segments
might become as congested as the original single Ethernet segment was 6 months earlier.
What’s the solution? What about a four-port bridge? The engineer adds the four-port bridge,
converting the two segments to four segments, again doubling bandwidth, and again
reducing collisions. A few months later, the number of devices has increased, more
bandwidth-hungry applications have been added, and you need an eight-port bridge! You
can see a vicious cycle beginning to occur.
From one perspective, switches are bridges with lots of ports. Switches behave identically to
transparent bridges in terms of forwarding and learning, but switches typically have many
more ports and much faster internal processing. So, if a campus network needed to be broken
into 100 different segments, you could use a switch with 100 ports in it. It would break the
LAN Switching 241
Ethernet into 100 different collision domains, or segments, and create 100 different sets of