Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!uflorida!ukma!rutgers!aramis.rutgers.edu!geneva.rutgers.edu!hedrick From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.dcom.lans Subject: Re: x.25 server for tcp/ip Message-ID: Date: 7 Feb 89 13:52:06 GMT References: <333@pbseps.UUCP> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 46 You ask about X.25 to TCP/IP services. We are currently doing an experiment with cisco equipment to provide just the sort of service you asked for. I don't think it is a product yet, but you might call them and ask about availability. (I can give you a specific contact if you have trouble getting information). We have a 56K line to NJ Bell's public X.25 network. People use NJ Bell pads to connect to us. This gets them to the cisco gateway. It gives them a normal cisco terminal server prompt. From there they can telnet or rlogin to any system on our network. There are also plans to have them make the connection transparently, based on a mapping from X.121 addresses to IP addresses, so users don't have to go through the extra step of talking to the cisco command level. However we have so many hosts on our network that I don't want to have to keep NJ Bell up to date on all of our addresses. Thus we have no plans to use such a feature even if it exists. cisco has the ability to forward IP packets to another gateway over X.25 connections. This is used for DDN X.25, as well as for X.25 based private networks, so this is a real product. (They can also handle DECnet and probably other things over X.25 links.) They is also an experiment at another university with outgoing TCP/IP to pad service. That is, you make a telnet connection to their box and it turns it into an outgoing X.25 call. Again, I believe that it is an experiment and not a product. At this point the pad to telnet code seems to be solid. However it's hard to be sure. We get lots of unexplained wierd events. As far as I can tell, they are all the fault of the X.25 network, but it's hard to be sure. They are all associated with some clear or other thing that NJ Bell sends us. They have reason codes suggesting that something is wrong on the network (though it's hard to be sure how much to trust reason codes with an X.25 network that uses "out of order" as the reason code in a normal close). It sounded to us like a great idea to use a public X.25 network for communications around the state. (We have a group that supplies services to state colleges.) Unfortunately, I'm not convinced that we can afford to use it in any large-scale way. X.25 seems to be priced for interactive transaction processing, where every minute or so a user with a block-mode terminal sends a couple of new values for a field and gets a few updates back. If you try to use it for something like a news feed, the packet charges kill you. It is cheaper to put in a dedicated line. Of course maybe if you are with the phone company, this isn't an issue for you. Our theory is that this is why the Internet doesn't use X.25 more than it does.