Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!uwm.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!csfst1
From: csfst1@unix.cis.pitt.edu (Charles S. Fuller)
Newsgroups: comp.sys.apollo
Subject: Re: Networking Apollo rings together with Cisco router boxes.
Summary: works well
Keywords: cisco DDS
Message-ID: <86164@unix.cis.pitt.edu>
Date: 1 Feb 91 02:53:12 GMT
References: <1991Feb1.000434.244@zoot.avgrp.cr.rok.com>
Reply-To: fuller@nye.nscee.edu (Charles S. Fuller)
Distribution: comp.sys.apollo
Organization: University of Pittsburgh, CIS
Lines: 39

We've been running DDS over cisco routers for some time now, using both
dedicated lines and switched virtual circuits, with minimal problem.
There are a few minor things that you'll run into, but the overall
implementation works quite well.  It has been our experience, though,
that IP data transfers through the same router perform better than 
DDS transfers (eg., ftp vs /com/cpf).

The first thing you'll notice when configuring the cisco is that they
don't provide a node id; you'll have to make one up.  We chose numbers
that are about 3X higher than current Apollo node id's, to avoid
collisions for a little while :-)  Enabling routing is a simple task,
but you'll have to remember when reading the docs that cisco manual
writers have probably never seen an Apollo, let alone configured one.
Between myself and a datacomm guru, we were able to arrive at common
terminology.

Then, once packets start flying, you'll probably want to do an 'lcnet 
-full -hw -conn' -- just to see what you've done.  The first thing
you'll see is an error message to the effect that the node identified as
the cisco did not respond, and that "touching" information may be
incomplete.  This is not an indication of problems, but, rather, an
indication that cisco routers lack the ability to respond to
"higher-level" DDS queries (like 'lcnet'). 

When combining networks, be sure to give some thought to administrative
issues, most importantly the registry.  There are 7 different registries
in our network, some of which span multiple sites.  Some are SR10, some
SR9.7.  We found out early on that, despite documentation to the
contrary, it is not necessary to merge registries UNLESS everyone needs
access to every machine.  If your sites are to remain autonomous, you
may want to leave the registries separate.  This also provides a little
extra protection from users at other departments, although root is
always root, capable of walking through the entire network.  Keeping
registries separate became a little difficult at SR10.0 and SR10.1, but
the addition of NCS cells at SR10.2 made registries a little more
manageable once again.

Hope these ramblings are of some use.
Chuck