percy@amdcad.AMD.COM (Percy Irani) (08/23/87)
We are seriously considering evaluation of Sun based IP routers
for our Ethernet. Does any one out (in the world) uses Sun routers
for connecting their Ethernet (TCP/IP)? [ I know Sun does!! ]
What about using them with DECNET sharing the same (leased phone) line?
Any other problems people have encountered using the Sun product
(ala reliability, routing updates, size constraints etc.)
Does any one uses their software for network monitoring?
What does the rest of the world use for network monitoring *
- for monitoring their TCP/IP based Ethernet (for the main backbone)
- for monitoring lease line(s) for other internet connections
(lets assume all TCP/IP type connections).
- Any public domain stuff?
* monitoring = BIG WORD!! Like to know what other people do. There
have been intresting articles in IEEE Network issues about them.
Lets see whats being done in the world!
--
Ignorance is bliss but can be embarassing at times!hedrick@topaz.rutgers.EDU (Charles Hedrick) (08/27/87)
Sun's Ethernet hardware is quite good. There's no reason in principle why a Sun couldn't be a very good IP gateway. However there are some practical things that make this less than optimal. The versions of SunOS we have seen are based on 4.2. In order to avoid stability problems, gateways have to have much more careful validation of packets than 4.2 does. E.g. they have to recognize every possible broadcast address format, and also refuse to forward packets for invalid addresses (as opposed for example to sending ARP requests for Martian addresses). This is somewhat better in 4.3 than 4.2, but even 4.3 does not recognize all possible old and new style broadcast addresses, nor as far as I can tell does it have a complete Martian filter. We expect our gateways to do proxy ARP (for hosts that can't handle subnets, and a few that can't even deal with routing). This is not present in 4.2, and as far as I know is not in 4.3 either. We expect our gateways to be up all the time. Normal timesharing systems are taken down periodically for PM, software installation, etc. Our gateways (cisco) download software from a server. Going to a new release requires downtime of about 30 seconds. Suns typically require a good deal longer than this to bring up new releases. Some sites also take them down for backups, and now and then they crash (though in honesty I'd have to say that our Suns are very stable). I believe that the operational requirements of a gateway are at least slightly inconsistent with those of a host. If you are building a large or complex network, the vendors whose business is making routers are likely to have better routing technology than routed, to support a wider variety of media, (As an example, we tried to interface our Sun to the Arpanet and found that although 1822 interfaces existed, we couldn't find anyone who knew how to get them.), and to be more aggressive about supporting new network monitoring standards. In the long run, there are going to be performance advantages. At the moment, Suns probably perform at least as well at connecting Ethernets as the typical dedicated routers. We have used Suns as gateways between major Ethernets and restricted Ethernets containing only diskless Suns. They perform very well at this. I'm sure we will continue to use Suns as gateways to one extent or another. However for large networks, those with complex topologies, and those serving machines from many vendors (and with buggy TCP implementations), I would recommend using a gateway from a vendor that specializes in such things.
melohn@SUN.COM.UUCP (08/28/87)
>The versions of SunOS we have seen are based on 4.2. In order to >avoid stability problems, gateways have to have much more careful >validation of packets than 4.2 does. E.g. they have to recognize >every possible broadcast address format, and also refuse to forward >packets for invalid addresses (as opposed for example to sending ARP >requests for Martian addresses). This is somewhat better in 4.3 than >4.2, but even 4.3 does not recognize all possible old and new style >broadcast addresses, nor as far as I can tell does it have a complete >Martian filter. We have gradually introduced many 4.3 networking features into various release of SunOS, beginning with SunOS 3.3. We plan to have all of 4.3 features in the next major release of SunOS. > >We expect our gateways to do proxy ARP (for hosts that can't handle >subnets, and a few that can't even deal with routing). This is not >present in 4.2, and as far as I know is not in 4.3 either. > Proxy ARP exists for Sun machines. If it is generally felt that this is a hinderance to using Suns as internet gateways, we will look into making it a supported part of the product. >We expect our gateways to be up all the time. Normal timesharing >systems are taken down periodically for PM, software installation, >etc. Our gateways (cisco) download software from a server. Going to >a new release requires downtime of about 30 seconds. Suns typically >require a good deal longer than this to bring up new releases. Some >sites also take them down for backups, and now and then they crash >(though in honesty I'd have to say that our Suns are very stable). >I believe that the operational requirements of a gateway are at least >slightly inconsistent with those of a host. This is historically a reasonable arguement, especially when dealing with large host systems that support timesharing or other loads. Within our own internal network we have many dedicated gateway machines with no local file system to backup whose uptime is regularly measured in weeks. Our network is built mostly out of file server machines with two ethernet interfaces; these are maintained by a central support staff, and support both diskless clients and internetworking connectivity. Having several gateways between each network distributes the load and increases the redundancy if any particular node fails. A diskless Sun running as a dedicated network server offers much the same network-loadable gateway capability as a cisco box at approximetly the same cost, albeit both the client and its server must be reliable. > >If you are building a large or complex network, the vendors whose >business is making routers are likely to have better routing >technology than routed, to support a wider variety of media, (As an >example, we tried to interface our Sun to the Arpanet and found that >although 1822 interfaces existed, we couldn't find anyone who knew how >to get them.), and to be more aggressive about supporting new network >monitoring standards. Here, I take strong exception to your statements! Pardon the commercial, but I don't know of any gateway box vendor who supports the range of media AND protocols that Sun currently supports. We run IP over Ethernet, Token bus, and load-shared sync connections; we offer gateways to DECnet, OSI, SNA, etc. We have had an DDN gateway product for almost a year, supporting both 1822 and X.25. We are actively involved in both Internet and OSI protocol committees, and as standards emerge that replace routed, EGP, and friends, we will have products that implement those standards. > >In the long run, there are going to be performance advantages. At >the moment, Suns probably perform at least as well at connecting >Ethernets as the typical dedicated routers. > Sun continues to be very agressive in delivering multiple MIPS at the lowest cost per MIP in the business. The technology that brings forth low cost high powered workstations can also be used just as effectively for high speed internet gateways.
melohn@SUN.COM (Bill Melohn) (08/28/87)
>We expect our gateways to be up all the time. Normal timesharing >systems are taken down periodically for PM, software installation, >etc. Our gateways (cisco) download software from a server. Going to >a new release requires downtime of about 30 seconds. Suns typically >require a good deal longer than this to bring up new releases. Some >sites also take them down for backups, and now and then they crash >(though in honesty I'd have to say that our Suns are very stable). >I believe that the operational requirements of a gateway are at least >slightly inconsistent with those of a host. This is historically a reasonable arguement, especially when dealing with large host systems that support timesharing or other loads. Within our own internal network we have many dedicated gateway machines with no local file system to backup whose uptime is regularly measured in weeks. Our network is built mostly out of file server machines with two ethernet interfaces; these are maintained by a central support staff, and support both diskless clients and internetworking connectivity. Having several gateways between each network distributes the load and increases the redundancy if any particular node fails. A diskless Sun running as a dedicated network server offers much the same network-loadable gateway capability as a cisco box at approximetly the same cost, albeit both the client and its server must be reliable. > >If you are building a large or complex network, the vendors whose >business is making routers are likely to have better routing >technology than routed, to support a wider variety of media, (As an >example, we tried to interface our Sun to the Arpanet and found that >although 1822 interfaces existed, we couldn't find anyone who knew how >to get them.), and to be more aggressive about supporting new network >monitoring standards. Here, I take strong exception to your statements! Pardon the commercial, but I don't know of any gateway box vendor who supports the range of media AND protocols that Sun currently supports. We run IP over Ethernet, Token bus, and load-shared sync connections; we offer gateways to DECnet, OSI, SNA, etc. We have had an DDN gateway product for almost a year, supporting both 1822 and X.25. We are actively involved in both Internet and OSI protocol committees, and as standards emerge that replace routed, EGP, and friends, we will have products that implement those standards. > >In the long run, there are going to be performance advantages. At >the moment, Suns probably perform at least as well at connecting >Ethernets as the typical dedicated routers. > Sun continues to be very agressive in delivering multiple MIPS at the lowest cost per MIP in the business. The technology that brings forth low cost high powered workstations can also be used just as effectively for high speed internet gateways.
geof@imagen.UUCP (Geof Cooper) (08/28/87)
Interdispersed with much stuff with which I have no problem, you write: > ..... Having several gateways between each > network distributes the load and increases the redundancy if any > particular node fails..... "Distributes the load"? I know of no network standard that allows this to happen. It is a major failing of the Internet protocol suite that redundant gateways improve the reliability of an internet, but don't increase its capacity to handle traffic (not that other protocols such as XNS or DECNET been more successful). If you have accomplished this, can you let us all know how? - Geof
SATZ@MATHOM.CISCO.COM (Greg Satz) (08/28/87)
It seems the internet gateway market is heating (or flaming) up. Instead of vendors showing off their features in a public forum like TCP-IP, maybe an interested member of the community would be willing to chase down the features and capabilities of the latest off-the-shelf products from the gateway vendors and make them available. This may be more beneficial to more people. As an aside, it seems that the europeans have a show called "CeBIT MultiNET, the new dimension in communication" where many vendors with TCP-IP products get together and do what they do best -- interoperate. Seems like a good idea to me. -------
LYNCH@A.ISI.EDU (Dan Lynch) (08/29/87)
Greg, The "good idea" you refer to (Europeans putting on a TCP/IP interoperability show) is something that we are working on here in the USA. We are working with many dozens of vendors to construct a permanent facility for demonstrating TCP/IP interoperability to the public. It will be open daily and we have scheduled the opening for January, 1988. It will live at Techmart, next to the Santa Clara Convention Center and should be an impressive activity. It is called the Connectivity Showcase and will be paid for by the vendors who want to clearly demonstrate that their products run harmoniously together. Users will be able to come in and run demos between any machines they wish to find out about. If it really catches on we wil be opening up additional sites in other US locations. Dan -------
CERF@A.ISI.EDU (08/29/87)
I had always hoped that the initiative taken by Dan Lynch with his conferences, seminars and Tech Mart would lead to the kind of joint demonstrations you suggest and which I agree are generally more productive than indiscriminate flaming. However, when there is real reason to flame, I am always glad to find a few souls willing to brave the heckling of their peers to holler about things that need fixing. Vint Cerf
karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) (08/30/87)
Geof, the Berkeley/UNIX "routed" router (and other similar routing protocols) choose among equal-cost routes semi-randomly. Different hosts and gateways may then choose different gateways for the same destination. The same is true for hosts that use one of several default gateways and then process redirects from them; they'll either choose a suitable gateway, or be redirected to that particular gateway's choice of next-hop router. None of this manages carefully-equalized load balancing, but does tend to spread out the load among multiple gateways. Mike
geof@apolling.UUCP (Geof Cooper) (08/31/87)
> This isn't exactly a failing of the standards, except maybe by > omission..... Actually, I think it IS a failing of the standards (by the way, some people misread my message -- I'm in favor of load sharing. I want EVERYONE to do it). Clearly, implementors have found ad hoc ways of achieving load sharing. We've seen three here (random choice, round robin, choose the first response ("load-biased random"?)). What are the implications of each to network congestion? Network reliability? One implementor points out that the load-sharing decision must not be made every packet. How frequently is right? How do the different schemes interact? Are there some combinations that make network congestion worse? There are non-trivial issues of network congestion and performance at stake. A standard is supposed to address these by causing even the most naive implementor to use a "good" technique. The standard also ensures that everyone addresses the problem. There are certainly gateways out there today (we have some) that don't support ANY ad-hoc load sharing system. So if we think that load-sharing is important (I do), and we know that it is tricky (cf above questions) then this is exactly the sort of thing the standards should address. - Geof