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