[comp.protocols.tcp-ip.ibmpc] KA9Q, forwarding between ethernets

rjberke@skvax1.csc.ti.com (RICHARD BERKE -- COMMUNICATIONS ENGINEERING) (10/19/89)

I've been exploring KA9Q (Sept 29, 1989) for PC, and have noticed a curious 
command listed: forward.  

Does anyone have information on its use/syntax?   The documentation (May 89)
BRIEFLY treats an apparently now-defunct command: mulport.  Forward command 
is not referenced in the documentation.  Mulport is not a valid command, per 
my copy.

It feels as if there is a capability for a PC with two interfaces, perhaps 
both ethernet boards, to be used as a 'poor man's' IP interconnect between 
two networks.

I have a requirement for interconnection of ethernets.  The co-requirements 
of low cost, data transparency, yet access control are so far tough to meet.
Local bridges that cost little are dumb devices.  They also don't have 
resident configuration files adequate to recover the filtering after a 
reset.  Routers appear to be designed for the technical purpose I have, but 
also appear to start at around $8,000 and only go up from there.

Can anyone refer me to options for KA9Q, or other products, with which a PC 
can be configured to serve as I've described?

Thanks,

Richard Berke

Texas Instruments
Plano, TX

rjberke@skvax1.csc.ti.com

karn@ka9q.bellcore.com (Phil Karn) (10/23/89)

In article <8910181933.AA14935@ti.com> rjberke@skvax1.csc.ti.com (RICHARD BERKE -- COMMUNICATIONS ENGINEERING) writes:
>I've been exploring KA9Q (Sept 29, 1989) for PC, and have noticed a curious 
>command listed: forward.  
>
>Does anyone have information on its use/syntax?

The "forward" command is a hack that I added to support receive-only
interfaces. I added it a year ago to support an experimental packet radio
store-and-forward repeater that listened on a set of frequencies and
transmitted on a common output channel, distinct from the inputs. It wasn't
a pretty solution, but I couldn't think of a better way to do what I wanted
to do. (IP datagram routing wasn't the problem; just setting up the routing
table took care of this. The problem was with link level packets, such as
ARP requests and AX.25 link level control frames.  I needed a way to deflect
responses to such packets out a different physical interface than the one
they arrived on. Hence the forward command.)

This command is of little use in regular Internet-style operation. The code
will already work as an IP router, although until just yesterday it took
some playing with proxy ARP to make it all work right. I just added
IP-address-per-interface support, so all this will become much easier,
and more like a regular router.

BTW, the code has supported RIP for about a month, so you can indeed use the
package as an IP router. It will definitely not outperform a Cisco, though.
The code is written for flexibility and portability, not speed.

Phil