Links to TheNET / NET-ROM partners
FlexNet V3 makes it possible to link Netrom neighbors and to forward
these interlinks, provided they are working. For the following explanations, we assume
that our FlexNet node DB0FLX has an interlink to the NETROM node DB0NR. The Netrom node
consists of several TNC’s with different SSID’s. The user port usually has the
SSID -0. DB0FLX is on DB0NR-4 for example. Obviously, we should add DB0NR-4 to the link
table of DB0FLX as it was done in V2. However, this has disadvantages:
• The Netrom node perhaps has other FlexNet neighbors. If they
forward their DB0NR-x information, too, DB0NR appears more than once in the FlexNet
D-tables. This makes the D-tables very uncomprehensive.
• When a user wishes to connect DB0NR, he does not know which path
to DB0NR the best is, since FlexNet may route the different DB0NR-x a different way.
However, it is possible to solve the problem with proper entries in the link list. The
idea is, that for the network it is enough to know that DB0NR exists. How the single
TNC’s of DB0NR are reached is only of interest for the neighbors of DB0NR. The link
entry of DB0FLX has to be as follows (provided that DB0NR is on port 5)
L 5 DB0NR-4 - * the "-" means that the link is checked, but not forwarded to
the network
L DB0NR-4 DB0NR * this is the trick: The link to the user port DB0NR-0 is checked and
forwarded to the network as ssid-range 0-15
FlexNet now knows a way to DB0NR, but only DB0FLX knows that it has to
go to DB0NR-4 directly, and to the other SSID’s of DB0NR via DB0NR. In the D-lists
only a DB0NR (0-15) appears. The user port DB0NR-0 is directly reachable. If there would
exist a Convers-TNC DB0NR-8, it could be directly reached, too. The thing becomes even
more Wizzardly when DB0NR has a second FlexNet neighbor. We assume DB0ZZZ is reachable via
DB0NR-2. We add the following two link entries:
L DB0NR-4 DB0NR-2 $ * indirect link. Not tested, not forwarded, but displayed in the
link list
L DB0NR-2 DB0ZZZ * Link to FlexNet via DB0NR. Will be tested and used by FlexNet.
That has been the good news, and now the bad news:
The D-command shows a route to DB0NR-14 now, even if it does not exist.
The Link-command is only capable of linking single (-0 -1 -2) or all (0-15) SSID’s...
The Netrom linkports have to turn on L2 digipeating. When accessing
DB0NR-0, this should cause no trouble, since the diode matrix works without collisions.
Furthermore, the link as set up via this trick suffers from the not
available hop-to-hop-acknowledgement. This compromise is acceptable when looking at the
advantages of the network: When the links are working 100%, it has no disadvantages,
hop-to-hop-acknowledgement is not necessary if there are no RETRIES. If the link is bad,
FlexNet uses a better route, if available. When the Netrom sysop is stupid and still wants
L2 digipeat turned off on the interlinks, the link still should be set up as described.
Then the NETROM node is not forwarded and the users have to find their way themselves. As
soon as the digipeating is turned on, everything will work OK again.
