> 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.
This will hopefully be done with rspfd 0.09.
> 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.
This is a good point and one I have not considered before, probably because
you couldn't remove a static route before.
> 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.
This is already done in the current versions (well it is supposed to
anyway). The method of pinging a potiential neighbor is to save route, add
new route, ping, restore old route.
- Craig
-- / /\ | | Craig Small VK2XLZ <yubf.kbyzzje@bucknell.edu> |==||==|=| Finger yllv.bfmb@specastro.com for PGP key. \ \/ | | fingerprint = AD 8D D8 63 6E BF C3 C7 47 41 B1 A2 1F 46 EC 90