> > I guess I'll have to wait and see what Craig says, and check whether the
> > problem is "his", ours (bad configuration), or a wider kernel problem
> > (which I would think is unlikely).
>
> I'd guess it's a combination of the first two.
>
> 1> The other rspfd shouldn't be advertising the network route in the first
> place. If he is a linux machine check whether he has a nodegroup entry
> for that interface, he probably shouldn't.
The other machine WAS advertising this nodegroup. It's running jnos and
rspf 2.1. This is where I had a small disagreement with Julian, ea4abb,
because I stated that ea4rct shouldn't be broadcasting a route to the network
on the network. He rightly pointed out that this information is supurflous
and thus it shouldn't matter whether it is broadcast or not, as it will
always be better to go through the interface "direct" to a host, than
through another host on the network to the host.
However here I wasn't sure whether rspf SHOULDN'T broadcast this route,
OUGHTN'T broadcast this route, or whether it didn't matter. You seem
more inclined toward the SHOULDN'T category?
> 2> your rspfd probably shouldn't be replacing the existing one with the
> new one.
This is what is happening without adding an explicit route to the network
via the interface.
The comment you make in your other message about removing static existent
routes I think is interesting, as it would potentially allow us to set up
some static maps, which rspf could override, if it knew better.
-- regards,Simon J Mudd, Madrid SPAIN +34-1-559 2854 e-mail: cagqddmr.vwysaxi@hisoregon.com [short messages - from radio hams] ----> hzc.bykxc@sychip.com