![]() There are multiple D-Star networks in operation today. This effort has dramatically imporoved our network performance and reliability.īecause of the situation just described, we consider running these coordination steps to be a requirement for joining the network. 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. The Good News is that a group of administrators has come up with an automated process that allows this to be much more reliable. 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. With a growing number of Gateways, literally around the world, manually coordinating them all is almost impossible. With a small number of Gateways on the network, coordinating this effort is pretty simple. If things really worked this way, maintenance would be relatively easy. When they restart, they pull corrected information from the TRUST_SERVER.Read the data back into the central TRUST_SERVER.Edit the data, making the necessary changes or deletions.Write out the data on the centrall TRUST_SERVER. ![]() Shutdown the Gateway processes on every Gateway at the same time.The only way to accomplish that is to follow this process: Since every Gateway shares all of its information with every other Gateway, we have to remove that bad entry from all of them AT THE SAME TIME. Well, we just delete the bad entry, right? Not quite. Yep - the response to a command can take a REALLY long time! Now, think what happens if there is more than one of those invalid entries in the list of gateways. Of course, there's nothing at that address now, and the operation "times out" after 5 minutes. In normal operation, this shouldn't be an issue.īut what happens if a Gateway has had to change its IP address (changing ISP's, location, etc.)? This old address is still in the table, and every Gatewat in the network will attempt to synchronize with that old address. This also happens anytime an administrator adds a new user and executes a "push_mng" command, or whenever the administrator needs to execute a "reserve" command to obtain another block of 32 addresses to assign to new users. Why is this a Big Deal? Indulge us just for a moment here.Įvery Gateway synchronizes its database with every other Gateway, every day. The D-Star Gateway design does not allow for easy removal of data in the system. This is a sensitive subject for most administrators. Ease of installation is expected to improve in the near future. CentOS has been explored and works well also. The gateway is especially sensitive to iptables configurations, in many cases refusing to even load. The added security features seem to conflict with the Gateway. We do have FC5 and FC6 running, but they definitely require more attention than FC4 to install. Most of us are running Fedora Core 4, which we know is old. The RS-RP2C manual suggests Fedora Core 2 or Redhat 9 Linux. You'll need speed at least equivalent to good DSL. Workarounds like "sticky" IP addresses or Dynamic DNS are not applicable in this environment. 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. Because of this, we recommend leaving the gateway at the repeater site. 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. This computer needs to be at the repeater site with the repeater. 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. While this document will not attempt to replace a Gateway Certification Course, it will address most of the major points. The overall process is very simple, if you'll pay attention to some key points. This page is designed to give you an idea of what's involved in brining a new D-STAR Gateway onto the network. Your Source for D-Star Digital Amateur Radio Information!Īdding a Gateway Ver 2 D-STAR Gateway to the Network Overview
0 Comments
Leave a Reply. |