Receiving route with metric 0

Mailman List Mirror (Read Only)
1

I am a little confused here. You yourself say that a valid metric
starts from 1, then how come 0 be valid for a directly connected
route. Are you saying that seeing a RIP metric of 0 on the wire is
valid?

RFC1058 says:

3.6. Compatibility

   The protocol described in this document is intended to interoperate
   with routed and other existing implementations of RIP. However, a
   different viewpoint is adopted about when to increment the metric
   than was used in most previous implementations. 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. By
   contrast, in this document directly-connected networks appear in the
   internal routing table with metrics equal to their costs; the metrics
   are not necessarily 1. In this document, the cost is added to the
   metrics when routes are received in update messages. Metrics from
   the routing table are sent in update messages without change (unless
   modified by split horizon).

   These two viewpoints result in identical update messages being sent.
   Metrics in the routing table differ by a constant one in the two
   descriptions. Thus, there is no difference in effect. The change
   was made because the new description makes it easier to handle
   situations where different metrics are used on directly-attached
   networks.

   Implementations that only support network costs of one need not
   change to match the new style of presentation. However, they must
   follow the description given in this document in all other ways.

In other words:

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.

Stephen

2

Stephen Stuart wrote:

I am a little confused here. You yourself say that a valid metric
starts from 1, then how come 0 be valid for a directly connected
route. Are you saying that seeing a RIP metric of 0 on the wire is
valid?

A metric of 0 from a host would mean that the host itself is the
endpoint for the route. See the discussion in section 2 of RFC1058.

RFC1058 says:

3.6. Compatibility

   The protocol described in this document is intended to interoperate
   with routed and other existing implementations of RIP. However, a
   different viewpoint is adopted about when to increment the metric
   than was used in most previous implementations. 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. By
   contrast, in this document directly-connected networks appear in the
   internal routing table with metrics equal to their costs; the metrics
   are not necessarily 1. In this document, the cost is added to the
   metrics when routes are received in update messages. Metrics from
   the routing table are sent in update messages without change (unless
   modified by split horizon).

   These two viewpoints result in identical update messages being sent.
   Metrics in the routing table differ by a constant one in the two
   descriptions. Thus, there is no difference in effect. The change
   was made because the new description makes it easier to handle
   situations where different metrics are used on directly-attached
   networks.

   Implementations that only support network costs of one need not
   change to match the new style of presentation. However, they must
   follow the description given in this document in all other ways.

In other words:

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.

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 the
internal routing tables of the machines differ in the two cases.

3

Am all the more confused now :slight_smile:

>
> 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.

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 the

Hmmm .. 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.

Thanks,
Glen

4

Glen Kent wrote:

Am all the more confused now :slight_smile:

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 the

Hmmm .. 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.