Figure 73 An internetwork using a distancevector routing protocol

Table 7-3: The Number of Hops with the Distance-Vector Protocol

Router

Destination

Next Hop

Number of Hops to Destination

A

172.16.0.0

B

1

A

192.168.125.0

C

1

A

192.168.253.0

B or C

2

B

10.0.0.0

A

1

B

192.168.125.0

C

1

B

192.168.253.0

D

1

C

10.0.0.0

A

1

C

172.16.0.0

B

1

C

192.168.253.0

D

1

D

10.0.0.0

B or C

2

D

172.16.0.0

B

1

D

192.168.125.0

C

1

In any internetwork with redundant routes, it is better to use a distance-vector protocol than to use static routes. This is because distance-vector routing protocols can automatically detect and correct failures in the network. Unfortunately, they aren't perfect. Consider the routing table entries for Gateway Router A, for example. This is the New York gateway. From its perspective, the Minneapolis gateway is two hops away, regardless of whether it goes through Philadelphia or Seattle. In other words, this router would be indifferent to accessing Minneapolis through either Philadelphia or Seattle.

If all the variables in the network were held constant (including such things as traffic levels, the bandwidth of each link, and even transmission technology), the geographically shortest path would incur the least amount of propagation delay. Therefore, logic dictates taking the shorter route, through Philadelphia. In reality, such logic is beyond the capabilities of simple distance-vector protocols. Distance-vector protocols aren't exactly limited by this because propagation delay is often the least significant of the factors driving the performance of a route. Bandwidth and traffic levels can both have much more noticeable effects on the performance of a network.

0 0

Post a comment