Skip to content

vRack - Service Presentation#9369

Draft
SlimJ4 wants to merge 2 commits into
developfrom
sa-vrack-global
Draft

vRack - Service Presentation#9369
SlimJ4 wants to merge 2 commits into
developfrom
sa-vrack-global

Conversation

@SlimJ4
Copy link
Copy Markdown
Contributor

@SlimJ4 SlimJ4 commented May 6, 2026

What type of Pull Request is this?

  • New guide(s)

Description

Introduces a new guide presenting the vRack service and its possible interactions and use cases.

Mandatory information

The translations in this Pull Request have been done using:

  • OVHcloud integrated translation LLM
  • Systran
  • Other tool : Claude
  • This Pull Request didn't require any translation.
  • This Pull Request can be merged as soon as possible.

@SlimJ4 SlimJ4 added Guide creation The Pull Request contains at least 1 new guide (meta.yaml and index edition needed) Offer: Network The PR documents Network products: Additional IP, BYOIP, Load Balancer, vRack, OCC, etc labels May 6, 2026
@SlimJ4 SlimJ4 requested a review from jslocinski May 6, 2026 12:26
| **Cross-region reach** | A single vRack spans all OVHcloud regions — services in different regions communicate as if on the same LAN |
| **VLAN transparency** | The vRack transparently carries 802.1Q-tagged traffic, supporting up to 4,000 VLANs (IDs 1–4094). VLANs are configured on each endpoint (server OS, vSphere, OpenStack), not on the vRack itself. |
| **Jumbo Frame support** | The vRack backbone transports frames with up to 9,000 bytes of payload (MTU 9000). Jumbo Frames must be configured on each endpoint's network interface — the vRack does not enforce or manage MTU. |
| **IPv4 and IPv6** | Additional IP blocks (IPv4 and IPv6) can be added to the vRack so that traffic for those blocks is carried over the private backbone instead of the public internet. IPv6 blocks additionally involve L3 functions (gateway, SLAAC, routed subnets) managed at the infrastructure level. |
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is different what's writen elsewhere - must be aligned
Additional IP can be routed into vRack in selected region to leverage vRack flexibility for public connectivity. There are additional public bandwidth options available for this traffic.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can mention that internet gateway is created in the region of selection

```svg
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 820 420" font-family="Arial, sans-serif" font-size="11">
<rect width="820" height="420" fill="#f8f9fa" rx="8"/>
A vRack is a free, logical container identified by a service name (e.g. `pn-12345`). You order one via the Control Panel or API, then attach eligible services to it. Every service in the same vRack shares the same Layer 2 domain. At the vRack level you manage membership (which services are attached) and, for Additional IPv6 blocks, gateway and SLAAC settings. All other traffic-level configuration (IPv4 addressing, VLANs, MTU) is done on the endpoints.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

next-hop and slaac are rather internet gateway features linked to additional ip routing into vRack. Let's clearify this

<rect x="20" y="165" width="180" height="55" rx="6" fill="#fff3e0" stroke="#e65100" stroke-width="1.5"/>
<text x="110" y="190" text-anchor="middle" font-weight="bold" fill="#e65100">OVHcloud Connect</text>
<text x="110" y="205" text-anchor="middle" fill="#555" font-size="9">On-premises · AWS · Azure · GCP</text>
The vRack is a Layer 2 service with no awareness of IP. You are responsible for assigning private IP addresses on each endpoint. Any RFC 1918 range works (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`). OVHcloud Additional IP blocks can also be added to the vRack so their traffic is carried over the private backbone instead of the public internet.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additional IP case should be aligned among the whole file.. can be confusing

<line x1="200" y1="335" x2="280" y2="250" stroke="#555" stroke-width="1.5" marker-end="url(#av)"/>
<line x1="620" y1="335" x2="540" y2="250" stroke="#555" stroke-width="1.5" marker-end="url(#av)"/>
<line x1="410" y1="270" x2="410" y2="340" stroke="#555" stroke-width="1.5" marker-end="url(#av)"/>
Public IP traffic routed through the vRack has a default bandwidth of 5 Gbps in EU/CA/US regions and 100 Mbps in APAC regions. Additional bandwidth can be purchased per-vRack and per-region, either during the Additional IP order or from the vRack management page. This is separate from the Dedicated Server private bandwidth described [below](#private-bandwidth).
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's align naming - Public IP, Additional IP, IPv6, ..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Guide creation The Pull Request contains at least 1 new guide (meta.yaml and index edition needed) Offer: Network The PR documents Network products: Additional IP, BYOIP, Load Balancer, vRack, OCC, etc

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants