Configure private peering stand-alone tutorial

content/concepts/the-rippled-server/peer-protocol.ja.md

@@ -28,7 +28,7 @@ protocol = peer
 
 ピアプロトコルポートは[特殊なPeer Crawler APIメソッド](peer-crawler.html)も処理します。
 
-### ノードキーペア
+## ノードキーペア
 
 サーバーを初めて起動すると、ピアプロトコル通信でサーバー自体を識別するための _ノードキーペア_ が生成されます。サーバーはこのキーを使用して、ピアプロトコル通信のすべてに署名します。これにより、ピアツーピアネットワーク内の別のサーバーからのメッセージの整合性を、信頼できる方法で識別、検証できます。これは、そのサーバーのメッセージが信頼できないピアにより中継される場合も同様です。
 
@@ -37,6 +37,10 @@ protocol = peer
 ノードキーペアは、このサーバーと共に[クラスター化](clustering.html)されている他のサーバーも識別します。サーバークラスターを使用している場合、一意の`[node_seed]`設定を使用してクラスター内の各サーバーを構成する必要があります。クラスターの設定についての詳細は、[`rippled`サーバーのクラスター化](cluster-rippled-servers.html)を参照してください。
 
 
+## Fixed Peers and Peer Reservations
+
+**注意:** 現在の所はこの部分は日本語では利用できません。[英語版](/{{currentpage.html}})をご覧下さい。
+
 ## プライベートピア
 
 `rippled`サーバーが「プライベート」サーバーとして動作するように設定し、そのIPアドレスを非公開にすることができます。これは、信頼できるバリデータなどの重要な`rippled`サーバーへのサービス拒否攻撃や侵入の試みに対する予防対策として有用です。ピアツーピアネットワークに参加するには、プライベートサーバーは1つ以上の非プライベートサーバーに接続するように設定されている必要があります。この非プライベートサーバーにより、メッセージがネットワークのその他の部分へ中継されます。

content/concepts/the-rippled-server/peer-protocol.md

@@ -11,11 +11,22 @@ The peer protocol is the main mode of communication between servers in the XRP L
 
 To establish a peer-to-peer connection, one server connects to another via HTTPS and requests an [HTTP upgrade](https://tools.ietf.org/html/rfc7230#section-6.7) to switch to RTXP. (For more information, see the [Overlay Network](https://github.com/ripple/rippled/blob/906ef761bab95f80b0a7e0cab3b4c594b226cf57/src/ripple/overlay/README.md#handshake) article in the [`rippled` repository](https://github.com/ripple/rippled).)
 
+## Peer Discovery
+
+The XRP Ledger uses a "gossip" protocol to help find servers find others to connect to in the XRP Ledger network. Whenever a server starts up, it connects to any other peers it was previous connected to. As a fallback, it uses the [hardcoded public hubs](https://github.com/ripple/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525). After a server successfully connects to any peers, it asks those peers for the contact information (generally, IP address and port) of other XRP Ledger servers that may also be seeking peers. The server can then connect to those servers, and ask them for the contact information of yet more XRP Ledger servers to peer with. Through this process, the server establishes enough peer connections that it can remain reliably connected to the rest of the network even if it loses a connection to any single peer.
+
+Typically, a server needs to connect to a public hub once and only for a short amount of time to find other peers. After doing so, the server may or may not remain connected to the hub, depending on how stable its network connection is, how busy the hub is, and how many other high-quality peers the server finds. The server saves the addresses of these other peers so it can try reconnecting directly to those peers later, after a network outage or a restart.
+
+For certain high-value servers (such as important [validators](rippled-server-modes.html#rippled-server-modes)) you may prefer not to have your server connect to untrusted peers through the peer discovery process. In this case, you can configure your server to use [private peers](#private-peers) only.
+
+
 ## Peer Protocol Port
 
 To participate in the XRP Ledger, `rippled` servers connect to arbitrary peers using the peer protocol. (All peers are treated as untrusted, unless they are [clustered](clustering.html) with the current server.)
 
-Ideally, the server should be able to send _and_ receive connections on the peer port. You should forward the port used for the peer protocol through your firewall to the `rippled` server. The [default `rippled` config file](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg) listens for incoming peer protocol connections on port 51235 on all network interfaces. You can change the port used by editing the appropriate stanza in your `rippled.cfg` file.
+Ideally, the server should be able to send _and_ receive connections on the peer port. You should [forward the port used for the peer protocol through your firewall](forward-ports-for-peering.html) to the `rippled` server.
+
+The [default `rippled` config file](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg) listens for incoming peer protocol connections on port 51235 on all network interfaces. You can change the port used by editing the appropriate stanza in your `rippled.cfg` file.
 
 Example:
 
@@ -28,21 +39,21 @@ protocol = peer
 
 The peer protocol port also serves the [special Peer Crawler API method](peer-crawler.html).
 
-### Node Key Pair
+## Node Key Pair
 
 When a server first starts up, it generates a _node key pair_ to use to identify itself in peer protocol communications. The server uses its key to sign all its peer protocol communications. This makes it possible to reliably identify and verify the integrity of messages from another server in the peer-to-peer network even if that server's messages are being relayed by untrusted peers.
 
 The node key pair is saved in the database and reused when the server restarts. If you delete the server's databases, it creates a new node key pair, effectively coming online with a different identity. To reuse the same key pair even if the databases are deleted, you can configure the server with a `[node_seed]` stanza. To generate a value suitable for use in the `[node_seed]` stanza, use the [validation_create method][].
 
-The node key pair also identifies other servers for purposes of [clustering](clustering.html) or [reserving peer slots](#fixed-and-reserved-peers). If you have a cluster of servers, you should configure each server in the cluster with a unique `[node_seed]` setting. For more information on setting up a cluster, see [Cluster `rippled` Servers](cluster-rippled-servers.html).
+The node key pair also identifies other servers for purposes of [clustering](clustering.html) or [reserving peer slots](#fixed-peers-and-peer-reservations). If you have a cluster of servers, you should configure each server in the cluster with a unique `[node_seed]` setting. For more information on setting up a cluster, see [Cluster `rippled` Servers](cluster-rippled-servers.html).
 
 
 ## Fixed Peers and Peer Reservations
 
 Normally, a `rippled` server attempts to maintain a healthy number of peers, and automatically connects to untrusted peers up to a maximum number. You can configure a `rippled` server to remain connected to specific peer servers in several ways:
 
-- Use **Fixed Peers** to remain always connected to specific other peers based on their IP addresses. This only works if the peers have fixed IP addresses. Use the `[ips_fixed]` config stanza to configure fixed peers. This is a necessary part of [clustering](clustering.html) or [private peers](#private-peers). Fixed peers are defined in the config file, so changes only apply after restarting the server.
+- Use **Fixed Peers** to remain always connected to specific other peers based on their IP addresses. This only works if the peers have fixed IP addresses. Use the `[ips_fixed]` config stanza to configure fixed peers. This is a necessary part of [clustering](clustering.html) or [private peers](#private-peers). Fixed peers are defined in the config file, so changes only apply after restarting the server. Fixed peers are most useful for keeping servers connected if those servers are run by the same person or organization.
-- Use **Peer Reservations** to prioritize specific peers. If your server has a peer reservation for a specific peer, then your server always accepts connection requests from that peer even if your server is already at its maximum number of connected peers. (This can cause your server to go _over_ the maximum number of peers.) You identify a reserved peer by its [node key pair](#node-key-pair), so you can do this even for peers with variable IP addresses. Peer reservations are configured through admin commands and saved in the server databases, so they can be adjusted while the server is online and are saved across restarts. [New in: rippled 1.4.0][]
+- Use **Peer Reservations** to prioritize specific peers. If your server has a peer reservation for a specific peer, then your server always accepts connection requests from that peer even if your server is already at its maximum number of connected peers. (This can cause your server to go _over_ the maximum number of peers.) You identify a reserved peer by its [node key pair](#node-key-pair), so you can do this even for peers with variable IP addresses. Peer reservations are configured through admin commands and saved in the server databases, so they can be adjusted while the server is online and are saved across restarts. Peer reservations are most useful for connecting servers operated by different people or organizations. [New in: rippled 1.4.0][]
 
 In the following cases, a `rippled` server does not connect to untrusted peers:
 
@@ -54,6 +65,8 @@ In the following cases, a `rippled` server does not connect to untrusted peers:
 
 You can configure a `rippled` server to act as a "private" server to keep its IP address hidden from the general public. This can be a useful precaution against denial of service attacks and intrusion attempts on important `rippled` servers such as trusted validators. To participate in the peer-to-peer network, a private server must be configured to connect to at least one non-private server, which relays its messages to the rest of the network.
 
+**Caution:** If you configure a private server without any [fixed peers](#fixed-peers-and-peer-reservations), the server cannot connect to the network, so it cannot know network state, broadcast transactions, or participate in the consensus process.
+
 Configuring a server as a private server has several effects:
 
 - The server does not make outgoing connections to other servers in the peer-to-peer network unless it has been explicitly configured to connect to those servers.
@@ -64,22 +77,65 @@ Configuring a server as a private server has several effects:
 
     **Caution:** It is possible to modify a server's source code so that it ignores this request and shares its immediate peers' IP addresses anyway. You should configure your private server to connect only to servers that you know are not modified in this way.
 
+### Pros and Cons of Peering Configurations
+
+To be part of the XRP Ledger, a `rippled` server must be connected to the rest of the open peer-to-peer network. Roughly speaking, there are three categories of configurations for how a `rippled` server connects to the network:
+
+- Using **discovered peers**. This is the default configuration, in which a server connects to any untrusted servers it finds and stays connected as long as those servers
+- As a **private server using proxies** run by the same person or organization. The proxies are stock `rippled` servers (also connected to discovered peers) that maintain a fixed peering connection with the private server.
+- As a **private server using public hubs**. This is similar to using proxies, but it relies on specific third parties.
+
+The pros and cons of each configuration are as follows:
+
+
+<table>
+<thead><tr>
+<th>Configuration</th> <th>Pros</th> <th>Cons</th>
+</tr></thead>
+<tbody>
+<tr><th>Discovered Peers</th>
+  <td><ul>
+    <li><p>Simplest configuration, with a low maintenance burden.</p></li>
+    <li><p>Creates the opportunity for a lot of direct peer connections. Having more direct peers comes with several benefits. Your server can <a href="ledger-history.html#fetching-history">fetch history</a> from multiple peers in parallel, both when syncing and when backfilling history. Since not all peers maintain full history, having access to more peers can also provide access to a wider selection of historical data.</p></li>
+    <li><p>Lowers the possibility of disconnecting from the network because your server can replace disconnected peers with new ones.</p></li>
+  </ul></td>
+  <td><ul>
+    <li><p>Doesn't allow you to select your server's peers, which means that you have no idea whether your peers may decide to act maliciously. Although `rippled` servers are designed to protect against malicious peers, there is always a risk that malicious peers could exploit software flaws to affect your server.</p></li>
+    <li><p>May connect you to peers that disconnect and change frequently, depending on whether you happen to connect to any reliable ones.</p></li>
+  </ul></td>
+</tr>
+<tr><th>Private Server Using Proxies</th>
+  <td><ul>
+    <li><p>Most secure and reliable configuration when implemented effectively.</p></li>
+    <li><p>As reliable and as redundant as you make it.</p></li>
+    <li><p>Can optimize the private server's performance with <a href="clustering.html">clustering</a>.</p></li>
+    <li><p>Enables you to create as many direct peer connections as you want. Being able to request content from more peers enables your server to parallelize the process of downloading the current ledger (when syncing) or backfilling history and gives it direct access to a wider selection of history.</p></li>
+  </ul></td>
+  <td><ul>
+    <li><p>Higher maintenance burden and cost from running multiple servers.</p></li>
+    <li><p>Does not completely eliminate the possibility of peer connection outages. No matter how many proxies you run, if they all exist on the same server rack, then one network or power outage can affect all of them.</p></li>
+  </ul></td>
+</tr>
+<tr><th>Private Server Using Public Hubs</th>
+  <td><ul>
+    <li><p>Low maintenance burden with a small amount of configuration.</p></li>
+    <li><p>Provides easy access to safe connections to the network.</p></li>
+    <li><p>Compared to connecting using proxies, may be less likely to cause your private server to disconnect from the network due to a simultaneous peer outage.</p></li>
+  </ul></td>
+  <td><ul>
+    <li><p>Depends on high-reputation third parties to remain reliable.</p></li>
+    <li>
+      <p>May cause your server to become disconnected from the network if the public hubs you rely on are too busy. Due to the nature of public hubs, they are the most popular and may not be able to keep a steady connection open to everyone.</p>
+      <p>To help avoid this issue, use more public hubs; the more the better. It can also help to use non-default hubs, which are less likely to be busy.</p>
+    </li>
+  </ul></td>
+</tr>
+</tbody>
+</table>
 
 ### Configuring a Private Server
 
-Use the `[peer_private]` stanza of the `rippled` config file to make your server act as a private peer. Use the `[ips_fixed]` to list servers you want your server to connect to. (If you enable `[peer_private]` without any addresses in `[ips_fixed]`, your server does not connect to the network.) As an additional precaution, use a firewall to block incoming connections from other servers.
+To configure your server as a private server, set the `[peer_private]` setting to `1` in the config file. For detailed instructions, see [Configure a Private Server](configure-a-private-server.html).
-
-Example configuration:
-
-```
-# Configuration on a private server that only connects through
-# a second rippled server at IP address 10.1.10.55
-[ips_fixed]
-10.1.10.55
-
-[peer_private]
-1
-```
 
 
 ## See Also

content/tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-validator.md

@@ -120,34 +120,18 @@ On your validator:
 
 This section describes three different configurations you can use to connect your validator to the XRP Ledger network. Use the configuration that best suits your use case.
 
-- [Discovered peers](#connect-using-discovered-peers)
+- [Discovered peers](#connect-using-discovered-peers): Connect to any servers in the peer-to-peer network.
 
-- [Proxies](#connect-using-proxies)
+- [Proxies](#connect-using-proxies): Run stock `rippled` servers as proxies between your validator and the rest of the peer-to-peer network.
 
-- [Public hubs](#connect-using-public-hubs)
+- [Public hubs](#connect-using-public-hubs): Connect only to specific public servers with a high reputation.
+
+For a comparison of these approaches, see [Pros and Cons of Peering Configurations](peer-protocol.html#pros-and-cons-of-peering-configurations).
 
 
 ### Connect using discovered peers
 
-This configuration connects your validator to the XRP Ledger network using discovered peers. This is the default behavior for `rippled` servers.
+This configuration connects your validator to the XRP Ledger network using [discovered peers](peer-protocol.html#peer-discovery). This is the default behavior for `rippled` servers.
-
-Specifically, it instructs your validator to connect to the [hardcoded public hubs](https://github.com/ripple/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525). Once connected, the public hub suggests other servers that might be looking for peers and provides your validator with contact information it can use to connect to them. Your validator can then connect to these servers and ask them for contact information for other servers until your validator has enough reliable peers that you don't have to worry about one or two of them suddenly dropping offline.
-
-Your validator needs to connect to the public hub once and only for a short amount of time to find other peers. After doing so, your server may or may not remain connected to the hub, depending on how stable your network connection is, how busy the hub is, and how many other high-quality peers your server finds. Your validator saves the addresses of these other peers so it can try reconnecting directly to those peers later, even if you restart your validator.
-
-**Pros:**
-
-  - Increases the chances of your validator finding a peer, probably several, to connect to.
-
-  - Creates the opportunity for a lot of direct peer connections. Having more direct peers comes with several benefits. Your validator can [fetch history](ledger-history.html#fetching-history) from multiple peers in parallel, both when syncing and when backfilling history. Since not all peers maintain full history, having access to more peers can also provide access to a wider selection of historical data.
-
-  - Lowers the possibility of your validator disconnecting from the network because it provides the ability to constantly replace disconnected peers with new ones.
-
-**Cons:**
-
-  - Doesn't allow you to select your validator's peers, which means that you have no idea whether your peers may decide to act maliciously. Your validator is designed to protect itself against malicious peers, but avoiding direct contact with unknown peers is the safest configuration possible.
-
-  - May connect you to peers that disconnect and change frequently, depending on whether you manage to connect to any reliable ones.
 
 _**To connect your validator to the XRP Ledger network using discovered peers,**_ omit the `[peer_private]` stanza or set it to `0` in your validator's `rippled.cfg` file. The [example rippled.cfg file](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg) is delivered with this configuration.
 
@@ -156,24 +140,6 @@ _**To connect your validator to the XRP Ledger network using discovered peers,**
 
 This configuration connects your validator to the network through stock `rippled` servers that you run yourself. These proxy servers sit between your validator and inbound and outbound network traffic.
 
-**Note:** While these servers are acting as proxies, they are not web proxies for HTTP(S) traffic.
-
-**Pros:**
-
-  - Guarantees that these servers will try to maintain a connection with your validator.
-
-  - Provides your validator with connections to the network that are as redundant and reliable as you make them.
-
-  - Enables you to trust your validator's peers.
-
-  - Enables you to create as many direct peer connections as you want. Being able to request content from more peers enables your validator to parallelize the process of downloading the current ledger (when syncing) or backfilling history and gives it direct access to a wider selection of history.
-
-**Cons:**
-
-  - While it does allow for high redundancy, doesn't eliminate the possibility of peer connection outages. No matter how many proxies you run, if they all exist on the same server rack, then one network or power outage means they can't deliver messages to and from your validator.
-
-    To mitigate this risk, you can use proxies in different geophysical locations.
-
 _**To connect your validator to the XRP Ledger network using proxies:**_
 
 1. Set up stock `rippled` servers. For more information, see [Install rippled](install-rippled.html).
@@ -205,20 +171,6 @@ _**To connect your validator to the XRP Ledger network using proxies:**_
 
 This configuration connects your validator to the network using two [public hubs](rippled-server-modes.html#public-hubs). This configuration is similar to [connecting using proxies you run yourself](#connect-using-proxies), but instead you connect through public hubs.
 
-**Pros:**
-
-  - Enables you to trust your validator's peers because you only connect to well-known servers with a high reputation.
-
-  - Provides easy access to safe connections to the network.
-
-  - Compared to [connecting using proxies](#connect-using-proxies), may be less likely to cause your validator to disconnect from the network due to a simultaneous peer outage.
-
-**Cons:**
-
-  - Uses the default (most popular) public hubs, so it's distinctly possible that a public hub may be too busy to provide your validator with a connection to the network. Assuming that you can solely rely on a default public hub to provide your validator with a connection to the network may not be the best idea.
-
-    To help avoid this issue, use more public hubs; the more the better. It can also help to use non-default hubs, which are less likely to be busy helping new servers find other peers.
-
 _**To connect your validator to the network using public hubs:**_
 
 1. In your validator's `rippled.cfg` file, include the following `[ips_fixed]` stanza. The two values, `r.ripple.com 51235` and `zaphod.alloy.ee 51235`, are default public hubs. This stanza tells `rippled` to always attempt to maintain peer connections with these public hubs.

content/tutorials/manage-the-rippled-server/configure-peering/configure-a-private-server.md

@@ -0,0 +1,90 @@
+# Configure a Private Server
+
+A [private server](peer-protocol.html#private-peers) is a `rippled` server that connects through the network only through specific, trusted peers instead of connecting directly to discovered peers in the open peer-to-peer network. This kind of configuration is an optional precaution most commonly recommended for [validators](run-rippled-as-a-validator.html), but it can be useful for other specific purposes.
+
+## Prerequisites
+
+To use a private server, you must meet the following requirements:
+
+- You must have [`rippled` installed](install-rippled.html) and updated to the latest version, but not running yet.
+- You must decide whether to connect through **proxies** you run yourself, or through **public hubs**. For a comparison of these options, see [Pros and Cons of Peering Configurations](peer-protocol.html#pros-and-cons-of-peering-configurations).
+    - If you are using proxies, you must have additional machines with `rippled` installed and running to use as the proxies. These servers must be able to connect to the outside network and to your private server.
+    - For either configuration, you must know the IP addresses and ports of the peers you intend to connect to.
+
+## Steps
+
+To set up a specific server as a private peer, complete the following steps:
+
+1. Edit your `rippled`'s config file.
+
+        vim /etc/opt/ripple/rippled.cfg
+
+    {% include '_snippets/conf-file-location.md' %}<!--_ -->
+
+2. Enable private peering.
+
+    Add or uncomment the following stanza in your config file:
+
+        [peer_private]
+        1
+
+3. Add fixed peers.
+
+    Add or uncomment an `[ips_fixed]` stanza in your config file. Each line in this stanza should be the hostname or IP address of a peer to connect to, followed by a space and the port where this peer accepts peer protocol connections.
+
+    For example, to connect using **public hubs**, you could use the following stanza:
+
+        [ips_fixed]
+        r.ripple.com 51235
+        zaphod.alloy.ee 51235
+
+    If you are connecting using **proxies**, the IP addresses and ports should match the configurations of the `rippled` servers you are using as proxies. For each of those servers, the port number should match the `protocol = peer` port in that server's config file (usually 51235). For example, your configuration might look like this:
+
+          [ips_fixed]
+          192.168.0.1 51235
+          192.168.0.2 51235
+
+4. If using proxies, cluster them with your private peer and each other.
+
+    If you are using public hubs, skip this step.
+
+    If you are using proxies, [configure the proxies as a cluster](cluster-rippled-servers.html) that includes your private peer. Each member of the cluster should have an `[ips_fixed]` stanza that lists each _other_ member of the cluster. However, **only the private server** should have a `[peer_private]` stanza.
+
+    Restart `rippled` on the proxies one-by-one. On each proxy server:
+
+        sudo service systemctl restart rippled
+
+5. Start `rippled` on the private server.
+
+        sudo service systemctl start rippled
+
+6. Use the [peers method][] to confirm that your private server is connected _only_ to its peers.
+
+    The `peers` array in the response should not contain any objects whose `address` is not one of your configured peers. If this is not the case, double-check your config file and restart the private server.
+
+
+## Next Steps
+
+As an additional precaution, you should configure your firewall to block incoming connections to your private server from servers that are not your specific peers. If you are running proxy servers, [forward peer ports](forward-ports-for-peering.html) through your firewall to the proxies, but **not** to the private peer. The exact details of how to configure this depend on what firewall you use.
+
+Be sure the firewall **does not block** outgoing HTTP connections on port 80. The default configuration uses this to download the latest recommended validator list from **vl.ripple.com**. Without a validator list, the server does not know which validators to trust and cannot recognize when the network reaches a consensus.
+
+## See Also
+
+- **Concepts:**
+    - [Peer Protocol](peer-protocol.html)
+    - [Consensus](consensus.html)
+    - [Parallel Networks](parallel-networks.html)
+- **Tutorials:**
+    - [Configure the Peer Crawler](configure-the-peer-crawler.html)
+- **References:**
+    - [peers method][]
+    - [connect method][]
+    - [fetch_info method][]
+    - [Peer Crawler](peer-crawler.html)
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}

content/tutorials/manage-the-rippled-server/configure-peering/forward-ports-for-peering.md

@@ -41,7 +41,17 @@ For other software and hardware firewalls, see the manufacturer's official docum
 
 ## See Also
 
-***TODO***
+- **Concepts:**
+    - [Peer Protocol](peer-protocol.html)
+    - [The `rippled` Server](the-rippled-server.html)
+- **Tutorials:**
+    - [Capacity Planning](capacity-planning.html)
+    - [Troubleshoot the `rippled` Server](troubleshoot-the-rippled-server.html)
+- **References:**
+    - [connect method][]
+    - [peers method][]
+    - [print method][]
+    - [server_info method][]
 
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}

content/tutorials/manage-the-rippled-server/configure-peering/manually-connect-to-a-specific-peer.md

@@ -54,7 +54,17 @@ rippled connect 169.54.2.151 51235
 
 ## See Also
 
-***TODO***
+- **Concepts:**
+    - [Peer Protocol](peer-protocol.html)
+    - [The `rippled` Server](the-rippled-server.html)
+- **Tutorials:**
+    - [Capacity Planning](capacity-planning.html)
+    - [Troubleshoot the `rippled` Server](troubleshoot-the-rippled-server.html)
+- **References:**
+    - [connect method][]
+    - [peers method][]
+    - [print method][]
+    - [server_info method][]
 
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}

content/tutorials/manage-the-rippled-server/configure-peering/set-max-number-of-peers.md

@@ -2,7 +2,7 @@
 
 The `rippled` server has a configurable soft maximum number of [peers](peer-protocol.html) to connect to. The default maximum number of peers is **21**.
 
-**Note:** Internally, the server generates approximate quotas of incoming and outgoing peers. You can potentially go over the soft maximum if you are using [fixed peers, peer reservations](peer-protocol.html#fixed-and-reserved-peers), or if you manually connect to additional peers using the [connect method][].
+**Note:** Internally, the server generates approximate quotas of incoming and outgoing peers. You can potentially go over the soft maximum if you are using [fixed peers, peer reservations](peer-protocol.html#fixed-peers-and-peer-reservations), or if you manually connect to additional peers using the [connect method][].
 
 To change the maximum number of peers your server allows, complete the following steps:
 

content/tutorials/manage-the-rippled-server/configure-peering/use-a-peer-reservation.md

@@ -17,7 +17,7 @@ To use a peer reservation, complete the following steps:
 
 ### 1. Set up a permanent node key pair
 
-If you have already configured your server with a permanent node key pair value, you can skip ahead to [step 2: Communicate your node public key to the peer's admin](2-communicate-your-node-public-key-to-the-peers-admin). (For example, setting up a permanent node key pair for each server is part of the process of [setting up a server cluster](cluster-rippled-servers.html).)
+If you have already configured your server with a permanent node key pair value, you can skip ahead to [step 2: Communicate your node public key to the peer's admin](#2-communicate-your-node-public-key-to-the-peers-admin). (For example, setting up a permanent node key pair for each server is part of the process of [setting up a server cluster](cluster-rippled-servers.html).)
 
 **Tip:** Setting up a permanent node key pair is optional, but makes it easier to keep the peer reservation set up if you need to erase its databases or move to a new machine. If you don't want to set up a permanent node key pair, you can use your server's automatically-generated node public key as reported in the `pubkey_node` field of the [server_info method][] response.
 
@@ -145,6 +145,7 @@ As the administrator, you can manage the reservations your server has for other
 ## See Also
 
 - **Concepts:**
+    - [Peer Protocol](peer-protocol.html)
     - [Consensus](consensus.html)
     - [Parallel Networks](parallel-networks.html)
 - **Tutorials:**

dactyl-config.yml

@@ -272,6 +272,9 @@ targets:
             "use-payment-channels.html#9-when-the-payer-and-payee-are-done-doing-business-the-payer-requests-for-the-channel-to-be-closed": "use-payment-channels.html#9-支払人と受取人の取引完了後支払人はchannelの閉鎖を要求します"
             # Fix 1 link from untranslated accountdelete.html. REMOVE when accounts.html is updated w/ deletable accounts info.
             "accounts.html#deletion-of-accounts": "accounts.html#アカウントの永続性"
+            # Fix links from untranslated peer protocol updates
+            "peer-protocol.html#node-key-pair": "peer-protocol.html#ノードキーペア"
+            "run-rippled-as-a-validator.html#connect-using-proxies": "run-rippled-as-a-validator.html#プロキシを使用した接続"
 
 
     -   name: xrp-api-only
@@ -2502,13 +2505,13 @@ pages:
         targets:
             - ja
 
-    -   md: tutorials/manage-the-rippled-server/configure-peering/use-a-peer-reservation.md
+    -   md: tutorials/manage-the-rippled-server/configure-peering/configure-a-private-server.md
-        html: use-a-peer-reservation.html
+        html: configure-a-private-server.html
         funnel: Docs
         doc_type: Tutorials
         category: Manage the rippled Server
-        subcategory: Configure Peering
+        subcategory: Configure Peering #TODO:translate
-        blurb: Configure how much information your rippled server reports publicly about its status and peers. #TODO:translate
+        blurb: Set up a server to connect only to specific, trusted peers. #TODO:translate
         targets:
             - en
             - ja
@@ -2557,6 +2560,17 @@ pages:
             - en
             - ja
 
+    -   md: tutorials/manage-the-rippled-server/configure-peering/use-a-peer-reservation.md
+        html: use-a-peer-reservation.html
+        funnel: Docs
+        doc_type: Tutorials
+        category: Manage the rippled Server
+        subcategory: Configure Peering
+        blurb: Set up a more reliable connection to a specific peer using a peer reservation. #TODO:translate
+        targets:
+            - en
+            - ja
+
     -   name: Test rippled Functionality in Stand-Alone Mode
         html: use-stand-alone-mode.html
         funnel: Docs