09.12.2012 Views

Understanding the network.pdf - Back to Home

Understanding the network.pdf - Back to Home

Understanding the network.pdf - Back to Home

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

The routing entry for <strong>the</strong> intranet side (same example) would look like this:<br />

Destination Network Mask Gateway<br />

0.0.0.0 0.0.0.0 12.127.247.109<br />

As far as <strong>the</strong> intra<strong>network</strong> is concerned, it sends all datagrams for which it has no<br />

local route <strong>to</strong> <strong>the</strong> interexchange, where <strong>the</strong>y become <strong>the</strong> ISP's problem. This<br />

functions <strong>the</strong> same way as a default route on a host, and <strong>the</strong> entire intranet's<br />

datagrams are sent <strong>to</strong> <strong>the</strong> backbone router.<br />

The backbone-<strong>to</strong>-backbone interexchange point is where <strong>the</strong> power of dynamic<br />

routing comes through. In most <strong>network</strong>s, links are point <strong>to</strong> point. In o<strong>the</strong>rs,<br />

redundancy is important, so multiple <strong>network</strong> links are used <strong>to</strong> connect some of <strong>the</strong><br />

segments. In our example, <strong>the</strong> inter<strong>network</strong> backbone is using a partial mesh<br />

<strong>to</strong>pology. With a partial mesh, each of <strong>the</strong> routers has more than one possible route<br />

path <strong>to</strong> any <strong>network</strong> point. A full mesh is where every device on <strong>the</strong> <strong>network</strong> has a<br />

redundant path <strong>to</strong> every o<strong>the</strong>r device on <strong>the</strong> <strong>network</strong>. Full mesh <strong>network</strong>s are<br />

extremely cost prohibitive; in most cases, a partial mesh approach can adequately<br />

meet most <strong>network</strong>ing requirements. The problem from a routing point of view is<br />

managing a routing table for a <strong>network</strong> that is comprised of so many alternative<br />

routes. Although diversity is good <strong>to</strong> ensure that <strong>the</strong> datagrams get delivered, it can<br />

cause havoc with routing. With diversity comes a large routing table.<br />

To get an idea of how large a regional <strong>network</strong>'s table could get, look at <strong>the</strong> possible<br />

backbone paths available for intranets homed on GW1. To get <strong>to</strong> <strong>the</strong> intranets<br />

homed on <strong>the</strong> o<strong>the</strong>r backbone routers, <strong>the</strong> paths available <strong>to</strong> route packets <strong>to</strong> <strong>the</strong><br />

Internet exchange points are as follows:<br />

GW1 <strong>to</strong> GW2<br />

Path Number of Hops<br />

gw1, gw2 2<br />

gw1, gw3, gw5, gw2 4<br />

gw1, gw3, gw4, gw2 4<br />

gw1, gw4, gw2 3<br />

gw1, gw3, gw4, gw5, gw2 5<br />

gw1, gw3, gw5, gw2 3<br />

gw1, gw3, gw5, gw4, gw2 5<br />

GW1 <strong>to</strong> Internet GW Number of Hops<br />

gw1 1<br />

gw1, gw3, gw5 3<br />

gw1, gw4 2

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!