c> No, rspfd doesn't do that. It basically only looks at the
c> routing table and because when it was written there wasn't
c> proper support for metrics, it couldn't judge on metrics.
c> The rule it follows is "do not replace any non-dynamic
c> routes already in the routing table". This will change
c> soon, now that metrics are in there, so that it looks at the
c> metric (which is what it should of done in the first place).
c> This interface metric will have to wait for more
Not only is it important to allow RSPF to override a non-dynamic route with a
dynamic one, but it is also important to restore the non-dynamic route if the
dynamic route is dropped. There are several reasons for this.
First, it is desirable to be able to establish some sort of minimally
functional although possibly inefficient route which would operate in the
absence of any proven dynamic route. In many cases, dynamic routes will come
and go with time or day or other expected occurences, and it would be
impossible to handle this is any of the routers involved in the non-dynamic
path are not themselves running RSPF.
Second, there is no way to test an RSPF-acquired route to see if it is any good
without somehow putting it in the routing table. This was the issue that
doomed the DOS implementation of RSPF. If the tested route is found to be bad,
then it would have to be removed from the routing table. At that point, the
less preferred route should be restored to operation.
-- Mike, N1BEE