North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Receiving route with metric 0
Glen Kent wrote:
Am all the more confused now :)In pre-RFC1058 implementations the sender increments the metric, so a directly-connected route's metric is 1 on the wire. In post-RFC1058 implementations the receiver increments the metric, so a directly-connected route's metric is 0 on the wire. In both cases, the metric in a reciever's database one hop away is 1.Lets say we have A -- B. A is pre-RFC1058 and B is post RFC 1058. A sends a directly connected route as 1. B increments this by 1, and thus stores it as 2.
Let's start over, looking at the text that was in the erlier mail from RFC1058. A is a pre-RFC1058 and B is post-RFC1058. Host A stores directly connected networks with metric 0, "Using the previous perspective, the internal routing table has a metric of 0 for all directly-connected networks. The cost (which is always 1) is added to the metric when the route is sent in an update message." So host A sends RIP messages with metric 1 for directly connected networks. Now, for post-RFC1058, host B, "By contrast, in this document directly-connected networks appear in the internal routing table with metrics equal to their costs;" So, a directly connected network, unless it has for some reason a higher cost, host B will have a cost of 1. The value in the internal table is 1. "Metrics from the routing table are sent in update messages without change (unless modified by split horizon)." So host B will send RIP updates for directly connected networks with a metric of 1.
You appear to have it backwards. As it says in the section you quoted, "These two viewpoints result in identical update messages being sent." Either approach results in messages with metric 1. The metrics on theHmmm .. not sure. A post 1058 implementation would send a metric 0 for a directly connected route, assuming that the other end would increment the value and things would work out fine.
A post-RFC1058 implementation adds the cost before putting it in its internal routing table so a directly connected network has a cost of greater than or equal to one. This seems to be the point of confusion. A directly connected network in an RFC1058-style implementation must have a cost >=1. Why must a post-RFC1058 have a non-zero cost for a directly connected network? Imagine A and B were both post-RFC1058 and both had zero cost for directly connected networks. A would send updates to B with a zero metric for one of its directly connected networks. B would then add the cost of its link to A, which is zero, before putting it in its table. But 0 + 0 = 0... That is, the metrics never increment. It doesn't work. -- Crist J. Clark [email protected] Globalstar Communications (408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [email protected]