A model for decision making
The chapter begins with a recap of choices made in the last chapter about placement of switches and routers. It continues toward the goal of implementing protocols that are best suited for your design.
The first topic in the chapter could have been placed anywhere in the text. It is about making choices. It involves comparing the products we might choose, and judging them against what we want them to do, as well as what we require that they do. The best method our author knows for making choices between protocols starts with asking ourselves what we want and need to accomplish.
The author points out that a decision might be made based on just the first two steps, laying out the chart and scoring each possibility. She warns us that we should carry out the third and fourth steps as well, to avoid service outages, and to avoid problems with staff and customers.
The text spends a few paragraphs explaining that switches are better than bridges. Most of you have seen switches, but you may never have seen a bridge, so we can move on. On page 202, the text reminds us that a switch is meant to work on layers 1 and 2 of the OSI model. A hub does not notice MAC addresses, so it works only at layer 1. On a tangent, the text discusses other meanings of the word "switch", which is nice but it is not necessary.
The text reviews the essential functions of a network switch:
On page 203, the text begins a discussion of switching protocols.
On page 209, the text begins a discussion of routing protocols that continues to the end of the chapter. Routing protocols are typically sorted into two groups: Distance Vector protocols and Link State protocols. The text gives us a list of Distance Vector protocols first:
Distance Vector protocols are older protocols that are verbose and limited in range. They learn about routes from other routers, add those routes to a table of routes they know from their own connections, and then proceed to broadcast all of those routes to other routers about twice a minute. The problem with this method is that a router can learn about a new route, add itself to that route, and start advertising it with all the others as a new route with one more hop.
What is a hop? The text reveals that the phrase hop count has two meanings, and different protocols may use either one. A hop count can be either:
This makes comparing the length of two routes harder if they are calculated by two protocols that each use a different definition. Back to the problem. If a router adds itself to a route, and adds 1 to the hop count, it will add that to its table and tell every device in screaming range about it, over and over. Another device learns about it, adds itself to that route, adds 1 to the hop count, and guess who hears about it? They all do! Eventually, the hop count on these routes reaches 16, at which point a Distance Vector router refuses to use it, and it becomes worthless. The text explains three methods to remedy this insane behavior, none of which change it enough: split-horizon, hold-down, and poison-reverse. What else can we do?
Routers running Link State protocols have many healthier features. They only advertise routes they are on themselves. They only tell you about new information, or information about routes that have changed. They try to find the shortest path available. Some protocols that are link state protocols:
The author probably realizes that no one in their right mind would choose a Distance Vector Protocol were it not for one reason: they are often installed on routers by default, and they are easy to set up. So the text offers a list of reasons to choose each type of protocol.
Reasons to choose Distance Vector protocols:
Reasons to choose Link State protocols:
The chapter continues with several other methods of classifying protocols. It is worth reviewing material on static and dynamic routing on page 215. See my notes for this material on my notes to NET 222.
You should review the summary of protocols discussed in the chapter that appears on page 230.