[nos-bbs] Parellel Routes and the routing table

[Jay Nugent]

Greetings Skip,

On Sun, 28 Feb 2010, George [ham] VerDuin wrote:

> 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?


   The AMPRnet (Hamgates) only "know" how to route to you at your 'HOME'
Hamgate.  To route through an alternate Hamgate, your HOME Hamgate will
need to have a /32 route for you sending packets destined for you, to the
alternate Hamgate.  That alternate Hamgate will then have to have a /32
route sending packets destined for you out its RF port to you (since both
these Hamgates are on the *same* frequency).  And YOU will have to point 
your outgoing 44/8 routes toward the Alternate Hamgate.

   Your choices really are:  Pick Hamgate "A" -or- Pick Hamgate "B".  But
there really is no way for these two Hamgates to decide which is better
suited to passing packets to you.  And Hamgate.Ottawa (44.102.132.1) *IS*
the one you should concentrate on since you "BELONG" to his subnet.  If 
it's an RF path issue --- get a beam!

   Now if you wish to use the 44.102.0.x subnet, we place MOBILE stations
in that group.  And we used to use the RSPF protocol to route to them.  
Currently *NONE* of the Michigan Hamgates have RSPF configured and I
simply have no time to research how this is done.  If you would like to do
the research, provide a config that works for everybody, and doesn't break
anything, then perhaps we could deploy this state wide :)

   Investigate using the RSPF protocol (Radio Shortest Path First).  You 
will have to do some Google searches to find out how this works and how it 
is configured.  Best of luck!

      --- Jay  WB8TKL

Train how you will Operate, and you will Operate how you were Trained.
+------------------------------------------------------------------------+
| Jay Nugent   jjn at nuge.com    (734)484-5105    (734)649-0850/Cell       |
|   Nugent Telecommunications  [www.nuge.com]                            |
|   Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller |
| ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring |
| Web-Pegasus    [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts|
+------------------------------------------------------------------------+
  5:01pm  up 80 days, 16:56,  3 users,  load average: 0.00, 0.00, 0.00