Simon J Mudd is rumoured to of said:
> 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?
This is the one of the main points, should a node broadcast a nodegroup that
is basically the network it sits on? The "default answer" is no, it
shouldn't.
A nodegroup is a statement saying that the sender of the nodegroup is
the best or one of the best places to attempt to reach *everyone* in that
nodegroup. It is used mainly for home ethernet LANs and also for a main
node in a radio network, such as a packet/internet gateway.
Now remember that a route that is in a node group is treated differently to
a route that is outside it. A route that is in a node group is a local
route, it has a low horizon so it should only be seen by "the locals"
ideally everyone that is included in that nodegroup. Everything else is
"portable" and should have a horizon which is the same as the nodegroup one.
So what should happen is that the main node or nodes of a network, ie the
stations that have the best chance of reaching most of the nodegroup, should
have this entry; everyone else should not.
This just leads to an interesting problem; the non-main nodes will treat
everything as outside the nodegroup (as they have none) and so give them
long "portable" horizons, this seems incorrect behavour to me.
> > 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.
We've now established that this is a "bug" in rspfd, or rather the linux
kernel network guys have pulled a rug out from underneath me; well if i
wanted stability I'd stick to cp/m ;)
What will happen in the new versions is that rspfd will check for a route in
both /proc/net/route and /proc/net/rt_local. This is kinda annoying but the
kernel people have been thinking "gated" when they did this (I can see why
it is an advantage too).
Now, we have a choice; to replace the interface route or not to replace.
I'm going for not to replace but I will ensure this is documented as it may
not be how some people with wierd configurations want to be setup.
> 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.
rspfd 0.09 will override static routes that are not these interface or local
routes. Wether or not it replaces them when the replacement is finished is
another question (see Mike's email regarding why it is an advantage).
- Craig vk2xlz
-- / /\ | | Craig Small VK2XLZ <abvjad@uidaho.edu> |==||==|=| Finger ies@dns.clanet.jp for PGP key. \ \/ | | fingerprint = AD 8D D8 63 6E BF C3 C7 47 41 B1 A2 1F 46 EC 90