- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: LAT communication over WAN
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2008 07:49 AM
тАО10-20-2008 07:49 AM
The attachment shows TSM output on the DR VAX followed by TSM output on the production VAX.
Is there anything that I might be missing or anything that I can check to help diagnose the problem? My network engineering contact tells my that the Cisco router on the DR VAX end should be tunneling the LAT packets between the DR VAX and the remote LAN, but I'm not 100% sure that this is accurate. Any help would be greatly appreciated!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2008 08:06 AM
тАО10-20-2008 08:06 AM
Re: LAT communication over WAN
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2008 08:10 AM
тАО10-20-2008 08:10 AM
Re: LAT communication over WAN
My solution would be to use an analyzer (e.g., WireShark) to check the actual transmissions between the systems.
That said, LAT over Wide Area Network connections is somewhat problematical because of issues related to propagation delay and the LAT protocol.
I have seen many situations with various protocols where misconfigured networks and routers have failed to forward packets in one direction or the other.
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2008 08:15 AM
тАО10-20-2008 08:15 AM
Re: LAT communication over WAN
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2008 08:26 AM
тАО10-20-2008 08:26 AM
Re: LAT communication over WAN
Several years back at the production site our VMS production system was communicating with DECserver 200s located across town via a T1 line. So first question: We must have been bridging LAT through our Cisco routers right?
Second question: Please explain the propagation delay issue. This is of concern because the DR VAX would be communicating with a PLC in which the normal production request/response time is < 320 milli-seconds. The production VAX has no problem maintaining reliable communcations, but I do need to determine how fast the remotely located DR VAX can communicate with this same device.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2008 09:27 AM
тАО10-20-2008 09:27 AM
Re: LAT communication over WAN
The LAT protocol has some timeouts that are reasonable in a LAN environment, but not necessarily workable in a WAN environment, particularly when there are any line errors. I do not have the citation handy, but it was a fairly well known fact when LAT was more heavily used.
Today, I would be tempted to use a telnet connection to the host in place of a LAT connection where there is potential for wide area access,
These problems would show up as dropped connections, not failure to see the services. Those are most likely caused by packets not reaching the receiver node.
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2008 12:12 PM
тАО10-20-2008 12:12 PM
Re: LAT communication over WAN
> Cisco routers right?
Right. For LAT, bridging works, routing
doesn't.
> Second question: Please explain the
> propagation delay issue.
I don't remember the fine print (probably
because I never knew it), but LAT has some
sensitivity to latency. That said, once,
upon a time long ago, I was at one end of a
9600b/s leased line between CA and MN with a
(forgotten brand, model) bridge+router at
each end. We never relied on LAT working
over that link, but it always worked when I
tried it (just fooling around, no serious
testing).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2008 12:34 PM
тАО10-20-2008 12:34 PM
Re: LAT communication over WAN
TSM uses MOP, not LAT, to communicate with your terminal servers. MOP (Maintenence Operations Protocol) is a non-routable protocol and has to be bridged or tunneled across a WAN link.
MOP uses three packet types, one for loopback testing, one for dump and load functions and one for remote console. The packet tyes to be bridged are 90-01, 60-01 and 60-02 respectively.
If you are using older DECservers that do not contain flash memory to load their software, you had better bridge MOP or get additional load hosts installed at your primary site. Otherwise if the VAXes are down at the primary site and the terminal servers are rebooted or loose power for what ever reason, they'll never get a down-line load. Your DR plan has a hole in it.
Bill
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2008 01:54 PM
тАО10-20-2008 01:54 PM
Re: LAT communication over WAN
>>doesn't.
>>TSM uses MOP, not LAT, to communicate with your terminal servers.
>>MOP (Maintenence >>Operations Protocol) is a non-routable >>protocol and
>>has to be bridged or tunneled across a WAN link.
So, IF LAT bridging (or possibly tunneling) is set up correctly, how do I verify that it's working, if not through TSM. It sounds like MOP also needs to be bridged or tunneled.
>>If you are using older DECservers that do not contain flash memory to
>>load their software, you had better bridge MOP or get additional
>>load hosts installed at your primary site. Otherwise if the VAXes are
>>down at the primary site and the terminal servers are rebooted or loose
>>power for what ever reason, they'll never get a down-line load.
>>Your DR plan has a hole in it.
Good catch. The original plan has been to relocate the DR VAX to the LAN where the "event" has taken place. (If a LAN still exists of course...) The DR VAX has the terminal server software on it and can function as a load host. Only recently was I asked to test LAT across the WAN.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2008 02:38 PM
тАО10-20-2008 02:38 PM
Solution$MCR LATCP SHOW SERVICE will show you the LAT service messages that the DR system can "hear" on the network. If you see your production server's LAT service you should be able to $SET HOST/LAT
"Outgoing connections" have to be enabled in LATCP. Outgoing connections can be enabled by $MCR LATCP SET NODE
Bill