# Networking Overview

DanubeData provides comprehensive networking features to secure and optimize connectivity for your cloud resources. This guide covers networking concepts, features, and best practices.

## Overview

DanubeData networking includes:

- **Public Networking**: Internet-accessible resources with public IP addresses
- **Private Networking**: Secure communication between resources
- **Firewalls**: Fine-grained access control and security
- **Load Balancers** (coming soon): Distribute traffic across multiple instances
- **DNS Management**: Manage DNS records for your resources

## Network Architecture

### Public Network

All resources receive public IP addresses by default:

- **IPv4**: Public IPv4 address for internet access
- **IPv6**: IPv6 address for modern connectivity
- **Bandwidth**: Generous bandwidth allocation per instance
- **Global Accessibility**: Resources accessible from anywhere

### Internal (Team) Network

Resources in the same team share a Kubernetes namespace and can communicate internally without traversing the public internet:

- **Shared namespace**: every team has a private namespace; all of your VPS instances, databases, caches, and queues live inside it
- **Internal DNS**: short hostnames like `redis-mycache` resolve from any VPS in the team
- **Free internal traffic**: east-west traffic between resources in the same team does not count against VPS bandwidth
- **Cluster-level enforcement**: firewall rules apply to internal traffic too — see [Firewalls](https://docs.danubedata.ro/networking-firewalls)
- **Cross-team connectivity**: use [Network Peering](https://docs.danubedata.ro/networking-peering) to connect two of your own teams (e.g. staging ↔ production)

### Private Networks (beta)

Beyond the team's shared namespace, you can also create dedicated VXLAN-backed L2 segments with your own CIDR blocks (RFC1918) and attach VPS instances to them as additional NICs — no reboot required. Each network is fully isolated from the public internet and from other tenants. See [Private Networks](https://docs.danubedata.ro/networking-private) for the full guide.

## IP Addressing

### Public IP Addresses

Each resource receives:

**IPv4**:
- Unique public IPv4 address
- Static assignment
- Included at no additional cost
- Accessible from internet

**IPv6**:
- /128 IPv6 address
- Static assignment
- Modern protocol support
- Included at no additional cost

### Internal Cluster Addresses

For internal team communication:

- Each resource has a cluster-internal address from the `10.x.x.x` range
- Persistent across the resource's lifecycle
- Used for VPS-to-database, VPS-to-cache, and VPS-to-VPS traffic in the same team
- Not routable on the public internet
- For databases, caches, and queues, prefer the internal DNS hostname over the IP — IPs may change after a node reschedule

## Network Features

### Bandwidth Allocation

Every VPS adds **20 TB/month** of included outbound (egress) traffic to your team's pooled quota:

- **Pooled**: included egress is shared across all VPS instances in the team
- **Overage**: €1.00/TB for traffic beyond the pooled quota
- **Monitoring**: Track usage in dashboard
- **No Internal Charges**: private-network traffic is free and never counts against the quota

### Network Performance

- **Latency**: < 1ms within same datacenter
- **Throughput**: Up to 1 Gbps
- **DDoS Protection**: Built-in protection against attacks

## Connecting Resources

### Within the Same Team

Resources that belong to the same team share a Kubernetes namespace and can communicate via:

1. **Internal DNS** (recommended): use short hostnames like `db-orders` or `redis-cache` from any VPS in the team
2. **Internal IP**: use the cluster `10.x.x.x` address shown on the [Networking page](https://docs.danubedata.ro/networking-overview)
3. **Public network**: using the public IP — works, but counts against bandwidth and is unnecessary for same-team traffic

**Benefits of internal traffic**:
- Free bandwidth (does not count against VPS allowance)
- Lower latency (no public-internet hop)
- Not exposed to the public internet
- Firewall still applies — restrict with rules that reference other instances directly

### Across Two of Your Own Teams

Use [Network Peering](https://docs.danubedata.ro/networking-peering) to connect two teams you own (e.g. staging ↔ production). Once peered, resources in either namespace can reach each other over the cluster network.

### Across Different Data Centers

Resources in different datacenters communicate over the public internet:

- Higher latency (50–200 ms typical)
- Bandwidth charges apply
- Consider a VPN if you need encrypted transport beyond TLS

### Exposing Managed Services to the Internet

Managed databases, caches, and queues are **private by default** — reachable only from resources inside your team's network. To connect from outside (your laptop, an external application, an IoT device), **enable public access (external DNS)** on the instance:

- The instance gets a public hostname you can connect to from anywhere
- Its firewall opens automatically the moment you enable public access — there's no separate rule to add — and closes again as soon as you turn it back off
- **Queues** additionally speak MQTT, MQTTS, STOMP, and STOMPS once external DNS is on, each on its own dedicated port — see [Connecting via MQTT & STOMP](https://docs.danubedata.ro/queue-mqtt-stomp)

Lock external access down to trusted networks with an inbound [firewall rule](https://docs.danubedata.ro/networking-firewalls).

## Firewalls

Control network access with firewall rules:

- **Inbound Rules**: Control incoming traffic
- **Outbound Rules**: Control outgoing traffic
- **Protocol Support**: TCP, UDP, ICMP
- **Port Ranges**: Specific ports or ranges
- **Source/Destination**: IP addresses or CIDR blocks

**Learn More**: [Firewalls Documentation](https://docs.danubedata.ro/networking-firewalls)

## Load Balancers (coming soon)

Load balancers will distribute traffic across multiple instances:

- **HTTP/HTTPS**: Layer 7 load balancing
- **TCP**: Layer 4 load balancing
- **SSL Termination**: Handle TLS at load balancer
- **Health Checks**: Automatic unhealthy instance removal
- **Sticky Sessions**: Session affinity support


## DNS Management

Manage DNS records for your resources:

- **A Records**: IPv4 address mapping
- **AAAA Records**: IPv6 address mapping
- **CNAME Records**: Domain aliasing
- **MX Records**: Mail server configuration
- **TXT Records**: Verification and SPF records

Access DNS management via **Networking** > **DNS**.

## Security Best Practices

### Network Segmentation

- Use private networks for internal communication
- Isolate different applications or environments
- Limit public exposure to necessary services only
- Use firewalls for fine-grained control

### Access Control

- Restrict SSH access to specific IP addresses
- Use firewalls for all publicly accessible resources
- Implement least privilege principle
- Regularly review and update firewall rules

### Monitoring

- Monitor bandwidth usage
- Track unusual traffic patterns
- Set up alerts for suspicious activity
- Review firewall logs regularly

## Cost Optimization

### Bandwidth Management

- Use private networks for internal traffic (free)
- Monitor bandwidth usage regularly
- Optimize data transfer patterns
- Cache static content
- Compress data when possible

### Network Design

- Co-locate resources in same datacenter when possible
- Use private networks to reduce bandwidth costs
- Implement caching strategies
- Consider CDN for static content

## Troubleshooting

### Connectivity Issues

**Cannot connect to resource**:

1. Check firewall rules allow your IP
2. Verify resource is running
3. Test with different network/IP
4. Check DNS resolution
5. Verify credentials

**High latency**:

1. Check geographic distance
2. Run traceroute to identify bottleneck
3. Verify network congestion
4. Consider using closer datacenter
5. Use private network if same datacenter

**Bandwidth exceeded**:

1. Review bandwidth usage in dashboard
2. Identify high-bandwidth resources
3. Optimize data transfer
4. Consider upgrading instances
5. Use private network more effectively

## Related Documentation

- [Firewalls](https://docs.danubedata.ro/networking-firewalls)
- [Network Peering](https://docs.danubedata.ro/networking-peering)
- [Private Networks](https://docs.danubedata.ro/networking-private)
- [Platform Security](https://docs.danubedata.ro/platform-security)
- [VPS Overview](https://docs.danubedata.ro/vps-overview)