ASTi Logo

Telestra App Note

Telestra 2.x and 3.x Networking Concepts (#48)

I. Introduction

ASTi's product name, "Telestra", refers to the Linux-based platform on which a number of applications can be run. These include the Remote Management System (RMS) software, HLA communications software, and various radio simulation servers.

At this time, there are a variety of software combinations that can run on a Telestra platform.

  • Both Telestra series (version 2.x & 3.x) can provide RMS, HF server, ALE server, SATCOM server, Terrain server, and model documentation capabilities.

The main distinction between different software versions is:

  • Telestra 3-series software does not yet support HLA and provides no DACS management capabilities.
  • Telestra 2-series software offers full HLA and DACS support, but does not support the latest Model Builder Visual (MBV) environment.

Regardless of the application(s) running on a Telestra system, each platform supports three (3) ethernet interfaces. This application note attempts to clarify the sometimes-confusing issues involved with integrating a Telestra system with your existing network architecture.

Every Telestra platform ships with default settings for each network interface:

Interface Default IP Address Default Subnet Mask
eth0 via DHCP or via DHCP or none

For more information about out-of-the-box configuration, please consult the "Initial Network Configuration" section of the Telestra User Guide for your version of Telestra software.

As technology evolves, the Telestra chassis (and the locations of the three ethernet interfaces) will continue to change. Each ethernet port will be labeled on the rear of the Telestra chassis upon shipment from ASTi.

In example diagrams throughout this application note, Telestra platforms will be represented by either of the figures below.

Telestra Platform Icon

Regardless of your software version, any two ethernet interfaces on your Telestra system MUST NOT be configured to share the same network segment. Meaning: each ethernet interface must have its own IP address and subnet mask such that its network configuration does not overlap at all with the others.

II. 2-Series (HLA- & DACS-compatible) Software

Sections II-A and II-B do not address HLA-specific configuration rules; please see section II-C.


Again, any two ethernet interfaces on your Telestra system MUST NOT be configured to share the same network segment.

A. RMS & DACS Management

Telestra RMS provides remote DACS management over the network, via its web-based interface. Users access RMS and its management capabilities using a standard PC with a web browser.

For all 3 network interfaces:

  • RMS servers communicate with DACS systems using port 58999.
  • RMS servers communicate between each other using a user-configurable "Auto-Discover" port. The default value is 15000. The "Auto-Discover" port setting will be used regardless of the RMS server's "Auto-Discover" mode--either multicast or broadcast. See the Telestra RMS User Guide for more information about Auto-Discovery and its associated settings.

1. Standard Network & DIS Network Configuration

The diagram below represents Telestra RMS' standard (and DIS) network configuration. Note that the DACS systems to be managed by RMS are on the same network segment as Telestra eth0. In this example, the Browser PC is also on the same network segment. Simply point the web browser to the IP address of Telestra eth0 to access RMS.

Standard Network Configuration

This is the recommended network configuration for Telestra RMS on a standard or DIS network.


After initial installation or cold start of the Telestra system, you should change the system's IP address to match your local network using the Telestra Configuration Utility. This utility allows you to change the settings of eth0 only. (This procedure is outlined in the Telestra User Guide, so will not be covered here.)

Also--at this time--the RMS server only publishes the IP address of eth0 to other RMS servers during the Auto-Discovery process (where each RMS server locates all others on the network).

It is possible to stray from this recommended network configuration without adversely affecting the operation of DACS or Telestra systems, but this requires more work on your part, as we'll soon see.

2. Alternate Network Configuration

The diagram below represents an alternative to the recommended network configuration, outlined above.

Alternate Network Configuration

This network configuration will work, but is not recommended.


First, it takes longer to set up. You'll have to use the Telestra Configuration Utility to change Telestra's eth0 IP address, wait for a system reboot, point to eth0 with a browser on the same network segment (blue in diagram), change Telestra's eth1 IP address through RMS, wait for a network services restart, then point to eth1 with a different browser on the other network segment (purple in diagram).

Also, because RMS only publishes the IP address for the system's eth0 interface, it may become confusing to have to point the browser to an entirely different IP address (that of eth1).

This example is only included to demonstrate proof-of-concept: the Browser PC can be on a different network segment than managed DACS systems, provided two of Telestra's ethernet interfaces are also members of those networks.

If, for some reason, your application requires the Browser PC to be on a different network than the DIS network, a configuration like the one pictured below will avoid confusion and your having to do more work, but will still conform to your network architecture.

Alternate Network Configuration

3. Another Alternate Network Configuration

The diagram below represents yet another alternative to the recommended network configuration, outlined in section A above.

Alternate Network Configuration 2

This network configuration will work, but is not recommended.


For the same reasons listed in section B above, namely longer set up time and the possibility of confusion.

This example is only included to demonstrate proof-of-concept: multiple, managed DACS systems can be on separate network segments, provided two of Telestra's ethernet interfaces are also members of those networks.

Again, if your application requires three separate networks, something like the setup pictured below will do the trick and minimize hassles.

Alternate Network Configuration 2


Although the network setup shown in section 1 is the recommended configuration, your particular application may require a setup similar to that shown in section 2 or in section 3. In all of the examples above, the Telestra RMS server can locate and manage all of the DACS systems shown, and you should not experience any difficulty accessing the RMS server itself.

AS A RULE: Always try to have your Browser PC on the same network segment as Telestra's interface eth0.

4. RMS and the Wide-Area Network

Using Telestra RMS to manage DACS systems on multiple networks requires special consideration. The most important thing to remember is that, unlike closed LANs, cases like these require "gateway" settings for each network interface.

The diagram below shows this concept in its simplest form.

Simple Routing Across WAN
  • 1 - Point your browser to the RMS server
  • 2 - Monitor/manage DACS on LAN
  • 3 - Monitor/manage DACS over WAN

To make this work, you must employ a router, and set up the systems to use it. For this example, we've assigned arbitrary class C networks for both networks A (192.168.1.x) and B (192.168.20.x). The following settings are arbitrary as well, but demonstrate a few important points.

Interface IP Netmask Gateway Managed By
Telestra eth0 n/a
Browser PC n/a
Router EA n/a n/a
Router EB n/a n/a
  • Every system on Network A uses the router's EA IP address as its gateway.
  • The DACS system on Network B uses the router's EB IP address as its gateway.
  • Both DACS systems, regardless of the network to which they belong, point to Telestra eth0 as its Manager IP address.

Although this example is quite simple, the same concepts apply to multiple groups of DACS systems on any number of separate--but interconnected--networks. Configure gateways locally, point RMS servers to DACS systems over the WAN, and vice versa.

5. Multiple RMS Servers

Employing multiple RMS servers to manage a number of DACS systems may be required by your application. In this section, we'll look at a very simple example using 2 RMS servers that works just fine. Then, we'll introduce a couple of GOTCHA!'s that the use of multiple RMS servers presents, and how to avoid them. First, the most basic example:

First, the most basic example:

Basic Multiple RMS Setup
  • 1 - Point your browser to one RMS server.
  • 2 - From there, monitor/manage a DACS system.
  • 3 - From there, jump to the other RMS server.
  • 4 - From that one, monitor/manage another DACS system.

Jumping from one RMS server to another (step 3 above) is made possible through an RMS feature called "Auto-Discovery". Each RMS server pumps out a "heartbeat" once every 5 seconds that contains various information about the server itself, including the IP address of its eth0 interface. Every other RMS server that can receive that information will display a neat little RMS server icon in your web browser that you can click on. At that point, your browser leaves the original RMS server, and begins retrieving information from the other one. This is bi-directional, meaning you can jump back-and-forth between RMS servers at will.

Gotcha! #1

Here, we have almost the exact same network configuration as in the prior example. The only difference is that our second RMS server's connection to the network is via a different interface (eth1). Take a look:

Improper Network Configuration

In this example, you can still hit the first RMS server with your browser, and manage its associated DACS system. You cannot, however, jump from the first RMS server to the second one; therefore, you can't manage the other DACS system.


It's a limitation of the Auto-Discovery process. Each RMS server pumps out the "heartbeat" on all its interfaces (eth0, eth1 and eth2). But each RMS server only publishes the IP address of its eth0 interface in the "heartbeat".

The first RMS server receives the second's "heartbeat", so it displays the cool little icon in your browser. BUT, the link it creates so you can click on the icon points to the IP address of the second RMS server's eth0 interface. As you can see, we don't have anything connected to the second server's eth0; it's not "on the network", and your browser will be unable to access its web server.


  1. Point your browser to the IP address of the second server's eth1 interface, provided you know what it is. Then, you can manage the other DACS.

    OR, better yet...

  2. Connect RMS servers to the network using only their eth0 interface, which is your best bet.


In sections 2 and 3 above, we demonstrated that the Browser PC and managed DACS systems don't have to be on the same subnet, nor do they have to be connected to an RMS server using its same network interface. This also applies to RMS servers, but can present problems.

Multiple Networks & RMS Servers

In this example, point the web browser to the local RMS server to manage one DACS on our LAN, and another DACS over the WAN. Even though both RMS servers will know about the other (and display this information to you), you cannot however, jump from our local RMS server to the remote RMS server.


You can't do this because, basically, neither Telestra nor the RMS software is a network router. It is important to understand the flow of data and the idea of "network segments" in this example. Let's break it down:

  • 1 - Browser communicates with local RMS server on its eth0 interface.
  • 2 - One DACS communicates with local RMS server on its eth0 interface.
  • 3 - Another DACS communicates with local RMS server on its eth1 interface.
  • 4 - Remote RMS server communicates with local RMS server on its eth1 interface.

The key is... in all of these paths of communication, the two communicating devices are both members of the same network.

From the local RMS server's viewpoint, some information is coming in from Network A via eth0, and some is coming in from Network B via eth1. The RMS software doesn't care where the information is coming from; it has the info, and will give it to you upon request.

In order to jump from the local RMS server to the remote RMS server, the network traffic involved would have to travel into local RMS eth0, out of local RMS eth1, and into remote RMS eth0... and then all the way back. Take a look:

This won't work!

This will not work because 1) you're dealing with two separate network segments, and 2) Telestra will not pass HTTP (web protocol) traffic in one network interface and out the other, or vice versa.

So how do you get to that remote RMS server?

Install a router:

This works quite nicely.

B. Telestra & the Multicast Router

Telestra's multicast routing software is controlled via the RMS web-based interface and works in conjunction with Model Builder software running on DACS systems (which may or may not be managed by RMS, your call).

Using the Telestra platform as your multicast router allows you to: 1) route desired transmissions directly to specific receivers, 2) exclude others from receiving that transmission, and 3) restrict local traffic to the local subnet, and away from the wide area network. This translates into dramatic improvement in your network's efficiency. See ASTi's discussion, "ASTi's Enhanced IP Multicasting Improves Internetwork Efficiency" for more information and a great sales pitch.

Because of its nature, Telestra as a multicast router only controls traffic between network interfaces eth0 and eth1. To maximize its effect as such, it only makes sense to keep your DACS systems segregated from the rest of your simulation network. Otherwise, how can the router do its job?

The diagram below shows the recommended location of DACS systems for optimal network performance. Note the various locations of Browser PCs and their labels.

RMS + Multicast Router

DACS: Create a DACS subnet that connects with Telestra's eth1, and configure the systems to use multicast. The Telestra's multicast router will only allow "subscribed-to" network traffic to pass through to eth0, and onto the simulation network. For more information regarding DACS system configuration, please see Application Note 41: Multicast Routing for Voice Networks.

Browser PCs: The Browser PC sharing a network with Telestra's eth0 is the recommended location from which to access the RMS server. Networking the Browser PC at either of the alternate locations will work just fine, but translates into more work for you.

C. Telestra HLA

Because of the software's inherent functionality, Telestra HLA systems require a fixed network architecture.

The diagram below shows the only valid network configuration for Telestra HLA systems.

Telestra HLA Configuration

To access RMS, you can connect a browser PC to any of the three networks shown above.

Recommended: Connect the browser PC to the HLA Network (eth0).

For information regarding port numbers used by Telestra HLA, please see Application Note 44: Host Control Via Telestra, and the Telestra User Guide.

III. 3-Series (MBV-compatible) Software

There are no "hard-and-fast" rules for configuring Telestra 3-series software network parameters. The radio, terrain & RMS servers will accept and reply to requests on any of the three ethernet interfaces.

However, please pay attention to these suggestions from the 2-series section of this document:

When setting up the system to work with a host computer (e.g., for model manipulation), you must specify which interface to use--but this is also reconfigurable at any time.


Again, any two ethernet interfaces on your Telestra system MUST NOT be configured to share the same network segment.