North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Receiving route with metric 0

  • From: Glen Kent
  • Date: Wed Dec 07 01:18:34 2005
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tixtqhPUhDVypX30dzHbT27bTjebd+bkJ6xfivvumJLTaUicNQDtYyFFlLYpd0DlwZmtMTTFauVhJpg5U4E+0z7mO5oPjfqbTkgKnflY4pWdeDBsZCtOC5yADDPxh8cR0/sNzx4/rT3AjHjzlUBGeNABDLtSI8JTyJOUkEvfhms=
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.

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