morrison@accuvax.nwu.edu (Vance Morrison ) (04/03/89)
Hello All,
I have developed software for Turning a klunky old IBM XT into
a IP router. Below is a description of the software I wrote.
The software is available via anonymous FTP from accuvax.nwu.edu
(129.105.49.1) in the directory pub/pcroute.
We here at Northwestern have found this program to be very useful
Already we have replaced a major Hub in our network with a PCrouter
and others additions/substitutions are planned.
If you find this program useful, let me know, it helps my ego (:-).
Vance
--------------------------------------------------------------------------
PCROUTE - and IP routing program from the IBM PC
Vance Morrison
morrison@accuvax.nwu.edu
Traditionally IP routers have been fairly high performance,
expensive machines. Typically they run about $5000-$10,000 a unit.
Until now a IP router for under $5000 was just about impossible
to get. Recent developments in PC hardware, however, has made
it possible to convert a PC to an IP router for a TOTAL of $800-$1000
a unit. This price is less that the cost of many ethernet boards
and thus it now makes sense to always use dedicated router to
perform IP gatewaying functions.
---------------------------------------------------------------------
What is PCroute?
PCroute is software written for an PC/XT (or AT) that will
allow it to act as a IP router that will gateway between the following
kinds of Physical media.
Ethernet - Ethernet
Ethernet - Starlan
Starlan - Starlan
In addition to the XT, the only other hardware needed are the
networking cards, which at present run about $200-$250 a piece.
Since you can buy an XT (without an monitor) for $400, the total
cost for the hardware is $800-$900.
---------------------------------------------------------------------
What do I need to install PCroute?
1) An XT computer (does not need monitor)
2) 2 Western Digital WD8003 network cards
WD8003E Ethercard Plus
WD8003S Starcard Plus
WD8003SH Starlink Plus
---------------------------------------------------------------------
How Fast is PC route?
Some may argue that a PC simply is not fast enough to be a
good IP router. This would true if the PC had to do all the work,
but in fact, the ethernet cards do most of the work. All the
PC needs to do is determine the route, and copy the packet from
one interface to the other. By programming in assembler and
optimizing for peak efficiency, the PC is up to the task.
Actual tests indicate that that following formula is a
worst case estimate of throughput of PCroute on a 4.77Mhz XT
packet_delay = .473 + .00393 * len msec
Where 'len' is the length of the packet in bytes. Thus
PCroute has a fix per packet overhead of .473msec and takes
3.93usec/byte to transfer the packet from one network to the
other.
Thus for the largest packet size (1514) we get throughput of
packet_delay = .473 + .00393 * 1514 = 6.4 ms
throughput = len*8/packet_delay = 1.9 Mbit/sec
For the smallest packet size (64) we get a throughput of
packet_delay = .473 + .00393 * 64 = .724 ms
throughput = len*8/packet_delay = .7 Mbit/sec
If you were to buy a XT clone, (even the $400 variety) it
would undoubtedly be a 8Mhz or 10Mhz machine, so you should
expect to do 1.6 and 2.0 times better respectively with these
machines. I most strongly suggest that you get the 10Mhz variety
since they are usually only $30 more and will give you a 12%
performance boost
In addition the Ethernet boards have an on-board 6.5K packet
buffer. Thus packets that come at the PCrouter too fast for
it to process will be queued. The router will start dropping
packets after this 6.5K buffer is exhausted.
Note that since SUN NFS likes to send 8K blocks in fast spurts
this will sometimes cause the router to drop packets. I suggest
that you set this block size down to 4K if you expect a lot of
NFS traffic through the router (look for 'wsize' in man fstab).
---------------------------------------------------------------------
What PC route supports?
PCroute was designed to be as simple as possible yet perform
well as a IP router. In particular it supports
1) IP routing with Subsets (however the subnet mask
must begin with 255.255)
2) Static routing with up to 250 routes.
3) responds to ICMP echo (ping)
3) Directed broadcasts
The PCrouter also has support for more than two network interfaces,
but this requires recompilation of the code, so for now you will have
to contact me.
---------------------------------------------------------------------
What PC route DOESN'T support?
1) Dynamic routing (yet)
2) Booting off the network (BOOTP) (yet)
3) Any IP services besides routing and ICMP echo.
4) Any other Ethernet/starlan card besides Western
Digital WD8003
---------------------------------------------------------------------
Coming Soon.
1) RIP Support
2) Appletalk - Ethernet Support (like a KIP box but you can
tunnel IP packets through the Appletalk network) Here at
NU we use this so that we can get cheap, reasonably fast
network access between buildings.
3) Network Booting a la BOOTP
4) The other ICMP functions so that router conforms to RFC1009
---------------------------------------------------------------------
Hints
1) We found that the 10Mhz XT clones that Jamco and others sell
work very well. One nice feature about these units is their
BIOS. By setting the dip switches in the PC, you can tell it
that there is no Monitor. This also tells the BIOS not to
check for a keyboard either. Thus you don't need to buy either
the keyboard or the monitor. Other XT BIOS ALWAYS check for
the keyboard, and thus you have to plug it in even though you
never use it.
---------------------------------------------------------------------
Reliability
The reliability of PCroute has been EXCELLENT. We have been
using these routers for months now in three places with
absolutely no failures. If you wish to PING one for yourself
here are some PC routers on our campus
129.105.49.13
129.105.1.1
129.105.7.1
---------------------------------------------------------------------
Comments and Bug reports
I am interested in finding out what you think of PCroute and
how well it performs for you. I am also interested in hearing
about any problems you have or bugs in the documentation.
You should send your comments to
Vance Morrison <morrison@accuvax.nwu.edu>
Note that since I am not paid to support this software, I can
not guarantee that I can respond to your problem, but I will
try.
Vance Morrison
Northwestern Universityhenry@utzoo.uucp (Henry Spencer) (04/04/89)
In article <583@accuvax.nwu.edu.NWU.EDU> morrison@accuvax.nwu.edu (Vance Morrison ) writes: >I have developed software for Turning a klunky old IBM XT into >a IP router... Was there some reason not to just use the Phil Karn ("KA9Q") TCP/IP for the PC/XT/AT/...? I can't see any reason why Phil's stuff wouldn't make a perfectly good router; were you aware of its existence? -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
rpw3@amdcad.AMD.COM (Rob Warnock) (04/04/89)
In article <1989Apr4.000727.2759@utzoo.uucp> henry@utzoo.uucp writes: +--------------- | In article <583@accuvax.nwu.edu.NWU.EDU> morrison@accuvax.nwu.edu writes: | >I have developed software for Turning a klunky old IBM XT into a IP router... | Was there some reason not to just use the Phil Karn ("KA9Q") TCP/IP | for the PC/XT/AT/...? I can't see any reason why Phil's stuff wouldn't | make a perfectly good router; were you aware of its existence? +--------------- Well, for one thing, Phil's code associates an IP address with the *host*, not with each interface. (See? KA9Q isn't *perfect*... yet.) That's all right when you a gatewaying from (say) Ethernet to a SLIP link, but isn't so hot if you are trying to go Ether-to-Ether. (Someone at AMD hacked the KA9Q code to put the IP addresses with the interface, and *is* playing with it as an experimental IP router. But it's a hack, and not completely general. Best would be for one of the real KA9Q maintainers to do an "official" fix.) Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun}!redwood!rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403
les@chinet.chi.il.us (Leslie Mikesell) (04/05/89)
In article <1989Apr4.000727.2759@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > >Was there some reason not to just use the Phil Karn ("KA9Q") TCP/IP >for the PC/XT/AT/...? I can't see any reason why Phil's stuff wouldn't >make a perfectly good router; were you aware of its existence? Is there anything similar for OSI protocols? I would like to split a 1 Megabit starlan into at least 2 sub-nets but the only thing I have seen to connect them would be to put 10-1 bridges back to back (at about $4500 each). A PC with two boards sounds a lot nicer. Les Mikesell
karn@jupiter (Phil R. Karn) (04/05/89)
>Well, for one thing, Phil's code associates an IP address with the *host*, >not with each interface. (See? KA9Q isn't *perfect*... yet.) I consider that a feature, not a bug. :-) Seriously, I have always considered the Internet approach of giving addresses to interfaces rather than to hosts to have been a bad move, and my approach of "one IP address per customer" was a deliberate design decision based on how I wanted the amateur packet radio TCP/IP network to evolve. Nevertheless, you can still make my code emulate a conventional Ethernet router with two distinct addresses by merely enabling proxy ARP. You assign the router running KA9Q an address on each network. One of these addresses becomes the host address for the system; the other is entered into the ARP table with the "publish" subcommand such that it answers ARP requests for that address with the Ethernet address of the appropriate interface. For example, consider a system with two Ethernet interfaces and two IP addresses as follows: Interface A: Ethernet addr 02:60:8c:0:0:1 IP addr 1.2.3.4 Interface B: Ethernet addr 02:60:8c:0:0:2 IP addr 44.0.0.1 The autoexec.net file would contain, among other things, the following two lines: ip address [1.2.3.4] arp publish [44.0.0.1] ethernet 02:60:8c:0:0:2 This will make the system behave just as it should for purposes of routing packets. The only precaution you have to make is to use the router's "primary" IP address whenever you want to talk directly to it as a host. Of course, it is then operating as a host, not a router... Phil
zdwcv@dcatla.UUCP (Wm. C. VerSteeg) (04/05/89)
The notion of a cheap IP router based on a PC is a good one. When we start talking about implementations, some interesting ideas get thrown out. Is a proxy arp scheme good enough scheme for such a low-end router? Phil Karn says that his KA9Q can be used as a router by configuring it for proxy arp. If the intended user group is relatively sophisticated, and is confining itself to a SMALL network environment, I would say that proxy arp is sufficient. But proxy arp is not intended for large networks. There is no distributed routing algorithm, so it does not scale well at all. Proxy arp schemes would not work in the internet at large, but may be usefull in some limited applications. Carefully look at your options before you decide to use a package that was not designed to be a router as a router. Bill VerSteeg
karn@ka9q.bellcore.com (Phil Karn) (04/06/89)
>Is a proxy arp scheme good enough scheme for such a low-end router? >Phil Karn says that his KA9Q can be used as a router by configuring >it for proxy arp...[]..Proxy arp schemes would not work in the internet at >large, but may be usefull in some limited applications. You misunderstood the reason I suggested you use proxy arp. The idea was to use it only to circumvent the "one IP address per system" design inherent in my code. Proxy arp allows the package to reply properly to ARP requests for its secondary IP address. You could, of course, go further and use my proxy arp as a general routing mechanism, but in this case the objections you raise become valid. There is, however, no routing algorithm code in my package, although there is talk of adding OSPFIGP. Phil
fink@nucthy.physics.orst.edu (Paul Fink) (04/07/89)
In article <1989Apr4.000727.2759@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Was there some reason not to just use the Phil Karn ("KA9Q") TCP/IP >for the PC/XT/AT/...? I can't see any reason why Phil's stuff wouldn't >make a perfectly good router; were you aware of its existence? >-- >Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology >passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu Ah, I'm not aware of it's existence. Could you tell me wher to get it? ____________________________________________________________________________ Paul J. Fink Jr. Internet: Oregon State University fink@PHYSICS.ORST.EDU Department of Physics Phone: Corvallis, Oregon 97331 (503) 754-4631
mah@hpuviea.UUCP (Michael Haberler) (04/08/89)
We're using KA9Q as a 'super cheap' IP router for about a year now at the University of Economics at Vienna. It's an AT clone bridging a NetBIOS IBM PC Network (broadband - the early works from IBM & Sytek) and the campus ethernet. Also, it has a permanent SLIP connection to a remote PC Network running with 19200 baud. We also experimented with two KA9Q's and dialup SLIP for bridging two distant Ethernets. This worked flawless as long as traffic is low; given the average dumb PC hardware it's easy to lose interrupts when traffic is coming in from more than one side. Especially the Slip connection deteriorated badly under high load. The Ethernet card we use (3c501 - yes I know) keeps the CPU busy with interrupts disabled too long so the serial port just is overrun. The Netbios/slip route actually works better, probably due to less latency of the Netbios driver. I think that a bridge able to sustain higer traffic would need interface cards with substantial on-board buffering. The one-interrupt-per-character scheme for slip would need to be replaced with at least DMA, or better an own CPU on the card. Remember: this all is due to the !@*&^% PC hardware having lousy real-time performance. KA9Q never gave us a problem (Kudos, Phil!). Michael Haberler & Gustaf Neumann (neumann@awiwuw11.bitnet) -- Michael Haberler mah@hpuviea.uucp Hewlett-Packard Austria GmbH, ...mcvax!tuvie!hpuviea!mah Lieblgasse 1 ...hplabs!hpfcla!hpbbn!hpuviea!mah A-1220 Vienna, Austria Tel: (0043) (222) 2500 x412 (9-18 CET)
mshiels@tmsoft.uucp (Michael A. Shiels) (04/10/89)
The best ideas for helping to support a PC as a gateway machine are SMART ethernet cards and SMART serial cards. (Or us a 16550 UART which has 16 byte buffers for in/out bound data). You can write packet drivers which will talk to a smart serial card which has a custom process written to run on it which talks SLIP.
henry@utzoo.uucp (Henry Spencer) (04/12/89)
In article <1989Apr10.032326.12080@tmsoft.uucp> mshiels@tmsoft.UUCP (Michael A. Shiels) writes: >The best ideas for helping to support a PC as a gateway machine are >SMART ethernet cards and SMART serial cards. (Or us a 16550 UART which has >16 byte buffers for in/out bound data). You can write packet drivers >which will talk to a smart serial card which has a custom process written >to run on it which talks SLIP. Alternatively, you can make the software do the right thing. It's not that hard to get real-time response to device interrupts. Just because the high-level software doesn't want to be bothered by interrupts at the moment doesn't mean that low-level software can't be taking the interrupts and stashing away the incoming characters. This is a common tactic for dealing with high-speed input on dumb serial ports. Agreed that smartness is required, but it doesn't have to be in the hardware. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) (04/12/89)
No doubt, I missed all of the important messages, earlier. If so, please forgive, but.. The ONLY function that you need in the i/o cards of a cheap (and even many expensive) routers is to buffer data adequately, to avoid dropping back-to-back packets (for a fast LAN) and to avoid excessive (e.g., per-character) interrupt rates. In the PC world, especially, intelligent LAN cards have a habit of being slower than the PC, adding $500 to the cost, per network interface, and making routing quite difficult, since you end up with IP inside multiple interfaces. Putting the link-level code into the interface usually makes sense, especially with the number that now are in silicon; is that being called "intelligent"? Dave
dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) (04/13/89)
Henry Spencer asserts that interrupts need not hurt performance, if software is written properly, primarily through the use of low-level modules to do the real-time servicing, deferring the rest of the processing for upper-level software. Well, five years ago, I would have agreed. I used to deal almost exclusively with application-layer protocols. Working in the lower layers has been sobering. Interrupts kill. The raw machine processing time -- i.e., hardware instruction cost -- for interrupts is quite significant. As with most features in this world, interrupts are excellent for their intended purpose and questionable for other situations. An interrupt is very useful when you don't expect much activity and don't want the overhead of polling. On the other hand, if you DO expect heavy activity, polling is quite nice. Some folks I used to work with did a calculation of the interupt overhead for 8 terminals running at 9600 baud, using an 80186 processor (I believe at 6MHz) and discovered that they would have time left over for VERY few instructions per character. With a polling approach, they were able to sustain a data rate of about 14Kbps per terminal. (My memory is fuzzy; it may have been around 17000 baud, but you get the idea.) This was with appropriate processing for an ethernet protocol stack and per-character terminal-oriented instpection and modification. Many, occasional sources of activity warrant interrupts. A few, active sources warrant polling. Dave
karn@ka9q.bellcore.com (Phil Karn) (04/14/89)
My experiences match those of Dave Crocker almost exactly. Per-character interrupts on the IBM PC are deadly. Minimizing the number of host level interrupts per byte transferred is the single most important optimization you can make in almost any PC communications program. The problem is that existing PC hardware has virtually no support for anything else. Background polling is usually out of the question, as most applications are complex enough to make it highly inconvenient to poll often enough to avoid missing input. DMA is virtually unusable, given the limited number of channels on the original PC plus a desire to be backward compatible with that machine. This leaves interrupt-driven I/O and busy-wait loops. I recently did a driver for the PC that handles a HDLC controller connected to a 56Kbps amateur packet radio modem. (Yes, we've made some progress since the InterOp 88 and Ann Arbor IETF demos. :-)) At 142 microseconds between characters, there was no way I could make it run in interrupt driven mode, nor could I tolerate an interrupt from another source while the interface was active. I therefore designed the driver to use only one interrupt: demodulator carrier detect. The presence of carrier causes the host to enter a polling loop on the receive status register with interrupts disabled. It stays there, receiving frames, until the carrier goes away. The transmit routine is simpler: it just busy waits on the transmitter with interrupts off, sending frames as long as it has frames to send. The scheme works, but is much less than satisfactory. Whenever the channel is active, all other activity on the system freezes. Keystrokes are not echoed. Even the $#@!! time-of-day clock freezes (why computer designers have this fetish for complex interrupt-driven software clocks instead of simple read-only hardware binary counters driven by oscillators, I'll never understand). The irony of this situation is that it wouldn't be so bad if the modem were faster; the PC would spend less time sending each packet. There is enough real time, even on a 4.77 MHz PC, to spin around the wait loop on the device a few times for each character that is actually sent or received. But the inter-character time is not long enough to go off and do any other useful work, so it goes to waste. It's sort of like making a cross-country airline trip with several hour-long connections. They're long enough to become a significant fraction of the total trip, but each one is too short to do anything but sit around each terminal, waiting. Just having lots of FIFO buffering on each I/O card would be an enormous help. It would be really nice to use the 80286 INS (block input) instruction to slurp several kilobytes out of a FIFO that had been loaded by the line controller without direct processor intervention. Considering the speed of this instruction, the total bus overhead would actually be less than DMA since you can avoid the bus arbitration that has to go on for each DMA transfer. Better yet is enough FIFO buffering plus hardware smarts to handle several packets without host intervention. Except for the newer Ethernet controllers the slave I/O CPU seems to be the only way to do this. But this is not to say that the link or higher protocols should be executed on the controller -- its job should be strictly limited to buffering for the purpose of alleviating the host processor's real-time constraints. Right now, my "slave I/O CPU" is a dedicated PC/XT with an Ethernet interface on one side and the packet radio interface on the other. It sits in the corner, gatewaying packets between the local Ethernet and the radio channel (the real Ether). Most people need a cheaper solution, so a friend (Mike Chepponis, K3MC) is designing a slave I/O processor for the PC that contains a V40 CPU, several hundred K of RAM and one or more 8530 HDLC chips. As an additional aside, polling is the standard technique used in electronic telephone switches. Imagine an interrupt-driven switch when all the phones come off-hook simultaneously... Phil
henry@utzoo.uucp (Henry Spencer) (04/15/89)
In article <8904140206.AA10084@ucbvax.Berkeley.EDU> dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) writes: >Henry Spencer asserts that interrupts need not hurt performance, if software >is written properly, primarily through the use of low-level modules to do >the real-time servicing, deferring the rest of the processing for upper-level >software... Well, that's the scheme I outlined, but the conclusion is overstated. I didn't say that interrupts were free, I said that they could be made a good deal less expensive than people tend to think. Obviously there is always a point where the cost gets too high. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (04/15/89)
In article <15321@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: >As an additional aside, polling is the standard technique used in electronic >telephone switches. Imagine an interrupt-driven switch when all the phones >come off-hook simultaneously... At least one terminal switch, built by otherwise very professional people, did in fact collapse when presented with a large number of simultaneous connection requests. I shouldn't give names, since this may well have been fixed by now -- it wasn't recent. Normally it's very uncommon for lots of people to hit BREAK simultaneously, but when you're talking about a military school with a whole class of cadets being marched into the terminal room, sitting down, and then hitting BREAK en masse, it can happen... -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
mah@hpuviea.UUCP (Michael Haberler) (04/15/89)
From article <8904140206.AA10084@ucbvax.Berkeley.EDU>, by dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker): > > Many, occasional sources of activity warrant interrupts. > A few, active sources warrant polling. > This is, by the way, what the hp-ux tty driver on the 300 series does: if traffic is low, it works on a interrupt-per-character basis; if traffic exceeds some high-water mark, it switches to polled operation. -michael -- Michael Haberler mah@hpuviea.uucp Hewlett-Packard Austria GmbH, ...mcvax!tuvie!hpuviea!mah Lieblgasse 1 ...hplabs!hpbbn!hpuviea!mah A-1220 Vienna, Austria Tel: (0043) (222) 2500 x412 (9-18 CET)
mshiels@tmsoft.uucp (Michael A. Shiels) (04/15/89)
Low level buffering is great but it is still a performance pig. If you can get one interrupt per packet then you can support more interfaces in one machine. I was thinking of a couple of SLIP lines a ethernet, token ring and makybe an arcnet. This thing becomes interrupt intensive unless you can get rid of some of the serial interrupts. It's really bad if your running 9600/19200.
henry@utzoo.uucp (Henry Spencer) (04/20/89)
In article <15321@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: >As an additional aside, polling is the standard technique used in electronic >telephone switches. Imagine an interrupt-driven switch when all the phones >come off-hook simultaneously... Little birds tell me, actually, that it is not unheard-of for some electronic phone switches to misbehave badly in this situation... -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
karn@jupiter (Phil R. Karn) (04/25/89)
>>As an additional aside, polling is the standard technique used in electronic >>telephone switches. Imagine an interrupt-driven switch when all the phones >>come off-hook simultaneously... > >Little birds tell me, actually, that it is not unheard-of for some electronic >phone switches to misbehave badly in this situation... Yes, things do slow down -- BUT -- if you wait long enough you will eventually get a dial tone. An excellent test of this occurred back in 1980 during the Carter/Reagan debates, when 900 DIAL-IT service was being trialed on a nationwide basis for the first time. AT&T had carefully designed the service to avoid tying up long distance trunk capacity (by limiting the number of 900 calls to a small fraction of each trunk group) but they had not anticipated the extraordinary level of interest that had half the homes in the US lifting their receivers simultaneously. I measured dial tone delays of 2-3 minutes on my local ESS in Illinois. When polled systems get overloaded they do inded slow down, but they do not collapse. Phil
henry@utzoo.uucp (Henry Spencer) (04/27/89)
In article <15577@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes: >>>As an additional aside, polling is the standard technique used in electronic >>>telephone switches. Imagine an interrupt-driven switch when all the phones >>>come off-hook simultaneously... >> >>Little birds tell me, actually, that it is not unheard-of for some electronic >>phone switches to misbehave badly in this situation... > >Yes, things do slow down -- BUT -- if you wait long enough you will >eventually get a dial tone... Context implied that the little birds' phrase "misbehave badly" did not mean just "respond slowly". The implication was that not all phone switches are always polled, or at least the polling isn't always done right. Just because it's the standard technique doesn't mean everybody is standard... -- Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology 2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
morrison@accuvax.nwu.edu (Vance Morrison ) (07/04/89)
Call for Beta Testers from PCroute 2.0
Hello All,
I have written debugged, and alpha-tested the next version of the
PCrouter software. For those of you who don't know what PCroute is,
it is a piece of software can turn an old XT or AT into an IP router.
The best part of all of this is due to the low cost of and XT clone and
ethernet cards, you can make an IP router for under $800. Not bad since
A Cisco router doing the same thing cost $8000. (granted, Cisco is
a higher performance machine, but I think you will be pleasantly supprised
by the throughput of this software, we do a fair amount of NFS and FTP
and really don't notice the difference).
I have been testing this code for about 3 weeks now in 9 PCrouters here
at Northwestern and they seem to be operating properly. But before I
schedule an 'official' release (3 - 4 Weeks), I would like to get some
other people trying PCroute in situation we simply don't have here at
Northwestern.
The software itself as well as the source code can be found on
accuvax.nwu.edu (129.105.49.1) in pub/pcroute. The source code is
compressed, and both the source and the software has been 'tarred'.
Please don't go modifying the code until the official release comes out
in several weeks, then you can make LOCAL modifications to your hearts
content. I Reserve the right to be the SOLE person to make modifications
to PCroute that span organizational boundaries. My motive is simple,
I want there to be only a single varient of PCroute. If you have a good
idea you want incorporated let me know and I will probably put it in.
People that aren't on the internet, be patient, in a couple of weeks I
will ask UUNET and other UUCP archives to keep a copy, then you can get
it yourself.
Here are some of the highlights of Version 2.0 (beta)
PCroute Version 2.0
PCroute, the software that can convert a PC into a IP router for
about $500, is now in its second major Version. As with version 1
PCroute supports
1) Western Digital WD8003 Ethernet and Starlan boards.
2) Static IP routing (up to 250 routes).
3) IP subneting
4) ICMP Ping
But in addition Version 2.0 also supports
1) Up to 6 networks interfaces
2) Localtalk interfaces (MacTCP compatable)
3) SLIP (coming soon)
4) ICMP TTL, Redirect, Unreachable
5) Fragmentation where necessary
6) RIP dynamic routing protocol
7) Error loging using BSD syslog
8) PROXY ARP (if desired)
9) Bootp forwarding
Vance
morrison@accuvax.nwu.edu