Routing Versus Bridging

{\rtf1\ansi\ansicpg1252\deff0\deflang16393{\fonttbl{\f0\froman\fcharset0 TimesNewRoman;}{\f1\fswiss\fcharset0 Arial,Bold;}{\f2\fnil\fcharset0 Calibri;}}
{\colortbl ;\red53\green66\blue120;\red0\green0\blue0;}
{\*\generator Msftedit 5.41.21.2509;}\viewkind4\uc1\pard\lang9\f0\fs21 Routing means sending packets from one Layer 3 network region to another using Layer 3 addressing\par
information. These two Layer 3 regions could use different Layer 1 or 2 protocols. For example, one may\par
be Ethernet and the other ATM. So part of the routing process requires taking the Layer 3 packet out of the\par
Ethernet frame in which it was received, deciding where to send it, then creating ATM cells to carry this\par
packet. Because ATM uses a cell size that is much smaller than the Ethernet packet size, the router has to\par
chop up the Layer 3 packet and wrap each fragment in an ATM cell before sending it. When receiving\par
from the ATM side, it has to wait until it receives all of the ATM cells that form one Layer 3 packet,\par
reassemble the fragments in the correct order, and wrap it up in an Ethernet frame before sending it on.\par
This allows easy transfer of data between LAN and WAN or between different LAN types.\par
Technically, bridging has some overlap into the Network Layer as well, because it specifies how the\par
broadcast domains that are part of the Data Link Layer can interact with one another. But the special\par
difference between routing and bridging is that in routing the Data Link properties don't need to have\par
anything in common. It is easy to route IP from Ethernet to Token Ring without needing to consider\par
anything but the IP addresses of both ends. But in bridging, the MAC (Media Access Control) addresses\par
from one side of the bridge are maintained as the frame crosses over to the other side.\par
It is possible to bridge from Ethernet to Token Ring, for example. But the Token Ring devices must\par
believe that they are talking to another Token Ring device. So the bridge has to generate a fake Token Ring\par
MAC address for each Ethernet device, and a fake Ethernet MAC address for each Token Ring device\par
taking part in the bridge.\par
With routing, though, there is only one MAC address visible, that of the router itself. Each device knows\par
that it has to communicate with all off-segment devices through that address.\par
So routing scales much better than bridging when large numbers of devices need to communicate with one\par
another. But the drawback is that the extra work of translating from one data-link layer to another means\par
that the router has to read in every packet, decide where to send it, reformat it for the new medium, and\par
then send it along.\par
With switching, however, it is possible to read in just enough of the packet to figure out where it needs to\par
go and then start sending it out before it has all been received. This is called cut-through switching. Storeand-\par
forward switching, in which the entire packet is read before forwarding, is also common. But the\par
bottom line is that switching is generally faster than routing.\par
Layer 3 switching is sort of a hybrid. If you know that you are switching between like media, then the only\par
things you need to change when you pass the packet along are the source and destination MAC addresses\par
(and the checksum will also need to be corrected). This is considerably less work than the general mediaindependent\par
problem of routing. So these Layer 3 switches are usually faster than a general-purpose router.\par
The other advantage of a Layer 3 switch over a router is that it can often be implemented as a special card\par
in a Layer 2 switch. This means that it is able to do its work while touching only the backplane of the\par
switch. Because the switch backplane doesn't need to go very far, and because it usually runs a proprietary\par
high-speed protocol, it is able to run at extremely high speeds. So it is as if you were able to connect your\par
router, not to a 100-Mbps Fast Ethernet or even to 1000Mbps Gigabit Ethernet, but to a medium many\par
times faster than the fastest readily available LAN technologies. And this is done without having to pay a\par
\pard\sa200\sl276\slmult1 lot of extra money for the high speed access.\par
\par
\pard\cf1\b\f1\fs30 1.4 Top-Down Design Philosophy\par
\cf2\b0\f0\fs21 Once the actual requirements are understood, the design work can begin, and it should always start at the\par
top. Earlier in this chapter I described the standard seven-layer OSI protocol model. The top layer in this\par
model is the Application Layer. That is where one has to start when designing a network. The network\par
exists to support applications. The applications exist to fulfill business requirements.\par
The trick is that the network will almost certainly outlive some of these applications. The organization will\par
implement new applications, and they will likely have new network requirements. They will form new\par
business units, and new departments will replace old ones. A good network design is sufficiently flexible\par
to support these sorts of changes without requiring wholesale redesign. This is why an experienced\par
network designer will generally add certain philosophical requirements to the business requirements that\par
have already been determined.\par
The network needs to be scalable, manageable, and reliable. Methods for achieving each of these topics\par
will be examined in considerable detail throughout this book. It should be obvious why they are all\par
important, but let me briefly touch on some of the benefits of imposing these as requirements in a network\par
design.\par
Making a design scalable automatically dismisses design possibilities where switches for different\par
workgroups are either interconnected with a mesh or cascaded one after another in a long string.\par
Scalability will generally lead to hierarchical designs with a Core where all intergroup traffic aggregates.\par
Manageability implies that you want to see what is going on throughout the network easily. It will also\par
demand simple, rational addressing schemes. Some types of technology are either unmanageable or\par
difficult to manage. You probably wouldn't want to eliminate these outright because they may be cost\par
effective. But you probably don't want to put them in key parts of the network.\par
Reliability is usually the result of combining a simple, scalable, manageable architecture with the business\par
throughput and traffic-flow requirements. But it also implies that the network designer will study the\par
design carefully to eliminate key single points of failure.\par
There are other important philosophical principles that may guide a network design. A common one is that,\par
except for specific security exclusions, any user should be able to access any other part of the network.\par
This will help ensure that, when new services are deployed, the network will not need to be redesigned.\par
Another common design philosophy says that only network devices perform network functions. In other\par
words, never use a server as a bridge or a router. It's often possible to set up a server with multiple\par
interface cards, but this philosophy will steer you away from doing such things. Generally speaking, a\par
server has enough work to do already without having the resources act as some kind of gateway. It will be\par
almost invariably slower and less reliable at these functions than a special-purpose network device.\par
If your network uses TCP/IP, will you use registered or unregistered IP addresses? This used to be a hotly\par
debated subject, but these days it is becoming clear that there is very little to lose by implementing a\par
network with unregistered addresses, as long as you have some registered addresses available for addresstranslation\par
purposes.\par
Perhaps the most important philosophical decisions have to do with what networking standards will be\par
employed. Will they be open standards that will allow easy interoperability among different vendors'\par
equipment? Or will they be proprietary to one vendor, hopefully delivering better performance at a lower\par
price? It is wise to be very careful before implementing any proprietary protocols on your network because\par
it can make it exceedingly difficult to integrate other equipment later. It is always possible that somebody\par
will come along with a new technology that is vastly better than anything currently on the market. If you\par
want to implement this new technology, you may find that the existing proprietary protocols will force a\par
\pard\sa200\sl276\slmult1 complete redesign of the network.\par
\par
\cf0\f2\fs22\par
}