61
while technicians are doing other work. But even if fiber is never touched and the conduit remains sealed forever, eventually it degrades due to a host of environmental hazards, such as background radiation.
All of this information is intended to scare the reader into worrying about trunk failures. In most network designs, the trunks are the first things I would want to provide redundancy for. There are many ways to do
so. The actual redundancy mechanism depends on trunk type. If the trunk is itself a multiplexed collection of links like Ciscos EtherChannel or Nortels MultiLink Trunking, then redundancy is inherent in the
design. In this case, it would be wise to employ an N+1 redundancy system. This means that the trunk capacity should be sized as discussed in the previous section, and then increased by one extra link. This
way, there is still sufficient capacity if any one link fails.
However, if a single fiber pair carries the trunk, then the only useful way to add redundancy is by running a second full-capacity trunk link. Since one of the main concerns is environmental or physical damage to the
fiber, putting this second link through a different conduit makes sense.
The only remaining question is whether to make the backup trunk link a hot standby or to have it actively share the load with the primary link. And the answer, unfortunately, depends on what you can get with the
technology youre using. In general, if you can do it, load sharing is better for two reasons:
•
In case you inadvertently underestimate your trunk capacity requirements, or in case those requirements grow over time, load sharing gives you extra bandwidth all the time.
•
If the primary can fail, so can the backup. The difference is that you notice when the primary fails, and you dont necessarily know when the backup fails. If traffic goes through it all the time, then
youll usually know pretty quickly that youve had a failure of your backup link.
3.4.3 Switching Versus Routing
In the discussion of backbone designs, I mentioned that the same general design topologies are applicable to both Layer 2 and Layer 3 implementations. Thus, at many points the designer can choose to either
bridge or route. There are philosophical reasons for choosing one or the other in many cases, but there are also several practical reasons for favoring either switching bridging or routing implementations.
3.4.3.1 Ancient history
The old rule for designing large-scale LANs was bridge on campus, route off campus. There were good reasons for this rule, but many of these reasons are less relevant today than they once were.
Figure 3-11 shows an example of a LAN designed using this rule. It consists of a number of separate Ethernet-based
work groups, all interconnected via an FDDI ring. I dont call this an old-style design to disparage it. In its day, this was cutting-edge technology. Although I modify the basic rule later in this chapter, the general
design concept points out some important principles of network design that are still applicable.
62
Figure 3-11. Old-style bridge on campus, route off campus design
Suppose that the network protocol in this diagram was TCPIP. The entire campus, then, would have been addressed from the same large address range, such as a Class B or Class A. In fact, because all of these
segments were bridged together, there would have been no technical requirement to break down the user segments into their own specific address ranges. The whole campus looked like one gigantic common flat
network at the IP layer.
In practice, however, most network administrators would have broken down their larger address range into subranges, and allocated these subranges to different user LAN segments. This allocation would be done
purely for administrative reasons and to make troubleshooting easier.
In this old-style design, if someone on one of the user LAN segments wants to access the central database, they first look up the IP address probably using DNS. They then send out an ARP Address Resolution
Protocol packet to find the Ethernet MAC address associated with this IP address. This ARP packet goes out through the bridge and onto the FDDI backbone ring. Every other bridge on the ring forwards this
packet onto its local segment. Eventually, the packet reaches the database server, which responds appropriately.
This approach immediately points out one of the important limitations of this design principle. Broadcast packets like the ARP packet in the example are sent to every distant corner of the network. This may be
fine if there is very little broadcast traffic, but some broadcasts, like ARP, are a Core part of the network protocol. Every station sends broadcasts. There are necessarily limits to how big one can make a bridged
network before routine broadcast traffic starts to choke off production application traffic.
This model does a nice job of segregating the regular application traffic, though. Suppose a user on the left side of the picture talks to a server on the right with regular unicast packets. Each packet on both sides of
the conversation contains the Ethernet MAC address of the destination device. All bridges are smart enough to keep track of the MAC addresses on each port. So, a packet heading for the database server
enters the FDDI ring because the users local bridge knows to find that MAC via the ring. Then every other
63
bridge on the ring simply leaves the packet alone until it reaches the one that has that MAC address on its LAN segment. Thus, normal application traffic takes an efficient direct route.
Now consider traffic destined for the remote site shown on the far right-hand side of the picture. Two rules of networks are almost immutable. The first is that bandwidth costs money; the second is that distance
costs money. From these two rules, it is safe to conclude that high bandwidth over long distances costs a lot of money. Whatever technology is used to connect to the remote site, it almost certainly has much
lower bandwidth than any LAN element.
This point is important because the rule was bridge on campus, route off campus. In other words, it says that you should bridge where bandwidth is cheap and route where its expensive. Bridging allows all
broadcast chatter to go everywhere throughout the bridged area. You simply want to avoid letting this chatter tie up your expensive WAN links. On the LAN, where bandwidth is cheaper, you will want to use
the fastest, cheapest, most reliable technology that you can get away with. At least in earlier times, that meant bridging.
A bridge is generally going to be faster than a router because the decisions it makes are much simpler. The manipulations it does to packets as they pass through it are much simpler as well. In the example, these
bridges interconnect Ethernet and FDDI segments, so the Layer 2 information in the packets needs to be rewritten. This is a simpler change, though, than what a router needs to do with the same packet.
3.4.3.2 Modernizing the old rule
