[nos-bbs] Parellel Routes and the routing table

[George [ham] VerDuin]

Greetings.

I am fortunate enough to have two paths from my jnos to Internet.  The 
two paths are both RF links to two hamgates, one north and one south of 
my location via the "vhf" interface.  The southern hamgate is my normal 
link as defined in encap.txt used by all(?) hamgates.

It is my desire to enable TCP/IP traffic on both links.  As defined in 
the documentation, the <metric> parameter of the "route" statement 
allows jnos to resolve which individual link to first use from parallel 
routes in the route table.

Thus I defined two gateways using the two commands:
route add 44.0.0.0/8  vhf 44.102.132.1  2
route add 44.0.0.0/8  vhf 44.102.134.1  5
Which define two gateways with the ...132... host [metric=2] preferred 
over the ...134... host [metric=5].

In the jnos2.f software I use, rspf, rip, and rip98, are defined but not 
configured.
[Explanation:
   a) They are #defined in config.h so the execution module contains the 
processes.
   b) They are not configured with commands in autoexec.nos]
Because the remote systems are not also configured for these features, 
these conditions seem OK to me.

First problem:
After defining the parallel routes, the route table appears to not carry 
the first definition and only displays the second.  Using the IProute 
command of the BBS, only the ...134... gateway appears.  While I expect 
identical routes to not be entered, the routes above are not identical 
because both the <IP> and <metric> are different.  Did jnos post the 
routes to the route table correctly or not?

Second problem:
During operation, the router selected the wrong gateway.  The result is 
outbound traffic went to the ...134... host and the reply came from the 
...132... host.  NON-symetric routing.  Well..., it can be argued this 
is correct because the only remaining route is to ...134... host, but 
this confirms [to me] that the preferred route to ...132... has in fact 
been deleted from the table.  However all I have read says the router 
will pick a route from parallel definitions using the <metric> paramter 
as a tie-breaker.  Right or wrong?

Third problem:
Because of problem 2, there is no reason to disable the link to 
...132... host in order to complete the test of supporting two gateways 
simultaneously in order to remain in contact when the primary gatway is 
unavailable.

Yes -- further adjustments must be made to remote hosts as well, but 
this test suggests the concept of parallel routes is DOA.  So -- any 
suggestions what I might do differently?

Thanks & 73
Skip