The XRPL uses a gossip-based P2P network:

Network Structure:

┌─────────┐     ┌─────────┐     ┌─────────┐
│ Validator│────│  Peer   │────│ Validator│
│    A    │    │ Server  │    │    B    │
└────┬────┘     └────┬────┘     └────┬────┘
     │               │               │
     │          ┌────┴────┐          │
     └──────────│  Hub    │──────────┘
                │ Server  │
                └────┬────┘
                     │
              ┌──────┴──────┐
              │   More      │
              │   Peers     │
              └─────────────┘

- Each node tells its peers
- Peers tell their peers
- Exponential propagation
- Redundant paths ensure delivery

Peer Categories:

1. Discovered Peers

1. Fixed Peers (ips_fixed)

1. Public Hubs

Inbound vs. Outbound Connections:

- Your server connects to peer
- You choose which peers
- Limited by your configuration
- More control

- Other servers connect to you
- Requires accessible port 51235
- Builds network connectivity
- Helps network health

- 10+ outbound connections
- 10+ inbound connections
- Diverse peer set

---

Default behavior—let rippled find peers:

# rippled.cfg - Default peer discovery
# No special configuration needed
# rippled finds peers automatically

# Server connects to hardcoded bootstrap nodes
# Discovers additional peers via peer exchange
# Maintains target peer count automatically

Pros and Cons:

Automatic Discovery:

Pros:
+ No configuration needed
+ Adapts to network changes
+ Finds geographically close peers
+ Self-healing if peers disappear

- Less control over peer selection
- May connect to low-quality peers
- Geographic distribution uncertain
- No guaranteed connections

Explicitly configure persistent peer connections:

# rippled.cfg - Fixed peers
[ips_fixed]
r.ripple.com 51235
s1.ripple.com 51235
s2.ripple.com 51235

# These connections are maintained persistently
# rippled will reconnect if disconnected
# Combines with discovered peers

When to Use Fixed Peers:

Fixed Peers Recommended For:

1. Validators (primary use case)

1. Restricted Networks

1. Performance Requirements

Hide your validator's address from peer exchange:

# rippled.cfg - Private mode
[peer_private]
1

# Effects:
# - Your address not shared with other peers
# - Inbound connections still work (if port open)
# - Must use fixed peers for reliable connectivity
# - Adds layer of obscurity

Private Mode Considerations:

When Private Mode Makes Sense:

✓ Running behind proxy servers
✓ Multiple servers sharing identity
✓ Enhanced privacy requirements
✓ Combined with fixed peer strategy

When to Avoid:

✗ Relying on peer discovery
✗ Want maximum connectivity
✗ No fixed peer strategy
✗ Network contribution priority

---

For most validators, a hybrid approach works best:

# rippled.cfg - Recommended validator peer config

# Enable automatic discovery (default)
# Plus configure fixed peers for reliability

[ips_fixed]
# Ripple's public hubs (reliable, well-connected)
r.ripple.com 51235
s1.ripple.com 51235
s2.ripple.com 51235

# XRPLF infrastructure
xrplcluster.com 51235

# Geographic diversity (add based on your location)
# Europe: eu.ripple.com 51235
# Asia: asia.ripple.com 51235

# Peer privacy (optional)
# [peer_private]
# 0

Good Fixed Peer Characteristics:

1. Reliability

1. Connectivity

1. Geographic Relevance

1. Trust

Well-known public hubs (as of course creation):

• r.ripple.com:51235

• s1.ripple.com:51235

• s2.ripple.com:51235

• xrplcluster.com:51235

• Various community operators

• Check XRPL Discord for current list

• Verify before adding to config

Note: Hub availability changes over time
Verify any hub is operational before relying on it

---

Understanding Peer Output:

Key Fields:

• IP and port

• Shows where peer is located

• Lower is better

• < 100ms excellent

• < 200ms good

• 500ms concerning

• Should be current

• Old ranges suggest sync issues

• "full" = good

• Other states = potentially issues

• Higher = more stable

• Low uptimes = connection churn

• "sane" = normal operation

• Other values = potential issues

• Current version preferred

• Very old versions concerning

#!/bin/bash
#===============================================================================
# Peer Connectivity Analysis
# Analyze validator peer connections
#===============================================================================

echo "=============================================="
echo "Peer Analysis - $(date)"
echo "=============================================="

Get peer data

PEERS=$(/opt/ripple/bin/rippled peers 2>/dev/null)

if [ $? -ne 0 ]; then
echo "ERROR: Cannot connect to rippled"
exit 1
fi

Count peers

TOTAL=$(echo "$PEERS" | grep -c '"address"')
echo "Total Peers: $TOTAL"

Count by status

FULL=$(echo "$PEERS" | grep -c '"status" : "full"')
echo "Fully Synced: $FULL"

Analyze latency

echo ""
echo "--- Latency Distribution ---"
echo "$PEERS" | grep -o '"latency" : [0-9]*' | awk '{print $3}' |
while read lat; do
if [ "$lat" -lt 50 ]; then
echo " <50ms: Excellent"
elif [ "$lat" -lt 100 ]; then
echo " <100ms: Good"
elif [ "$lat" -lt 200 ]; then
echo " <200ms: Acceptable"
else
echo " >200ms: High ($lat ms)"
fi
done | sort | uniq -c

Check for version diversity

echo ""
echo "--- Version Distribution ---"
echo "$PEERS" | grep -o '"version" : "[^"]*"' | cut -d'"' -f4 | sort | uniq -c

Connection age analysis

echo ""
echo "--- Connection Stability ---"
LONG_CONN=$(echo "$PEERS" | grep -o '"uptime" : [0-9]*' | awk '$3 > 3600 {count++} END {print count+0}')
echo "Connections > 1 hour: $LONG_CONN"

Geographic diversity (basic IP analysis)

echo ""
echo "--- IP Distribution (first octet) ---"
echo "$PEERS" | grep -o '"address" : "[0-9]*.' | cut -d'"' -f4 | sort | uniq -c | head -10

echo ""
echo "=============================================="
```

Common Connectivity Problems:

- Firewall blocking port 51235
- NAT not configured properly
- Network restrictions
- ISP blocking P2P traffic

- Geographic isolation
- Poor network path
- Consider closer fixed peers

- Network instability
- Server resource issues
- Peers having problems

- Limited peer diversity
- May be connecting to same infrastructure
- Add diverse fixed peers

---

Optimize for Your Location:

- Ripple's US infrastructure: good latency
- Add European peers for diversity
- Consider Asian peers for coverage

- European hubs if available
- US hubs still reasonable latency
- Asian peers for diversity

- Asian hubs preferred
- Consider Singapore, Tokyo infrastructure
- US/EU for diversity

Goal: Mix of low-latency and diverse peers

# Test latency to potential fixed peers
ping -c 5 r.ripple.com
ping -c 5 s1.ripple.com

Test TCP connectivity

nc -zv r.ripple.com 51235

More detailed path analysis

traceroute r.ripple.com

MTR for ongoing path quality

mtr r.ripple.com
```

# rippled.cfg - Connection limits

Maximum peer connections (default usually fine)

[peers_max]

21

Considerations:

- More peers = more bandwidth, more CPU

- Diminishing returns past ~30

- Default (21) usually optimal

- Increase only if experiencing issues

For validators behind corporate firewalls:

# rippled.cfg - SOCKS proxy (if needed)
# [proxy]
# socks5://127.0.0.1:1080

# Use case:
# - Corporate firewall restrictions
# - Network policy requirements
# - Additional network layer

# Note: Adds latency, complexity
# Only use if required by network policy

For operators running multiple servers:

# rippled.cfg - Cluster configuration
# [cluster_nodes]
# nHUXXXXXXXXXXXXX
# nHUYYYYYYYYYYYYY

# Use case:
# - Multiple servers in same organization
# - Load balancing
# - Redundancy configurations

# Note: Advanced configuration
# See XRPL documentation for details

Control connections per IP address:

# rippled.cfg - Per-IP limits
# [overlay]
# ip_limit = 2

# Prevents single IP from consuming
# too many connection slots
# Default usually appropriate

# Verify rippled is running
systemctl status rippled

Check if peer port is listening

ss -tlnp | grep 51235

Should show rippled listening on 0.0.0.0:51235

Check firewall

sudo ufw status | grep 51235

Should show ALLOW for 51235

External port test (from another machine)

nc -zv YOUR_SERVER_IP 51235

Check if NAT is configured (if behind router)

Ensure port 51235 forwarded to server

# Check if peer_private is enabled
grep -i "peer_private" /opt/ripple/etc/rippled.cfg

If peer_private=1, ensure fixed peers configured

grep -A10 "ips_fixed" /opt/ripple/etc/rippled.cfg

Check for network-level filtering

Some ISPs filter P2P traffic

Try different time of day

Contact ISP if persistent

Check server resources

free -h
df -h

Resource pressure can cause disconnections

# Test general network latency
ping 8.8.8.8

Test rippled peer endpoints

ping r.ripple.com

If general latency high:

- Network infrastructure issue

- ISP problems

- Server location suboptimal

If only rippled latency high:

- May need closer fixed peers

- Check for network restrictions on port 51235

# Check logs for disconnect reasons
sudo grep -i "disconnect" /var/log/rippled/debug.log | tail -30

Check resource usage during disconnects

May correlate with resource pressure

Common causes:

- Memory pressure (swap usage)

- CPU spikes

- Network instability

- Peer-side issues

Initial Connectivity Setup:

1. Start with defaults (automatic discovery)
2. Verify 10+ peers connecting
3. Add fixed peers for reliability:
4. Monitor for 24-48 hours
5. Adjust based on observed connectivity

Regular Connectivity Checks:

- Verify peer count (10+)
- Check for low-latency peers
- Review any disconnection spikes

- Full peer analysis
- Latency distribution check
- Version diversity check

- Fixed peer health verification
- Consider adding/removing fixed peers
- Network path analysis

Document Your Network Configuration:

1. Fixed Peers:

1. Network Topology:

1. Known Limitations:

1. Baseline Metrics:

---

✅ Peer count directly affects validator effectiveness - Low peer count correlates with delayed message propagation and lower agreement percentages

✅ Fixed peers improve reliability - Configured persistent connections provide stable foundation for validator communication

✅ Geographic diversity matters - Peers in multiple regions provide path redundancy and faster propagation across the network

✅ Automatic discovery works for most scenarios - Default peer discovery is sufficient for basic operation; fixed peers enhance reliability

⚠️ Optimal fixed peer count - Depends on network quality, location, and specific connectivity challenges

⚠️ Best public hubs for your location - Changes over time; requires testing and monitoring

⚠️ Impact of private mode - Reduces discoverability but actual impact on validator effectiveness varies

📌 No fixed peers for validators - Relying entirely on discovery can lead to suboptimal peer selection

📌 Too many fixed peers - Excessive fixed connections may crowd out discovered peers and reduce diversity

📌 Ignoring latency metrics - High-latency connections can cause validation messages to arrive late

📌 No connectivity monitoring - Silent degradation of peer quality affects validator performance

Most validators will operate fine with default peer discovery plus 3-5 fixed connections to well-known hubs. The complexity described in this lesson is for diagnosing problems when they occur, not for daily operation.

If your peer count is 10+, latencies are reasonable (<200ms typical), and your agreement percentage is high (>99%), your connectivity is probably fine. Optimize only if metrics indicate problems.

Assignment: Analyze and optimize your validator's network connectivity.

Requirements:

• Run peer analysis script

• Document current peer count

• Analyze latency distribution

• Identify any connectivity concerns

• Select 3-5 fixed peers with rationale

• Test latency to each selected peer

• Implement in rippled.cfg

• Verify connections after restart

• Document your network path

• Note any firewalls, NAT, restrictions

• Record baseline peer metrics

• Create connectivity monitoring procedure

• Before/after peer count comparison

• Latency improvement (if applicable)

• 24-hour stability confirmation

• Any remaining concerns noted

• PDF or Markdown document

• Peer analysis outputs

• Configuration snippets

• Latency test results

• Comprehensive current state analysis (30%)

• Thoughtful fixed peer selection (30%)

• Complete network documentation (25%)

• Measurable optimization results (15%)

Time investment: 2-3 hours
Value: Optimized, documented network configuration

1. Peer Count Threshold (Tests Operational Knowledge):

What is the recommended minimum peer count for a validator to operate reliably?

A) 3 peers
B) 5 peers
C) 10 peers
D) 25 peers

Correct Answer: C
Explanation: 10 peers is the generally recommended minimum for reliable validator operation. Below this threshold, validation message propagation may be unreliable. While 5 might work in ideal conditions, 10+ provides redundancy against individual peer failures and ensures diverse network paths for message propagation.

2. Fixed Peers Purpose (Tests Technical Understanding):

What is the primary benefit of configuring fixed peers for a validator?

A) Fixed peers are faster than discovered peers
B) Fixed peers provide persistent, reliable connections regardless of peer discovery
C) Fixed peers are required for UNL inclusion
D) Fixed peers reduce bandwidth usage

Correct Answer: B
Explanation: Fixed peers ensure your validator maintains connections to known, reliable nodes regardless of what peer discovery finds. If automatic discovery fails or finds poor-quality peers, fixed peers provide a baseline of reliable connectivity. This is especially important for validators where consistent connectivity affects reputation.

3. Latency Impact (Tests Performance Understanding):

A validator has 15 peers, but all have latency over 400ms. What is the likely impact?

A) No impact—peer count is what matters
B) Validation messages may arrive late, potentially lowering agreement percentage
C) The validator will be automatically removed from UNLs
D) Higher latency improves message security

Correct Answer: B
Explanation: High latency to all peers means validation messages take longer to propagate. By the time your vote reaches other validators, consensus may have already progressed. This can lower your agreement percentage as your votes aren't counted in time. Consider adding geographically closer fixed peers to improve latency.

4. Peer Analysis (Tests Diagnostic Skills):

When analyzing peers, you notice most connections have uptimes under 5 minutes. What does this suggest?

A) Normal operation—peers rotate frequently
B) Connection instability; investigate network issues or resource pressure
C) Your server is rejecting long connections
D) Other validators are restarting frequently

Correct Answer: B
Explanation: Very short uptimes across many peers suggests connection instability. Peers shouldn't be disconnecting and reconnecting every few minutes. Common causes include: network instability, server resource pressure (memory/CPU), firewall issues, or ISP-level problems. Investigate your server's resource usage and network path.

5. Private Mode (Tests Configuration Knowledge):

When should a validator enable [peer_private] = 1?

A) Always—validators should be private
B) When running behind proxy servers or requiring enhanced privacy, combined with fixed peer configuration
C) When peer count is too high
D) Never—it prevents validation from working

Correct Answer: B
Explanation: Private mode prevents your address from being shared via peer exchange. It's appropriate when running behind proxies, when privacy is important, or as part of a specific network architecture. However, it must be combined with fixed peers since discovered peers won't learn about you. It doesn't prevent validation but does change how peers find you.

For Next Lesson:
With network connectivity optimized, Lesson 10 will cover advanced security hardening—additional security layers specifically for validators, including intrusion detection, advanced firewall rules, and security monitoring. We'll build defense-in-depth for your validator infrastructure.

End of Lesson 9

Total words: ~5,200
Estimated completion time: 50 minutes reading + 2-3 hours for analysis and optimization