> 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.
I think I agree, but ..
> 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.
I use a manually defined default route as the catch all and let rspf handle
the exception. This seems to work fairly well, though I can fairly easily
imagine scenarios where this might not work. You always have the option
of starting with no routes and just waiting for rspf to build them
for you. Isn't it true that when I am first detected as a new adjacency
my neighbours should perform a full routing broadcast for me ? If not, I
wonder if it shouldn't be, or if some functional equivalent to an
'rspf query' could not be implemented so that when I start, and find
an adjacency I can ask them to tell me what they know?
> 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.
You could always construct the 'test' datagram manually and write it rawly
to the interface. Ugly, but it would avoid routing table manipulation.
Terry
-- Linux: standard and fully integrated support for Amateur Radio protocols "Beware the Penguin".