swb@batcomputer.tn.cornell.edu (Scott Brim) (12/01/86)
Thanks to all the mail about terminal servers recently, I feel educated
about using terminal servers on ethernets. How about the other
direction though ("milking machines")? I'm talking about a situation
where you TELNET to this box and it produces asynch out the backend to
connect to hosts that don't support TCP/IP, or support it in a limited
way. Nice user functions aren't so important in this mode, but
reliability, throughput, and routing functionality become critical.
Once again the only contenders I know of are Bridge, Cisco, and
Encore.
Is anyone using terminal servers in this mode?
What's REAL throughput like, these days, coming **from** the "terminal"
(which in this case is the host)?? I believe these boxes have been
engineered for high throughput **to** the terminal (which in my case is
the host). How do they do if you spew characters at them from the
RS232 ports? Do they crash? Stagger? Drop things on the floor? Sail
smoothly through it?
Does Bridge understand UDP RIP yet? (I suspect Cisco still only uses
its own proprietary routing protocol.)
On any of these boxes, is there any problem with **completely** turning
off things like welcoming banners, flow control, etc.?
Thanks ... Scott
---------------------------------------------------------------------------
Scott W. Brim swb@devvax.tn.cornell.edu
Cornell University Theory Center {decvax,ihnp4}!cornell!swb
265 Olin Hall bitnet: swb@crnlcs
Ithaca, NY 14853 607-255-9392phil@amdcad.UUCP (Phil Ngai) (12/02/86)
In article <1612@batcomputer.tn.cornell.edu> swb@batcomputer.UUCP (Scott Brim) writes: > >Does Bridge understand UDP RIP yet? (I suspect Cisco still only uses >its own proprietary routing protocol.) None of the Bridge boxes we have, which consist of GS/3 internet routers and CS/100 terminal servers, understand Berkeley's routed protocol. I think this is what you mean by UDP RIP. I don't know that my terminology is more accurate than yours but vendors seem to understand me better when I say Berkeley routed rather than RIP. Bridge Comm's lack of routed is a problem in several ways. Because they don't send routed packets, managing routing tables for our 100 hosts is very inconvenient. We have implemented a workaround for this by using a host which allows forging IP source addresses. We impersonate the GS/3 internet routers and advertise the networks available through them. This has been running for only a few days but seems like it will suffice for us. It was surprisingly easy. A shell script was used to assemble the packets and then send them to a raw Ethernet device. This system allows us to keep 100 hosts run by many different system managers up to date on routing information by changing just one file on one host. This system is not perfect. There would be benefit from the GS/3s producing the routed packets themselves. For example, if one gateway went down and an alternative route was available, hosts would automatically use the alternative. A worse problem is that the GS/3s don't listen to routed packets. We have started installing Apollo domain rings with Ethernet gateways. These gateways broadcast routed packets and if the GS/3 heard them, they would route packets destined for a node on a ring to the appropriate gateway. Instead, we have to get on a CS/100, use a nonstandard protocol and modify the GS/3. Every time we install a new Apollo ring, we have to update all eight of our GS/3s. Most times we have to add two entries for every new Apollo ring because of our redundant topology. Every time we install a new version of GS/3 software, we have to type in the entire routing table to each GS/3. It gets very tiresome. I wish I could store the routing tables as files on my VAX Unix machine and download them. I could probably figure out how by looking at the packets with my LANalyzer but haven't had time yet. -- If you had everything, where would you put it? Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
hedrick@topaz.RUTGERS.EDU (Charles Hedrick) (12/02/86)
> Does Bridge understand UDP RIP yet? (I suspect Cisco still only uses > its own proprietary routing protocol.) Actually, at this instant Cisco will handle either EGP or the PUP GWINFO (the PUP version of RIP). They are being very careful about testing their own protocol before turning it on in customer copies. As I understand it, they do not regard it as proprietary, and have considered issuing an RFC. (One might well describe routed as proprietary, since it is not described by an RFC. You have to figure it out from looking at source files. Under your license agreement, you can't divulge the information that you have obtained, though I suspect that this is being a bit more picky than they had in mind.) There are several problems with routed that make it unlikely that it will take over as a routing protocol. One is that in large networks, the algorithms behind RIP can lead to instability. It's unclear to me how many real networks have configurations that would lead to problems, but Cisco and similar companies would like their boxes to be usable to build networks on the scale of the Arpanet. (NSFnet and a number of regional networks are creating a market for routers that can handle big networks.) A more practical problem is that routed is largely a Unix-only protocol. If all your machines and gateways are BSD, fine. But we find it more practical to use other techniques to distribute routing. The most common ways to distribute routing information are routing redirects and proxy ARP. To use routing redirects, you set up a default gateway for each host. (It is common to have a convention that host number 1 on each subnet is a gateway.) If that gateway turns out not to be on the best route, it will issue an ICMP redirect pointing you to the better route. To use proxy ARP, you set things up so that your host issues an ARP request for every destination. The appropriate gateway responds to the ARP with its own Ethernet address. Routing redirects are probably the most common. Their use is described in the standards. Every TCP/IP implementation that I know of can use them. Proxy ARP is used primarily to handle hosts that do not understand subnetting on a subnetted network. However if you prefer not to wire in knowledge of a gateway to each host, you can also use this as your primary method for distributing routing. This method will always work for handling the subnet problem, but many host can't be told to ARP destinations on other networks. Bridge terminal servers are set up to use routing redirects. You can set a default gateway, and they obey ICMP redirects. I don't know anything about Bridge gateways, but I'd be real surprised if they didn't issue redirects when appropriate. Cisco terminal servers and gateways can use either technique. You can set a default gateway, and they will obey ICMP redirects. The terminal servers (but not gateways, I think) will also issue ARP's when they can't find any other way to get to a destination, even if it is on a different network. The gateways will issue redirects when appropriate, and will also handle proxy ARP. As far as I know, Berkeley Unix will not issue redirects when used as a gateway, but it will obey them when used as a host. It will also not respond to ARP requests for other networks when used as a gateway, but can be made to issue them when used as a host. In my opinion, this make Unix perfectly well-behaved as a host, but rules it out for use as a gateway, except in a network where you know you will never have any hosts other than Unix machines. (These comments are certainly true for 4.2. It is always possible that 4.3 has added code to issue redirects, though I haven't seen any sign of it in the announcements and other discussions on the net. I know that it hasn't added code to do proxy ARP, even though a number of sites have had to add it in order to bring up subnets.) As to your original question about milking machine performance: Bridge advertises their units for this purpose. We have used it in a small- scale way to front a PDP-11 and an IBM machine. It works. However the CS-100's, at least, are very short on memory. We have run into problems with machines when certain combinations of things are done with them. E.g. when the same machine is used as a milking machine and to drive a printer at high speed. Bridge has been working on these problems, and may have fixed it by now. Performance on connections when they are used this way is fine. You can certainly disable flow control. I've never seen any problem with welcoming banners, etc., but can't swear to the exact configurations we use. We've never measured throughput, but terminals look like they are running at full speed. Cisco does not advertise their equipment for use this way, but both they and we think they would work, at least up to some number of ports. There are things about the Bridge design that might make them slightly better, except for the dratted memory shortage.
scarter@caip.RUTGERS.EDU (Stephen M. Carter) (12/02/86)
In article <1612@batcomputer.tn.cornell.edu> swb@batcomputer.UUCP (Scott Brim) writes: >Once again the only contenders I know of are Bridge, Cisco, and >Encore. >Is anyone using terminal servers in this mode? > We have a couple CS/100s acting as milking machines to some Prime 9950s and a Comten. We are about to replace the CS/100 with a cisco box for the Primes. In theory, the Bridge family has excellent parameters for RS232 ports in milking machine style: - when a port is set "device=host", it will turn off the welcome message and not allow the connected device to start a session (this is handy of you ever seen an instance where two machines start a tug-of-war with banner messages) - supports hardware handshaking in a number of ways, ie you should have no problems with using full handshaking to the extent that the user can't tell the difference between this and a real telnet connection - allows sockets to answer to rlogin (does not implement rlogin, bit will connect via telnet). Also, you can sysgen a port to answer any socket you wish, ie if you wanted to write a SMTP server to reside on a rs232 port. - setting an IP address to either a single port or a defined group of ports - the usual large selection of speed, parity, stop bits, flow control, and all the rest (see C. Hedrick's article). We are replacing the cs/100 with a cisco because there are problems. The worst design flaw of the cs/100 is the tiny buffers. In cases where we have all 14 ports of a box milking a host, we have cases where a connection will break if the user attempts to type a large file without paging. (hardware flow control will not help and we can't use ^S^Q because of emacs). We see this most often on connections from a Unix machine to a port and not so much from another Bridge port on the network. We believe that the Unix machines ask for a much larger window than another Bridge. We have made repeated requests to Bridge to help us out with no success. The marketing folks stand firm on one release per product and refuse to have a version that is tuned for milking machines, or make use use of additional memory on the newer versions of the hardware. From what I have noticed, this should only be a problem when you have a cs/100 and a number of ports on that unit milking a host. I assume that things would be better on a cs/200. Don't know about a cs/1. We have two ports on one box connected to a 11/44 where the remainder of the ports are office terminals with no reported problems. Newer versions of the software and firmware fix many oddball bugs that show in this mode. Get the lastest versions. I'll post a message about our results of using a cisco box as soon as we hook it up in about week or so. Let me know it you want more info. -Stephen Carter uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!scarter arpa: SCARTER@RUTGERS or SCARTER@RED.RUTGERS.EDU
medin@nike.uucp (Milo S. Medin) (12/03/86)
Bridge doesn't support RIP, but Encore Annex's do, and do it quite nicely. We have a couple here and it really simplifies things when new nets come up. You don't have to do anything... They have lots of nice features, but I suspect this subject has been beaten to death. They also do reverse terminal serving. Bridge doesn't do RIP, and last I heard, even their gateways didn't do ICMP. Which means default routes that depend on redirects to work don't. Maybe this has changed; anybody here have newer information? Milo Medin medin@orion.arpa ...!ames!medin PS Usual disclaimers about this not being the opinion of the US Gov't or the contractor I work for, etc...
narten@arthur.cs.purdue.edu (Thomas Narten) (12/04/86)
>In <7432@topaz.RUTGERS.EDU>, hedrick@topaz.RUTGERS.EDU (Charles Hedrick) writes: >There are several problems with routed that make it unlikely that it >will take over as a routing protocol. One is that in large networks, >the algorithms behind RIP can lead to instability. It's unclear to me >how many real networks have configurations that would lead to >problems, but Cisco and similar companies would like their boxes to be >usable to build networks on the scale of the Arpanet. (NSFnet and a >number of regional networks are creating a market for routers that can >handle big networks.) A more practical problem is that routed is >largely a Unix-only protocol. If all your machines and gateways are >BSD, fine. But we find it more practical to use other techniques to >distribute routing. Could you please elaborate on what "algorithms...lead to instability"? Is this a flaw in the protocol, or would other algorithms also run into similar problems? The fact that routed is found mostly in BSD systems is no reason not to use it. I can turn the argument around and say that any other routing algorithm available from other vendors is impractical cause Unix machines don't run them. >The most common ways to distribute routing information are routing >redirects and proxy ARP. To use routing redirects, you set up a >default gateway for each host. (It is common to have a convention >that host number 1 on each subnet is a gateway.) If that gateway >turns out not to be on the best route, it will issue an ICMP redirect >pointing you to the better route. To use proxy ARP, you set things up >so that your host issues an ARP request for every destination. The >appropriate gateway responds to the ARP with its own Ethernet address. >Routing redirects are probably the most common. Their use is >described in the standards. Every TCP/IP implementation that I know >of can use them. Proxy ARP is used primarily to handle hosts that do >not understand subnetting on a subnetted network. However if you >prefer not to wire in knowledge of a gateway to each host, you can >also use this as your primary method for distributing routing. This >method will always work for handling the subnet problem, but many >host can't be told to ARP destinations on other networks. I would have to dispute what you call as "most common". Routing redirects and proxy ARPs are one way to manage routes, but all is not rosey. With redirects, one starts with one gateway finds new and better routes cause the gateway you are currently using tells you of a more direct path. If that new route should go away, however, you have no way of finding out cause you would need a redirect from the gateway that just went away. You may in fact have another gateway that could still be used. RIP would detect gateways that go away and either remove the route or find another gateway. In summary, Redirects can be used to fix up incorrect entries, not to manage routing tables. It certainly has as many and probably more problems than RIP. Using "proxy ARP" may work some of the time, but it is not robust. ARP entries are cached for about 20 minutes of non reference, hence there is no guarantee that a route that no longer works will ever time out. If you have only one gateway, that isn't a problem. Lots of sites have many. Besides, using ARP/redirects for routing just pushes the problem of needing a routing algorithm to the gateways. They cannot use this trick themselves. The gateways will have to use some sort of algorithm (such as RIP) to get routes straight between them. Again, having just one gateway simplyfies things. The convention of host 1 being a gateway is a local assumption. We don't follow that convention, and I would be surprised if many others do. Besides, lots of sites have more than 1 gateway per net anyway. What do you do then? >As far as I know, Berkeley Unix will not issue redirects when used as >a gateway, but it will obey them when used as a host. It will also >not respond to ARP requests for other networks when used as a gateway, >but can be made to issue them when used as a host. In my opinion, >this make Unix perfectly well-behaved as a host, but rules it out for >use as a gateway, except in a network where you know you will never >have any hosts other than Unix machines. (These comments are >certainly true for 4.2. It is always possible that 4.3 has added code >to issue redirects, though I haven't seen any sign of it in the >announcements and other discussions on the net. I know that it hasn't >added code to do proxy ARP, even though a number of sites have had to >add it in order to bring up subnets.) 4.3 BSD will issue and accept redirects if properly configured. Properly configured means that it must have 2 or more "real" interfaces (loopback doesn't count), otherwise it thinks it is a host. This is a wise decision, as hosts aren't gateways, and shouldn't act as such. 4.3 will change routing entries that are updated via redirects. It will, however, only do so if the redirect came from the same gateway it is currently routing packets addressed to the destination given in the redirect to. This prevents it from installing redirects that come from a random host. -- Thomas Narten narten@purdue.EDU or {ucbvax, ihnp4, allegra}!purdue!narten
lepreau@utah-cs.UUCP (Jay Lepreau) (12/04/86)
From "Changes in the kernel in 4.3 BSD": When a packet is forwarded using the same interface on which it arrived, if the source host is on the directly-attached network, an ICMP redirect is sent to the source. If the route used for forwarding was a route to a host or a route to a subnet, a host redirect is used, otherwise a network redirect is sent. The generation of redirects may be disabled by a configuration option, IPSENDREDIRECTS=0. As Chuck notes, the "proxy arp" code is widely available and easy to install; one place is from ut-sally in pub/subarp or subarp.shar.
gds@sri-spam.istc.sri.com (The lost Bostonian) (12/06/86)
In article <675@arthur.cs.purdue.edu>, narten@arthur.cs.purdue.edu (Thomas Narten) writes: > I would have to dispute what you call as "most common". Routing redirects > and proxy ARPs are one way to manage routes, but all is not rosey. With > redirects, one starts with one gateway finds new and better routes cause the > gateway you are currently using tells you of a more direct path. If that new > route should go away, however, you have no way of finding out cause you > would need a redirect from the gateway that just went away. You may in fact > have another gateway that could still be used. RIP would detect gateways > that go away and either remove the route or find another gateway. In > summary, Redirects can be used to fix up incorrect entries, not to manage > routing tables. It certainly has as many and probably more problems than > RIP. The BBN 4.2 TCP/IP implementation pings the gateway listed in the routing tables periodically. When the gateway is marked "down" because it does not answer its ping in m out of n tries (I forget the exact numbers) the connection is retried using the "default" gateway. This will cause another round of redirects to be sent, until the original route is good, or another path through the internet is found. When a gateway crashes which is the only gateway onto a network, communications with that network are cut off until the gateway comes back up, but a flurry of redirects is sent nevertheless. There is a problem with too much pinging contributing to network congestion, but this can be alleviated by implementing pinging with exponential backoff. 4.3 BSD TCP/IP does not do any pinging. > 4.3 BSD will issue and accept redirects if properly configured. Properly > configured means that it must have 2 or more "real" interfaces (loopback > doesn't count), otherwise it thinks it is a host. This is a wise decision, > as hosts aren't gateways, and shouldn't act as such. 4.3 will change routing > entries that are updated via redirects. It will, however, only do so if the > redirect came from the same gateway it is currently routing packets > addressed to the destination given in the redirect to. This prevents it from > installing redirects that come from a random host. 4.2 BBN TCP/IP would not enter a new route from a redirect into its tables unless it came from a gateway which was already in its tables. --gregbo
dcrocker@ubvax.UUCP (Dave Crocker) (12/08/86)
In article <1612@batcomputer.tn.cornell.edu> swb@batcomputer.UUCP (Scott Brim) writes: >How about the other >direction though ("milking machines")? I'm talking about a situation >where you TELNET to this box and it produces asynch out the backend to >connect to hosts that don't support TCP/IP, or support it in a limited >way. Ungermann-Bass has support for TCP/IP Telnet access to hosts, in the configuration that you describe. Sustained, full-speed transfers work fine. Line speeds up to 19.2Kbps are supported. Dave