If you want to extend or connect your LANs, then repeaters or bridges will likely be the tools that you use. Repeaters extend the reach of your network, and bridges connect like (or nearly like) networks to create one big network. Although it's difficult to generalize about the role of different connection hardware in a network, because the lines between connectivity hardware and internetworking hardware become blurrier by the hour, you could say that bridges and repeaters are both intranetworking devices. They create larger networks, instead of connecting separate ones. Contrast them with routers, which are more internetworking devices that provide a meeting place for separate networks. (Routers are such a big topic that they get a chapter of their own; see chapter 15, "Routers," to read about what they are and how they work.)
This chapter discusses repeaters and bridges and includes the following topics:
Repeaters are devices that regenerate an electronic or photonic signal to extend the distance that the signal can travel. When repeaters receive a signal, they boost it to its original strength and condition, repairing any signal corruption that may have occurred due to noise along the way.
Repeaters are purely physical devices, operating at the lowest level of the OSI model. The only thing that repeaters do is strengthen the signal; filtering and routing are left to higher-level devices.
Specifically, what purpose might a repeater serve in your network? Why is repeating the signal important?
The reason for repeaters is simple: any kind of signal becomes weaker the farther it has to travel. The weaker the signal gets, the more vulnerable it is to interference and corruption, and eventually it becomes unintelligible. Think of throwing rocks in a lake. At the spot where the rock enters the water, the waves produced are strongest; other ripples at that point are unlikely to affect their path. The ripples spread out from that point and may travel quite a distance (depending on the size of the original splash), but become less and less pronounced the farther they travel. The smaller and weaker the ripple, the more likely that interferenceóperhaps another rippleówill disturb the pattern that the first creates, or even stop it from traveling any further. The way that the signal gets weaker as it travels is called attenuation.
Network signals work much the same way as the water ripples, although not all are equally affected by interference and distance. The kind of signal makes a difference (photonic signals are less affected by attenuation than electronic signals), and cable shielding can reduce the effects. However, no matter what kind of signal it is or what kind of cable it travels through, sooner or later the signal loses its strength to the point where the data it carries is no longer "intelligible" at its destination. Use a repeater to increase the distance by which the sender and receiver can be separated before attenuation becomes a problem.
In bus Ethernet (10Base2) networks, repeaters can help avoid collisions. You'll recall from earlier in this text that one of the problems with Ethernet's broadcasting method of data transfer is the possibility of collisions when two or more nodes attempt to transmit data at the same time. (In fact, collisions are an inherent part of the Ethernet broadcast architecture.) As you remember, when an Ethernet node wants to transmit data, it first "listens" to see if the network is clear, rather like the old Westerns in which the scout put an ear to the ground to hear if the cavalry was coming. If the network is not in use, then that node is free to transmit data. So far, so good. But a node's ears are only so good, and if the cable segment is too long then the node can't always hear network traffic, so it may attempt to send data when another node is already using the network. The result is increased collisions, which will ultimately reduce network performance. Repeaters can help solve this problem by shortening the cable segments required to fit all the nodes in the network.
Repeaters have yet another use: they can isolate segments of the network, while still permitting the LAN to operate as a unit. In a bus topology the biggest problem is that one break in the cable (whether an actual break or just being unplugged) keeps the network from functioning properly. A network divided into segments separated by hardware such as a repeater is less affected by cable breaks, as only the segment on which the break occurs is affected, rather than the entire network.
For example, consider the case of one computer training company. To give its instructors hands-on experience with PC troubleshooting and network maintenance, it wanted to develop a training area where the instructors could play with machines, cables, and network software without having to worry about using mission-critical parts of the network for training. After all, the last place that you want to put a person just learning about network operating systems is in front of the file server, right? So the idea was that some machines and a network could be set aside for training purposes, permitting the students to experiment without endangering operations.
The problem was that it was necessary for these machines to be networked and be able to get to the main office network, but the company didn't want the bus network to be broken when students forgot to terminate the network. Therefore, the company used a repeater to isolate the training segment. In the now isolated (but still connected to the office network) segment, the instructors could get hands-on experience with real and created problems without affecting the rest of the network.
Repeaters are useful for those times when you need to segment your network without breaking it, but when you don't need any kind of routing or traffic-control capability.
The function of a repeater in the network is to regenerate the signal so that it can travel farther. Essentially, what happens is this: when data packets arrive at the repeater, the device takes them apart and reassembles them in the same form that they started out as. The repeater is not doing anything to the dataóas physical devices, repeaters don't know data from a hole in the groundóbut only revitalizing the packet so that it's ready to travel farther. Please note that there is no error-control inherent in this process: if the packets that arrive at the repeater are garbled due to line noise, that's what the repeater will send out.
Although repeaters operate on a physical level, they are not limited only to connecting the same kind of cable. Some modular repeaters can support twisted pair, coaxial, and/or fiber all in the same boxóthe exact configuration is determined by the modules you select. Repeaters cannot, however, connect two disparate network types, such as Token Ring to Ethernet, as they're not smart enough to perform any kind of packet conversion. As you'll see later in this chapter and in chapter 15, "Routers," this is a job left to the smarter bridges and to routers.
You'll notice that the name of repeaters is a little misleading. They don't just repeat the signal, they reassemble it to make it fresh. LAN extenders, which electronically boost the signal and don't repackage it, in some ways are the devices that might more properly be called repeaters. Extenders have much of the same function as repeaters, in that, by strengthening the signal, they permit you to place nodes farther apart than would normally be permitted due to the effects of attenuation, but they don't work the same way and don't add to your repeater count. (What repeater count? As we'll discuss in a minute, you can only have as many as four repeaters in a network, and the number that you have is known as the repeater count.)
You can see the difference between repeaters and extenders illustrated in figure 14.1.
Figure 14.1 Repeaters regenerate the signal; extenders rebroadcast the existing signal.
You can only have as many as four repeaters in any given network, or else bad things (like network failures or delays) may happen. There are two reasons for this. First, propagation delay may produce collisions on the network. Every time a packet is disassembled and reassembled by the repeater, there's an infinitesimal delay. This isn't a problem when the packet is only reassembled once, but the more repeaters in the network, the more delays you have. After a certain point, the delays accumulate to the point at which the sending node notices that it hasn't heard any acknowledgment of its transmission. "Looks like the packet got lost on the way there," decides the sending node, "so I'd better re-send it." Trouble is, that packet is still on the network and in transit, so if the original sender retransmits the data while the original packet is still out there, the two packets will collide. The result is network delays because the sending node has to retransmit the data. As you'll remember from the earlier discussion of the Ethernet logical topology, collisions don't seriously slow down the network, but there's no reason to go looking for them.
The other problem that having too many repeaters can lead to is that of data corruption. Every time that a repeater disassembles and reassembles a packet, there's the chance that it may put the packet back together incorrectly, possibly substituting a 1 for a 0 and thus corrupting the data. It's rather like the joke about what happens if you take a computer apart and put it back together againódo it enough times, and you can build a new computer from all the spare parts. Take apart a packet and put it together enough times, and some parts may be missing or put back together incorrectly.
The four-repeater rule is not carved in stoneóthat is, this doesn't mean that your network will work perfectly with four repeaters and cease functioning altogether with fiveóbut it's a good guideline to help you avoid problems. Networks fail enough without looking for problems. Therefore, if your network's span requires more than four repeaters to keep connected, you should consider a bridge.
Bridges are a step up from repeaters in terms of complexity and capability. Instead of providing a purely physical connection between segments of a network, bridges have some intelligence to perform traffic control. They keep local traffic local and send traffic only to other segments on which it belongs. Bridges have the regenerating capabilities of repeaters, so you don't need to use them in tandem.
Bridges operate in the data link layer of the OSI model, in the sublayers known as the media access control (MAC) layer and the logical link control (LLC) layer.
These sublayers were not originally part of the OSI model developed by the International Standards Organization, but after the model was completed the IEEE decided that the data link layer covered too broad an area to be useful for some definitions, such as explaining how bridging should work. Hence the sublayersóit's the same reason why the physical layer is subdivided; see chapter 3, "The OSI Model: Bringing Order to Chaos," for more information about the OSI model.
The MAC and LLC layers fit into the OSI model as shown in figure 14.2.
Figure 14.2 The MAC and LLC's layers are sublayers of the data link layer in the OSI model.
Each of these sublayers plays a different role in the function of a bridge. The MAC sublayer, which is closest to the physical layer, specifies how a device transmits data and how that data travels over the physical medium, whether that be coaxial cable, fiber, or twisted pair. This layer is where the various kinds of networks (Ethernet, Token Ring, and FDDI) are defined.
If you've heard of MAC addresses (and if you haven't, you will later in this chapter when we discuss filtering), then this is the layer at which they're applicable. MAC addresses are the network addressees burned into network cards at manufacture. Each MAC address is unique, because the IEEE furnishes NIC vendors with available addresses from the three trillion or so available. Theoretically, duplication among MAC addresses is impossible. (In practice, this isn't always true, but we'll get to that a little later.)
Most bridges require compatibility at the MAC layer to link network segmentsóthat is, Ethernet to Ethernet, or Token Ring to Token Ring, but not (in most bridges) Ethernet to Token Ring. This compatibility means that the bridge can be insensitive to what's going on at higher levels, so the network operating system or network protocols used are irrelevant to a bridge.
The LLC's role is closer to the network layer, and performs a function similar to routing. Because of its routing character, LLC type is defined in the IEEE standards, so that 802.3 (DIX) Ethernet uses LLC, but other Ethernet types may not. (In English, that means that other kinds of Ethernet may not be able to do the same kinds of bridge routing as the 802.3 standard.) This matters when you're bridging Ethernet to Token Ring (as we'll discuss below), so keep that in mind when choosing an Ethernet type for your network.
The LLC layer is responsible for how connections are established between sender and destination, how the data moves between them (flow control), and how the connections are broken when the data has been sent. It can define any one of three kinds of transmission methods:
Each of these transmission methods works a little differently and is better used for a different purpose. The methods that include frame acknowledgment actually take over a task normally associated with higher-level protocols (such as TCP/IP). In providing this service at the data-link layer these methods allow the connection to be made more quickly because the upper layers don't have to be concerned with whether the transmission was successful.
The word datagram describes a data transfer method in which the sender transmits data to the recipient without first establishing any kind of connection and without expecting any kind of response. Delivery is in no way guaranteed, so if there's any problem in transmission it's the responsibility of the recipient to notice it and request retransmission.
Datagram transmissions are similar to ordinary mail. Say you're sending a piece of mail to someone you're not on very good terms with, perhaps a former roommate or former spouse. You don't especially want to talk to them, but you want the mail to get to them in one pieceóif nothing else, so they don't call you looking for it. Therefore, before sending them the mail you carefully check the contents and the addressing information, but you don't call the person to tell them that there's a package on the way, and once the package leaves your hands you don't call them to make sure that he or she got it. Unless the person calls you to say that the piece of mail never got there, you're going to assume that it arrived as sent. The onus of error-handling rests with the recipient, not the sender.
Datagrams are fast and efficient because there's no error-checking information required with the transmission, but you can see that they can be a little uncertain. If you're the sender, the only way that you get feedback about the transmission is if something goes wrong. For more certainty, the sender can require the recipient to acknowledge receipt of each packet of the transmission, increasing overhead but also increasing the likelihood of transmission integrity. If the sender doesn't receive acknowledgment of all frames, he assumes that something went wrong and resends the unacknowledged frames.
To continue the mail analogy, the difference between a datagram and an acknowledged connectionless transmission is the difference between sending a package regular mail and sending the package registered mail. As you may know from experience, you send things registered mail if you want to have proof that the recipient got them. If the recipient never signed for the package, you have to assume that they never received it. It's still connectionless, as you don't establish a connection before sending the data, but it's easier to establish successful delivery because of the required receipt. If the sender doesn't receive confirmation of receipt, the package gets re-sent.
The surest way of transmitting data is to establish a connection before sending the data. Unlike the connectionless transmissions illustrated with the mail analogy, a logical connection is more like a telephone conversation. If you've got something to communicate to your friend across town, you don't just pick up the telephone and start talkingóyou dial their number, wait for them to pick up, and then give them the information. If they're not there (that is, if you can't establish the connection) then you don't transmit the data; instead, you make a mental note to try again later. But the important part is that you establish the connection before transmitting data.
So it is with a logical connection. Before the node that wants to send data begins transmitting, it first "calls" the recipient to make sure that it's available to receive data. If the proposed recipient doesn't answer, then the sender doesn't transmit the data. This pretty much ensures that the data reaches its destination in one piece, because the "conversation" doesn't end until the sender and recipient are both satisfied with the state of the transmission. This is a good transmission method to use when bridging LANs, as it relieves the upper layers of the responsibility of making sure that the transmission was successful.
So much for how bridges function in the theoretical world of the OSI modelówhat is their place in your network?
Bridges connect smaller networks to create one big one. This is different from repeaters (discussed earlier in this chapter) which extend the reach of your LAN by regenerating the signal, and different from routers (discussed in chapter 15, "Routers,") which connect individual networks but do not merge them. The difference lies in the OSI level at which bridges work: above the purely physical level, but (mostly) below any routing capabilities found in the Network Level. Essentially, the principal job of a bridge on a network is to connect network segments without burdening the entire network with traffic that only belongs on one segment, but they can perform other functions as well. We'll look at the various possible roles of a bridge on a network now.
Bridges keep records of the MAC addresses on each side of the segments they connect, and can compare the source and destination address of a packet with the addresses in the table. If the destination is local, then the bridge filters out the broadcast and leaves it on the local segment. If the destination is on another segment, then the bridge passes the data along to that segment. Either way, the data is only passed to the segment(s) where it belongs, so the network isn't tied up with broadcasts that belong only to one segment.
A bridge's filtering capability also makes it configurable for security purposes. You're probably quite familiar with the idea of limiting access to shared drives, directories, and files with user rights, file permissions, and passwords, but this kind of restriction goes one step further. Using the filtering capabilities of a bridge, you can forbid any physical connection between nodes, making it impossible for an engineer, for example, to access the accounting files from his local machine. You still need the logical security of passwords and user rights to protect against those times, but if you're feeling really hyper about security, address filtering can give you an added layer of protection.
Of course, if you've got users, you've got potential security breaches. If you're running NetWare, for example, you can substitute a node's physical MAC address for a logical one, thus bypassing any security relying on blocking a particular MAC address from accessing a particular segment.
As many networks are not the result of careful planning to produce an integrated system, the capability of some bridges to link more than one kind of network can be useful in making the corporate network more integrated. We're not talking about linking merely physically different networks here (for example, 10Base2 Ethernet and 10Base5 Ethernet)óa repeater can do that. This is about connecting networks that transmit data in entirely different ways and using different packet forms.
As you're no doubt aware, Ethernet and Token Ring (to use the two most common network types in today's LANs) don't work in the same way. Ethernet networks broadcast their data to every node within hearing (that is, on the segment before the bridge) but only the node for which the data is intended really pays attention. Token Ring networks seek to avoid the possibility of two nodes trying to "talk" over each other that's inherent in broadcast networking. To do this, they pass around a null packet called a token that acts like a talking stick in a lodge meetingóonly the node with the talking stick gets to transfer data at any given time. The packet forms for these two paradigms of networking vary as well, as you can see in figure 14.3.
Figure 14.3 An Ethernet frame contains different information from a token-ring frame.
Therefore, it's a touchy proposition for these two network types to communicate. For a bridge to translate these network types, it must convert the frame headers and data fields of the packets to be translated.
Protocol conversion only works with like hardware, such as micros to micros or PCs to PCs. If you need a gateway to help the machines talk to each other (such as a PC to mainframe connection), then you still need the gateway even with the protocol conversion. A bridge won't work, for example, to connect an Ethernet PC to a Token Ring VAX.
The packet's frame header and data field must be converted in order to transfer a Token Ring packet on an Ethernet network or vice versa. Essentially, protocol conversion works like this: token-ring packets are stripped of the LLC protocol used for source routing, thus removing extraneous routing data that would only confuse the Ethernet network. Once on the Ethernet side, the packets are converted to Ethernet packets and sent on their way. Ethernet packets that must get to the token-ring network have routing information added, because token-ring bridging requires the packets to carry routing information within them. The bridge adds the routing information from its own address database. No matter which way the packet travels, however, only the address changesóthe data within the packet never gets touched.
Because protocol conversion connects a Token Ring network to an Ethernet network, it requires a bridge that can speak to both. Spanning tree or source routing bridges won't work for thisóyou need a bridge that can perform translation functions for this to work.
When playing traffic cop in order to keep network congestion to a minimum, a bridge's most important question is whether a packet should be filtered or forwarded. If the packet's destination is on the same network segment as the sender, then the packet is filtered out of the bridge and sent to its destinationóthe bridge doesn't have to do anything with it. If the packet's destination is on another segment, however, then it's forwarded to the bridge that connects to that segment. If the segment is not directly connected to the bridge forwarding the packet, then the bridge will send it to a bridge on the way to the proper segment. That bridge will then filter or forward the packet again, and so on until the packet gets forwarded to the proper segment and can be sent to its destination. The process is illustrated in figure 14.4.
In a nutshell, filtering works like this: the bridge checks the destination address in the packet header. If the destination address is on the same segment as the source address (as shown in the bridge's routing table) then the bridge filters the packet. If it is on a different segment, the bridge forwards the packet to the other active port. It's pretty much a no-brainer for the bridge, which is why bridges can keep up with network speeds.
The exact method by which the bridges determine how to route the packet depends on the routing method used, as discussed later in this chapter.
You may see a similarity in the function of a bridge and a network redirector. We've discussed redirectors earlier in this book. They're the part of the network operating system that determines whether a command to the system hardware should be sent to the local hard disk (or a network-accessible hard disk. The redirector is necessary because most applicationsóword processors, spreadsheets, and gamesódon't know or care what networks are. They open files and save files, but whether those files are on a local disk or a disk across the room or state is not the application's concern. The network redirector monitors all disk accesses and determines the location of the hard disk that the application is asking for. If the disk access is local, then the redirector steps back and lets the operating system handle the transaction. If the disk access requires the network, the redirector puts on its operating system hat (this is transparent to the application and user) and redirects the command to the network.
This is essentially the same thing that a bridge is doing when it filters. The user (and node) shouldn't have to care whether the destination address is on the local segment or a bridged segment; the user accesses the network, and the bridge determines how the network access should be routed.
Bridges forward packets from one segment of a network to another. Each bridge port is assigned an address for the segment to which that port is connected. When the bridge receives a packet, it looks at the packet's destination address and sends the packet to the port associated with that address. If the destination address isn't associated with any port (that is, if it's not in the bridge's routing table), then the bridge sends the packet to all of its ports. This is called flooding, and it's a perfectly normal thing for a bridge to do when attempting to discover the segment in which a particular destination address resides. (If a bridge is malfunctioning, it may flood the network unnecessarily, tying up traffic on the network with traffic that only belongs on one segment.)
Bridges aren't restricted to filtering based on addressing, however. Depending on the model of bridge, you can configure the bridge to filter based on the source address, destination address, bridge priority, port number, or any of several others. A few bridges (Computer System Product's StackUp Series Branch Office Relay and Presticom's BCX-6000 are two) even let you define custom filter types, although these bridges also make sure to have some default filter options as well.
Whatever the filter criteria used, all filters work pretty much the same. Almost all are based on the MAC addresses of the network devices. Bridges don't understand network destinations; they just understand MAC addresses, so they cache all MAC addresses that they receive to make a routing table. Once this table has been created, you can set the bridge to filter or forward packets to the addresses in the table, but you need the table first. As you'll see in chapter 15, "Routers," this differs from routing access lists. In routing access lists you have a wider latitude in how you can set router filtering than you have with bridges. Instead of being limited (mostly) to MAC addresses, you can set routers to grant or deny access permissions based on a MAC address, a node address (IP address), IPX number, network number, application call, or IP number. (Thanks to Curtis Taylor for the excellent explanation of the difference between bridge route tables and routing access lists.)
The simplest method of bridging involves no previous route determination or intelligence in packet addressing. One bridge connects two segments and relays packets between them. This method, called transparent bridging, simply relays packets between network segments. Transparent bridging may use any of the routing types discussed here. The important part is that the bridge does not have to do anything to the packets it forwards to make them intelligible to the nodes on the other segment.
Translation bridging is used to connect networks that use different packets, such as Ethernet and Token Ring. The matter is a little trickier than just adjusting the contents of the packet header. Token Ring bridging requires some network traffic that isn't data, just so the nodes can get the routing information they need to address their packets properly. These null packets look like garbage to the Ethernet segment, which only passes data. Show a route discovery packet to an Ethernet segment, even with the routing information stripped off it, and the segment won't know what to do with it.
Therefore, the process of translating the packets from one network type to another requires the bridges to do a little disguise work. On the Ethernet side, the bridge pretends to be one more Ethernet node. When nodes send network traffic meant for a station on the Token Ring side, the bridge claims the packets for its own, satisfying the sending node which only wants to know that the data it sent arrived safely. Once the bridge receives the packet, it puts on its Token Ring hat, writes the routing information into the packet, and sends the data on its way. On the Token Ring side, the bridge looks like just another bridge. When it receives data meant for the Ethernet segment, however, it puts on its Ethernet hat, strips the excess routing (but not addressing) information from the packet, and broadcasts the packet on the Ethernet segment. The node with the matching destination address collects the packet and acknowledges it.
Discussing bridges leads to a lot of chicken and egg problemsóit's hard to talk about how filtering works without mentioning how the bridges figure out how to rout packets to their destinations. If you start with the routing discussion then the reason for routing is difficult to discern. The following sections discuss how the packets get to their destinations once they've been forwarded.
After the explanation of transparent versus translational bridging, you may wonder where routing becomes necessary. Once the packet gets to the segment where its destination lies, it would seem to be a simple matter to get the packet home. In simple networks, this is true. If there's only one possible path between segments, then the bridge must only act as a relay center as shown in figure 14.5.
Figure 14.5 A simple bridged network requires no route discovery.
A bridge filters packets with a destination that's on the same segment as the sender and forwards packets on a different segment, so the data flows neatly in one port and out the other.
Most networks are more complicated than this, however. They may have an extra bridge for redundancy (in case the first fails) or to provide a connection to a different segment. Whatever the case, once you introduce a second bridge you introduce a second path for the data to travel (see fig. 14.6).
Figure 14.6 If more than one bridge connets the segments, only one path can be used.
To see why this is a bad thing, remember the following things:
In this scenario, illustrated in figure 14.7, a node on segment 1 has a message for a node on segment 2. Bridge 1 hears the message, notes that the address is not on segment 1, and so forwards it to segment 2. Bridge 2 hears the message broadcast to the segment 2 and forwards it to segment 1. Bridge 1 hears the message, forwards it to segment 2... and so on. This is called looping, and it kills your network because it ties it up with unnecessary garbage that can never be cleared.
Figure 14.7 Bridge looping ties up your network with perpetual trafic and renders it inoperable.
To avoid looping, you'll need to purchase a bridge that uses one of the routing algorithms discussed in the sections that follow. Which one you choose depends on your network and specific needs. Once the packet is sent to the port connecting to the segment where its destination resides, its journey may not be over yet. Unless the network is a fairly simple one, with only one bridge, the packet might be sent first to one bridge on the way to its destination and then routed to another segment. The route that the packets must take depends on several variables: the physical layout and complexity of the network, the traffic patterns, and even the type of network being bridged. To describe the ways in which various bridges determine the best route to send packets along, several algorithms have been developed.
DEC and Vitalink developed the first bridge routing standard, known as the spanning tree algorithm (STA). This algorithm, adopted as a standard by the IEEE 802.1 committee, permits bridges to establish a "best route" to reach a given segment, and then block off less desirable routes. This avoids the problem of looping described in the previous section.
Under STA, each bridge has an identifier with two parts: a priority level and an address. On power-up of the network, all the bridges in the network exchange information about their addresses and relative priority, until all recognize one bridge as having the highest priority. It's possible for more than one bridge to have the same priority level, so if this happens the bridge with the highest address outranks the others. The highest-ranking bridge is called the root bridge, and all other bridges define themselves in relation to that bridge. The process of determining a root bridge is illustrated in figure 14.8.
Figure 14.8 The bridge with the highest network priority becomes the root bridge.
You (as the network administrator) can stack the deck to make a particular bridge the rootójust give it a higher priority than any other bridge when you're setting it up.
After the root bridge has been determined, all the other bridges in the network determine which of their ports point to the root bridge (this part looks like a little like the star logical topology, as all bridges are oriented toward a central point). That port becomes each bridge's root port, and it represents the direction from which that bridge will receive data. To send data, the bridge identifies one port leading away from the root port
If a bridge doesn't have a direct connection to the root bridge, it must choose a path by way of an intervening peer bridge. The bridge it chooses is the one with the lowest transmission costs; that is, the fastest line, the least amount of traffic, and the greatest buffer capacity. If all costs are the same, the route to the root bridge will be determined by the fewest hops required to pass data from one LAN to another.
After all the negotiations as to what is the root bridge and which ports each bridge will use for incoming and outgoing data, the bridges set those ports for forwarding and block the others. All other ports are blocked for forwarding, so that there's one pipe in and one pipe out. Any other ports are not disabled but they don't pass any packets. If one of the active ports stops working, a blocked port goes into learning modeóa sort of apprenticeship to becoming a forwarding port. During this apprenticeship, the blocked port examines the packets on the network, learns where all the bridges are in relation to each other, and then becomes a forwarding port. This should happen without any action being required on the part of the network administrator. Figure 14.9 shows a network using the spanning tree algorithm for packet routing.
Figure 14.9 A spanning tree network blocks certain paths to avoid looping.
How static are these port configurations? Obviously, the best route at 9 AM might not be the best at 3:30 PMóperhaps a bridge may have gone down, or there's a lot of traffic on one segment of the network. Thus, each bridge maintains a timer in the address database that it keeps. If the timer for a destination address on Segment B runs out, the bridge checks to see if the route that it's been taking to get to Segment B is still good, or if a more efficient way has turned up since it last checked. If the network topology hasn't changed, then the bridge will select the same route and reset the timer; otherwise, it will search for a new route.
Although the spanning tree algorithm has the advantage of being protocol independent, it does not work for all networksóit is for Ethernet networks only. Although Ethernet is a more popular network type than Token Ring, IBM found it necessary to come up with a routing scheme of its own for networks too complicated to work with transparent bridging. This scheme, introduced in 1985, is called source routing.
Source routing is IBM's proprietary routing schemeóit's required to bridge Token Ring networks. In fact, if you're using one of IBM's operating systems (OS/2 or LAN Server) and you want to bridge the network, you must use source routing.
Because it's really active above the data link layer of the OSI model, source routing depends on the network operating system to cooperate in route discovery. Therefore, not every NOS will support it. NetWare, Banyan VINES, OS/2, and LAN Manager are among those that do.
As it is not protocol independent (unlike STA) and relies on the network operating system to function, source routing has never caught on as well as the spanning tree algorithm (also due to the fact that Ethernet networks are more popular than Token Ring). However, source routing has got some design features that spanning tree lacks, so its existence is far from unnecessary. Spanning tree is static (until the timed intervals when it checks the paths that it's using to reach a particular segment; source routing checks the path every time that it sends data. There's more overhead involved, because every time a packet crosses the network it's got to carry routing information with it, but in a network that changes frequently due to new members, breaks or other circumstances, source routing would be able to pick up on the changes more quickly than spanning tree.
Logically speaking, there are three kinds of objects in a source routed network: the nodes, the bridges, and the segments (or in this case, rings, as by definition we're talking about Token Ring networks). Each of these objects has a unique address. The nodes get a 6-byte address, the bridges a 4-bit number, and the rings a 12-bit number.
Although the nodes in a source-routed network do all the legwork in route discovery, each of the different object types plays a part in the process. To find the best route, the networked PCs need a road map of the network. Their first step is to broadcast a message to another node, but without specifying any particular segment or route that the packets in the message should take. This message is called a discovery packet, and contains buffer areas for the other network objects to fill in their numbers. As the discovery packet bounces around the network, attempting to find its destination, the bridges fill in the numbers for the rings which they connect and their own bridge numbers. When the packet reaches the destination node, it returns the packet to the sending node, thus giving the sender a road map of the path which the packet took. This process is illustrated in figure 14.10.
After the sending node has figured out where all the pieces of the network are, it can send data. The sending part of the process looks like a normal Token Ring topology, except that the packets holding the data have the routing information embedded in the packet. The address field in a source routed packet has two main components: the I/G (individual/group) bit and the U/L (universal/local) bit. The I/G bit indicates whether the address is for an individual or a group, and the U/L bit indicates whether the address is a universal address supplied by the IEEE or a locally-made address to override the IEEE address. Source routing takes the I/G bit in the source address (not the destination, but the address of the node sending the packet) and uses the information to set another bit, the routing information bit (RI), that indicates whether there's additional routing information required to get the packet to its destination. If the RI bit is set to 1, as many as 18 bytes of routing information are included in another field, thus providing an itinerary for that packet. That itinerary comes from the road map developed during the discovery phase. There's one limitation here: because the RI field is limited to 18 bytes, there's only room to define eight ring numbers (including the source ring), so the packet can only take as many as seven hops to get to its destination. The routing path uses the lowest number of hops possible. See figure 14.11 to see how the routing process works.
Figure 14.11 The presence of the RI bit determines how packets are routed across the network.
This sounds complicated, but the end result is straightforward: the packets have all the routing information embedded in them, so all that the bridges must do is look at the itinerary in the packet, note which ring the packet must get to and the route required to get it there, and send it on its merry way.
You can make a source routed network act like a spanning tree network. In this case, the route discovery packet identifies only a single route between the source and destination (choosing the one with the lowest cost or fewest hops). The road map that the sending node gets back only shows one path to its destinations, so the routing information embedded in the packet only permits the bridge to send the packet using one path. This avoids any looping and dual packets. You can see how this works in figure 14.12.
Figure 14.12 Source routing can be configured to work like the spanning tree algorithm.
Because source routing can keep up with network changes more easily than the spanning tree algorithm, why would you want to make source routing act like spanning tree? The answer is the one common to almost all networking questions: speed. Source routing requires more overhead than spanning tree because the fluid routes permit route discovery. If the network hasn't changed since the last time a node's road map was created, however, the route discovery is a waste of time. Therefore, if you create a rigid series of paths in the network you remove some of the flexibility but decrease the overhead.
Remember the Reese's Peanut Butter Cups commercials that had two people walking aroundóone eating chocolate and the other eating peanut butteróuntil they ran into each other, mixed up the two, and discovered an entirely new taste treat? That's sort of how source routing transparent (SRT) bridging works. Ethernet's spanning tree method is nice, but the routes are fairly static. Source routing is nice too, but it's NOS-dependent. Both of them have the drawback of only working with one kind of electrical topology: you can have Ethernet, or you can have Token Ring, but you can't have both.
Well, you can have bothóif you use a translating bridge with a routing method called source routing transparent (SRT). SRT bridges can translate packets from one form to another, so that the two networks can be connected. In fact, SRT bridges arerequired for the purpose: if your network includes both Token Ring and Ethernet segments, then you'll need a SRT bridge to connect them and translate. The SRT bridge is only necessary at the point at which the two network types connect, however, to connect Ethernet to Ethernet or Token Ring to Token Ring you can use a spanning tree or source routing bridges as necessary.
Source Routing Transparent bridging is not limited to networks with split personalities. You can also use SRT bridges in Token Ring networks to make the network protocol independentóif it runs on Token Ring, it will work with an SRT bridge.
Sometimes when you're bridge shopping you'll notice bridges that support network layer routing. "Wait a minute," the alert shopper will say, "bridges are datalink layer devices. How can a bridge be doing anything with the network layer?"
The answer, of course, is that it really isn't. The device that you're looking at is not exactly a bridgeóit's a hybrid bridge/router sometimes called a brouter. Brouters are devices that perform the functions of both bridges and routers so that you can connect networks using protocols that can't be routed, such as NetBIOS/NetBEUI and SNA. Confusingly, they're often listed as bridges, but if the device does anything at the network layer, it's not a pure bridge.
Network layer routing (NLR) looks at the node's network layer address, such as an IP address, to decided how the packet should reach its destination. Because routing is covered in detail in the following chapter, we'll leave a complete discussion of how routing works for chapter 15, "Routers."
The key questions to consider when purchasing any network connection hardware are as follows:
No matter what you're buying, these questions are the ones to answer before purchasing.
Networks aren't static and often they aren't simple. Vendors know that, so it's not hard to find repeaters that have a fighting chance of keeping up with you. The Black Box catalog, for example, sells both modular repeaters that you can design to exactly fit your cabling needs, and a variety of media combinations if you want to buy an off-the-shelf model. If you're not sure about the direction in which your network will evolve, a modular repeater is an easy way of maintaining your flexibility for about the same price as a solid repeater. If one segment of your network changes media, you can swap out the old module for the new one without taking down the rest of the network.
The price of a repeater or bridge is based both on the number of ports in the device and the special features that it offers. For example, a transparent bridge costs less than a similarly capable translating bridge. Decide what you need, and then shop for a device that provides it. Once again, a modular bridge may give you a little more flexibility. Also, when comparing similar bridges, calculate how much you're paying per port.
If you want your repeated network to have management ability tied in with the rest of your network, look for a model with SNMP built in or attachable. Make sure that the SNMP implementation is MIB-II compliant, and don't forget that the management capabilities of an SNMP-managed system vary, so ask for a listing of exactly what the management module can manage before you purchase.
Notice how you're treated when shopping and collecting information. Although it's not a sure bet that a company that is helpful and supportive to potential customers will always be there for you after you've made the purchase, a vendor who's unwilling to help you collect information before purchasing probably won't improve when you need help with the unit. Notice things like how long you must wait for technical support (the best source of detailed information about a given unit), and whether they call back if you leave messages. I'd be a little wary of vendors that know very little about the products that they sell.
In this chapter, we discussed two of the devices that you can use to extend your network's reach: repeaters and bridges. The one you need depends on what you want to do. Repeaters are physical layer devices that extend the reach of a given network but don't restrict network traffic. Bridges are data link layer devices that both extend your network's reach and limit traffic to the node on which it belongs.
Bridges support a number of different filtering and routing methods to get your data to where it needs to go. The simpler the routing method, the less overhead is required but the less flexible the network is to changes in its topology. Although most bridges are limited to linking networks using the same logical topology, SRT bridges can permit token-ring and Ethernet networks to communicate
