Conference netcad::hub_mgnt

According to note 44 in the ROCKS::Frame_relay notes conferance.  Trying LAT 
accross a Frame relay is not a good idea.  I know that and can accept that, and 
would not expect good response.  But we should at least see the services offered.

But can the DECBrouter 90 bridge LAT across the FRame Relay?  Or is it disabled
automatically?  The documentation does not lead to any firm conclusions.  The 
documentation does say you can bridge accross a Frame Relay and in another 
section says that LAT is not a routable protocol and can only be bridged.  This
will lead customers to the conclusion that LAT can only be bridged, and since the 
DEC Brouter 90 can bridge across a FRame relay.  Lat should work.  Strange 
convolted thnking, but we still get calls when customers run into problems with
more than 25 LAT sessions with a 56KB Vita link bridge.  That combined with the 
limitations of Cterm is going to be a sore spot.

If LAT cannot be used across the Frame Relay and is in fact prevented from 
doing so then we need to clearly state that in the documentation, and sell this
customer DQS.  If LAT will work across the FRame Relay we need to clearly
state in the documentation the conditions and limitations.



Thanks for any input
Alan

 

You did not mention the customer.  I have talked to Scripps-Howard and discussed
an error in their configuration file.

If this is not Scripps-Howard, please send me a copy of their configuration
files (write term command) for all their routers. They need to ensure that they
have bridging enabled on all interfaces (bridge-group 1 command or similar)
and they should not have any beta software earlier than around 9.14(0.12). The 
most recent version is 0.15  dated 07-Apr-93 -- igs-bfpx.914-0.15 (TFTP) and 
igs-bfpx.914-0.15.sys (MOP load). Both files are in the directory 
EEON1::"/usr/tftp/" via DECnet or the anonymous FTP/TFTP directory on 
irenaeus.mlo.dec.com (16.123.96.47) or prnsy1.mlo.dec.com (16.123.96.68) via 
TCP/IP.  If those filenames are too long, you can use "f" for the TFTP version 
or "f.sys" for the MOPversion.  It's also available for MOP load from Kali; 
the name is DEWBR. ("f" and "f.sys" should always be the most recent image.)


> But can the DECBrouter 90 bridge LAT across the FRame Relay? 

yes.

> This will lead customers to the conclusion that LAT can only be bridged, and 
> since the DEC Brouter 90 can bridge across a FRame relay.

This is true.

> If LAT will work across the FRame Relay we need to clearly
> state in the documentation the conditions and limitations.

There are no specific conditions and limitations to DEWBR bridging of LAT over
frame relay. As with any attempt to bridge LAT over WANs, however, it's not a
smart idea.

Customers should be encouraged to use protocol translation on the DEWBR whenever
possible.  It works a lot better.  Protocol translation involves translating
LAT connections into Telnet, which is routed over the WAN, and then translated
back into LAT.  This is quite suitable for a small number of services. There is
no danger of losing connections with this scheme.

Eric

  It looks like LAT service announcement is not bridged properly. If you
check Ethernet with LAN analizer(like Sniffer), you will be more confidet...

  BTW, have you tried this ?

        frame-relay map bridge {DLCI} broadcast
                                      ~~~~~~~~~
  Also check if Customer's frame relay switch (or telephone company's
frame relay service) supports "multicast DLCI facility". If NOT, you may
try to do this. (Of course, you need another PVC(DLCI) for bridging 
multicast/broadcast if frame relay facility dose not support multicast
DLCI)

        frame-relay multicast-dlci {DLCI}

  Basically, support of multicast DLCI in frame relay network is very
important for Internetworking. Otherwise, brouter must copy multicast/broad-
cast for every DLCIs.

  Hope this helps,

---Masami