🚀 go-pugleaf

shaffer@hamlet.ctd.anl.gov writes:
> [ Bridged network -> routers: what to do with the Non Routable
>     Protocols (tm) ]
>
> Soooo... we can...
> 1. Bridge the brain-dead protocols (there are several).
> 2. Buy a bunch of seperate protocol converters.
> 3. Give them their own bridged FDDI ring.
> 4. Let them continue to use the old bridged system(minimal support) while we
>    move on.
> 5. Refuse to support them.
> 6. Go on a crusade to convert the heathens :-)
> 
> 1&3&4 seem like a management nightmare. 2&3 are expensive. 4&5 have grave
> political implications and 6 is not even worth considering.

We do 1 with traces of 5 and 6 - Ciscos will of course bridge what they
cannot route so there's no extra equipment cost.  [Thinks: does he not
know that the Ciscos bridge as well, and is that why the next paragraph?]

> [ Couldn't a Cisco encapsulate NRPs in IP? ]

Doesn't need - it bridges them.

> So to the questions...
> 
> question for cisco...have you looked into the possibility of doing this
> kind of thing? Is it possible/practical? How would you handle this situation?
> 
> Question for the rest of the world...Any advice on setting up and
> administering mega-multiprotocol networks esp. with regard to the NRP?

At this site bridged protcols include LAN Manager over NBP, the various
DEC protocols (LAT, LAVC, MOP - yes, perverts that we are we boot a
VAXStation through a Cisco, but not through 8.2(3) :-(, but we should be
able to with 8.2(4) :-) ) and, until Cisco come up with the promised OSI
CONS routing, the UK's private version of CONS known as Pink Book. 
Managing it isn't a particular problem - you just turn on the bridging
and away it goes.  The spanning tree sorts itself out and you've got a
network.  You might of course want to fiddle things, depending on the
shape of your network, but it's not absolutely necessary.

I mentioned 5 and 6 above.  We provide bridging but we guarantee to
support only a subset of protocols that happen to be bridged, namely NBP
and CONS.  If they want to run LAVC or LAT across our network then
that's their own problem - we don't support it.  In fact we're planning
to explicitly block LAVC - all those nasty multicasts.  They can get
terminal service via other protocols if they need to.  Anyway, the usual
reason for LAT breaking is the stupid timeouts and that's adjusted in
the hosts, there's nothing the network provider can do about it. 

Oh, yes.  You can't yet (I don't think) run AppleTalk over FDDI.  If
you've got Apples you'll need to watch that.  A large bridged AppleTalk
network could be a real pain to manage...


Sam Wilson 
Network Services, Edinburgh University Computing Service, Scotland, UK