The first published book on D-Star!
Adding a Gateway Ver 2 D-STAR Gateway to the Network
This page is designed to give you an idea of what's involved in brining a new D-STAR Gateway onto the network. The overall process is very simple, if you'll pay attention to some key points. While this document will not attempt to replace a Gateway Certification Course, it will address most of the major points.
Equipment and Location
The Gateway requires a computer with at least two Ethernet ports, a minimum of 512 MB of memory, and a recommended processor of at least 2.4 GHz. This computer needs to be at the repeater site with the repeater. It's possible to remotely locate the Internet connection if absolutely necessary, but the network segment between the RP2C controller and the Gateway is very sensitive to latency. Because of this, we recommend leaving the gateway at the repeater site.
OK, here's the bad news - you MUST have a static IP for use on the D-Star network! D-Star is designed around static IP addresses. Workarounds like "sticky" IP addresses or Dynamic DNS are not applicable in this environment. You'll need speed at least equivalent to good DSL.
The RS-RP2C manual suggests Fedora Core 2 or Redhat 9 Linux. Most of us are running Fedora Core 4, which we know is old. We do have FC5 and FC6 running, but they definitely require more attention than FC4 to install. The added security features seem to conflict with the Gateway. The gateway is especially sensitive to iptables configurations, in many cases refusing to even load. CentOS has been explored and works well also. Ease of installation is expected to improve in the near future.
This is a sensitive subject for most administrators. The D-Star Gateway design does not allow for easy removal of data in the system. Why is this a Big Deal? Indulge us just for a moment here...
If things really worked this way, maintenance would be relatively easy. With a small number of Gateways on the network, coordinating this effort is pretty simple. With a growing number of Gateways, literally around the world, manually coordinating them all is almost impossible. But remember, if even one Gateway doesn't execute this process at the same time, its data will be the old data, and the old data will repropagate throughout the network, rendering the exercixe futile.
The Good News is that a group of administrators has come up with an automated process that allows this to be much more reliable. It's acocmplished by asking each Gateway in the network to install a set of scripts that check a central site for cleanup schedule coordination, and then executing the appropriate steps at the scheduled times. This effort has dramatically imporoved our network performance and reliability.
Because of the situation just described, we consider running these coordination steps to be a requirement for joining the network.
There are multiple D-Star networks in operation today. They do not share anything between networks. Communication between networks is not possible. Because of the synchronization described above, as soon as information about any one Gateway in Network A is added to Network B, the Gateways all automatically synchronize, and the two networks are then one.
TrainingThose of us who were early adopters of the Gateway fumbled our way through learning many of the features and restrictions of the Gateway. To make things easier on those who followed, we recommended a Gateway Certification Course for new trustees, in order to minimize the impact to the network of errors made by new administrators with erroneous assumptions about how things "should" work, versus how things really do work with the system. Many of us with technical or networking backgrounds found it difficult to release our assumptions, and to accept the design for what it is. Since mistakes on one Gateway impact every other Gateway in the network, we chose to require some training.
We do not expect everyone in the world to go through the existing training course. Many new owners will say that "I know networking - I don't need a training course!" Our experience has been that this almost always results in our executing a network cleanup to remove the errors that come from things like this. Fortunately, the cleanup scripts running on all the gateways make this process much less painful for everyone.
We have a Yahoo! Group set up form Gateway Administrators. There's no secret information there, but we do try to use that as a place to discuss network coordination and Gateway-specific things, with participation limited to those who are responsible for Gateways on the network. If you have a Gateway on the network and are not a member, please contact Jim McClellan, N5MIJ, via K5TIT.org to join the group.
Our current procedure for bringing a new Gateway online is for the new Administrator to perform a test with the D-Star Technical Support Group at ICOM. When that test is successfully completed, the cleanup scripts are installed on the new Gateway, and the notification is sent to the Network Coordinator for the D-Star network with contact information for the new Administrator. The Network Coordinator will then contact the new Administrator with information about the network TRUST_SERVER, and describe the final processes for bringing the new Gateway online.
We know that everything we do in D-STAR will be subject to change as the technology grows, and as our experience improves. We ask that you be patient with us as we all learn together to best implement the capabilities of D-Star. Each regional area will develop their own training and implementation criteria. Many will join a common network. We'll find better ways to manage things. We'll all learn together.
|© Copyright D-StarUsers.org, All Rights Reserved.|
|Last Heard and DStarMonitor Disclaimer|