Skip to main content

Connecting Multiple VLANs Using Equinix Metal Private IP Addressing

Connect two of your VLANs to each other across metros using Equinix Metal's Layer 3 networking.

Connecting Multiple VLANs Using Equinix Metal Private IP Addressing

In this guide, you will learning how to connect two Equinix Metal VLANs, each in a different metro, using Equinix Metal Backend Transfer. Normally, Metal devices on the Equinix layer 3 private network can communicate only with other devices in the same project and metro. Backend Transfer extends this connectivity to devices in the same project across metros worldwide.

Metal devices connected to VLANs that have attached private IP Metal Gateways also can communicate with the Equinix Metal's private layer 3 network. Like Metal devices directly attached to the network, these connections are restricted to the same metro. Backend Transfer extends this connectivity as well, to devices and VLANs with private IP Metal Gateways across metros worldwide.

Using a private IP Metal Gateway means that you will assign the devices in the VLAN IP address from a private IP range provided by Equinix Metal, rather than from an IP address range that you choose.

If you want to use your own IP address range, and the VLANs are in the same metro, you can use the VRF Metal Gateway to connect the VLANs and select the IP address range. In that case, refer to our guide Connecting Multiple VLANs with Full IP Control.

As of this writing, it is not possible (yet) to connect VLANs across metros using VRF Metal Gateways and select your own IP address range.

Architecture

Before we get started, take a look at the architecture of the completed connection:

Architecture

There are two VLANs, each in a distinct metro. Each VLAN is connected to an Equinix Metal Gateway, which is connected to the Equinix Metal private layer 3 network, which in turn is connected to the global Equinix Metal private backbone. The global connectivity is enabled on your project via Backend Transfer. Each VLAN has an IP address range provided by Equinix Metal. You select which addresses in the provided range to assign to each Metal device. The Metal Gateway's IP is assigned by Equinix Metal.

Each VLAN may or may not also connect to the public internet via an Equinix Metal Gateway, or to Equinix Fabric via a VRF Metal Gateway.

Prerequisites

The prerequisites for connecting your VLANs are:

  • An Equinix Metal account, with a project in it
  • Two VLANs deployed to your Equinix Metal project, each in a different metro

No configuration information is necessary, because Equinix Metal will be providing the IP ranges for your VLANs.

Equinix Metal has guides to help with setting up your account, organization and project, including deploying your first server and an introduction to the Equinix Metal console.

Once you have your project, in the Console, select Networking:

Select Networking from the console

Then select VLANs:

Select VLANs from the Networking menu

Then click the "Add a VLAN" button:

Add VLAN

In the dialog that appears, pick a Metro, and any VLAN ID that is convenient for you. For our example, we will use VLAN ID 200 in Washington.

Add VLAN Details

Repeat the process for a second VLAN in a different metro. For our example, we will use VLAN ID 201, in Dallas.

Add second VLAN Details

Once complete, you should see two VLANs in two distinct metros:

VLANs

Enable Backend Transfer

With the VLANs in place, you'll next enable Backend Transfer for the project. Backend Transfer is a per-project configuration. You only need to enable it once per project, but you do need to enable it on each project.

Backend Transfer is a paid feature. You will be charged for traffic between metros.

Backend Transfer is under "Networking," like "VLANs." Select "Backend Transfer":

Console - Backend Transger

Then toggle "Backend Transfer":

Enable Backend Transfer

Wait a moment, and you should see Backend Transfer as "Enabled," with a green status on each metro:

Backend Transfer - Ready

Deploy Equinix Metal Gateway

The VLANs are created, and Backend Transfer is enabled. The next step is to create a Metal Gateway to link each VLAN to the Equinix Metal private network. "Metal Gateway" is under "Networking," like "VLANs" and "Virtual Routing and Forwarding." Click on "Metal Gateways":

Metal Gateway

Then click "Create a Metal Gateway":

Create Metal Gateway

To create the Metal Gateway, you need a few pieces of information:

  • The Metro. This must be the same metro as the VLAN you are connecting to. In our case, our first VLAN is in Washington.
  • The VLAN. This is the VLAN that the Metal Gateway will connect to. We will connect to our first VLAN, 200, which we created earlier.
  • The IP block. This is one of a reserved public IPv4 range, a private IPv4 range, or a VRF IP range. Since we are connecting to the Equinix Metal private network, we will pick "Private IPv4," and then an IP range of the size we need. For the purposes of this guide, a /28 of 16 IPs is enough. When deploying in production, you might need a larger range with more IPs, or a smaller range with fewer.

Create Metal Gateway

Repeat the process to create a Metal Gateway for the second VLAN:

  • The Metro. This must be the same metro as the VLAN you are connecting to. In our case, our second VLAN is in Dallas.
  • The VLAN. This is the VLAN that the Metal Gateway will connect to. We will connect to our second VLAN, 201, which we created earlier.
  • The IP block. This is one of a reserved public IPv4 range, a private IPv4 range, or a VRF IP range. Since we are connecting to the Equinix Metal private network, we will pick "Private IPv4", and then an IP range of the size we need. For the purposes of this guide, a /28 of 16 IPs is enough.

Create Metal Gateway

Once complete, you should see both gateways listed in the console. Each should have the correct Metro, VLAN and IP range.

Metal Gateways

Notice that each VLAN has been assigned an IP Block and Usable IPs. These are the IPs that you can use on Metal devices attached to that VLAN. For our example:

VLAN Metro IP Block Usable IPs Gateway
200 Washington 10.68.50.16/28 10.68.50.18 - 10.68.50.30 10.68.50.17
201 Dallas 10.70.53.224/28 10.70.53.226 - 10.70.53.238 10.70.53.225

You will need those IP addresses when connecting Metal servers to the VLANs.

Test Connection

The setup is complete, and it's time to test the connection. We will deploy one Metal server on each VLAN, assign it an IP in that VLAN, and test it.

Since this is a guide on the connections, and not on deploying Metal servers, we won't give detailed descriptions here. For more information, refer to the Deploy Your First Equinix Metal Server Guide.

There are a few things to keep in mind.

  1. Deploy each server normally in its target metro. In our case, deploy one server in Washington to connect to VLAN 200, and one in Dallas to connect to VLAN 201.
  2. Switch each server networking type to hybrid bonded, so you can SSH to it from the internet while also connecting to the VLAN, then attach it to the VLAN and assign an IP address. Use the Equinix Metal hybrid bonded networking documentation for detailed instructions.
  3. On each server, add the route to the other VLAN via the Metal Gateway. In this example:
    • The first VLAN in Washington has gateway 10.68.50.17, while the second VLAN in Dallas has IP range 10.70.53.224/28, so when the device in Washington is ready, add the route: ip route add 10.70.53.224/28 via 10.68.50.17.
    • The second VLAN in Dallas has gateway 10.70.53.225, while the first VLAN in Washington has IP range 10.68.50.16/28, so when the device in Dallas is ready, add the route: ip route add 10.68.50.16/28 via 10.70.53.225.

Once the servers are deployed, you'll need to configure them correctly for VLAN networking, IP addresses and routes.

Configure the first server

SSH into the first server, in Washington. Use the following commands:

apt-get install vlan                                     # install VLAN support packages
modprobe 8021q                                           # load the 8021q VLAN module into the kernel
echo "8021q" >> /etc/modules                             # ensure the 8021q VLAN modules are loaded on future boots
ip link add link bond0 name bond0.200 type vlan id 200   # create a VLAN interface on bond0 with VLAN ID 200 called bond0.200
ip link set up dev bond0.200                             # bring the VLAN bond0.200 interface up
ip addr add 10.68.50.18/28 dev bond0.200                 # add the IP address to the VLAN bond0.200 interface

Here is what it looks like on the server:

root@c3-small-x86-01:~# apt-get install vlan
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
  grub-pc-bin
Use 'apt autoremove' to remove it.
The following NEW packages will be installed:
  vlan
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 10.4 kB of archives.
After this operation, 51.2 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu jammy/universe amd64 vlan all 2.0.5ubuntu5 [10.4 kB]
Fetched 10.4 kB in 0s (41.5 kB/s)
Selecting previously unselected package vlan.
(Reading database ... 74606 files and directories currently installed.)
Preparing to unpack .../vlan_2.0.5ubuntu5_all.deb ...
Unpacking vlan (2.0.5ubuntu5) ...
Setting up vlan (2.0.5ubuntu5) ...
Processing triggers for man-db (2.10.2-1) ...
Scanning processes...
Scanning processor microcode...
Scanning linux images...

Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this host.

root@c3-small-x86-01:~# modprobe 8021q

root@c3-small-x86-01:~# echo "8021q" >> /etc/modules

root@c3-small-x86-01:~# ip link add link bond0 name bond0.200 type vlan id 200

root@c3-small-x86-01:~# ip link set up dev bond0.200

root@c3-small-x86-01:~# ip addr add 10.68.50.18/28 dev bond0.200

With those steps complete, add the route to the IP range of the other VLAN, in Dallas, via the local Metal Gateway on the VLAN:

root@c3-small-x86-01:~# ip ro add 10.70.53.224/28 via 10.68.50.17

Configure the second server

Repeat on the second server, in Dallas, but using the appropriate VLAN ID and addresses for the second VLAN and device. Here are the commands:

apt-get install vlan                                     # install VLAN support packages
modprobe 8021q                                           # load the 8021q VLAN module into the kernel
echo "8021q" >> /etc/modules                             # ensure the 8021q VLAN modules are loaded on future boots
ip link add link bond0 name bond0.201 type vlan id 201   # create a VLAN interface on bond0 with VLAN ID 201 called bond0.201
ip link set up dev bond0.201                             # bring the VLAN bond0.201 interface up
ip addr add 10.70.53.226/28 dev bond0.201                # add the IP address to the VLAN bond0.201 interface

Here is what it looks like on the server:

root@c3-small-x86-02:~# apt-get install vlan
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
  grub-pc-bin
Use 'apt autoremove' to remove it.
The following NEW packages will be installed:
  vlan
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 10.4 kB of archives.
After this operation, 51.2 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu jammy/universe amd64 vlan all 2.0.5ubuntu5 [10.4 kB]
Fetched 10.4 kB in 0s (41.5 kB/s)
Selecting previously unselected package vlan.
(Reading database ... 74606 files and directories currently installed.)
Preparing to unpack .../vlan_2.0.5ubuntu5_all.deb ...
Unpacking vlan (2.0.5ubuntu5) ...
Setting up vlan (2.0.5ubuntu5) ...
Processing triggers for man-db (2.10.2-1) ...
Scanning processes...
Scanning processor microcode...
Scanning linux images...

Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this host.

root@c3-small-x86-02:~# modprobe 8021q

root@c3-small-x86-02:~# echo "8021q" >> /etc/modules

root@c3-small-x86-02:~# ip link add link bond0 name bond0.201 type vlan id 201

root@c3-small-x86-01:~# ip link set up dev bond0.201

root@c3-small-x86-02:~# ip addr add 10.70.53.226/28 dev bond0.201

As with the first server, add the route to the IP range of the other VLAN, in Washington, via the local Metal Gateway on the VLAN:

root@c3-small-x86-02:~# ip ro add 10.68.50.16/28 via 10.70.53.225

Test the connection from the first server

Return to the first server in Washington at 10.68.50.18.

First try to ping the local Metal Gateway, in Washington:

root@c3-small-x86-01:~# ping 10.68.50.17
PING 10.68.50.17 (10.68.50.17) 56(84) bytes of data.
64 bytes from 10.68.50.17: icmp_seq=1 ttl=64 time=0.480 ms
64 bytes from 10.68.50.17: icmp_seq=2 ttl=64 time=0.235 ms
64 bytes from 10.68.50.17: icmp_seq=3 ttl=64 time=0.215 ms
^C
--- 10.68.50.17 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2086ms
rtt min/avg/max/mdev = 0.215/0.310/0.480/0.120 ms

This is a good result. Next, ping the Metal server on the other VLAN 201 in Dallas:

root@c3-small-x86-01:~# ping 10.70.53.226
PING 10.70.53.226 (10.70.53.226) 56(84) bytes of data.
64 bytes from 10.70.53.226: icmp_seq=1 ttl=55 time=35.8 ms
64 bytes from 10.70.53.226: icmp_seq=2 ttl=55 time=33.5 ms
64 bytes from 10.70.53.226: icmp_seq=3 ttl=55 time=33.5 ms
^C
--- 10.70.53.226 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 33.455/34.231/35.766/1.085 ms

This result is good as well.

Test the connection from the second server

Now repeat the exercise from the second server in Dallas, on VLAN 201.

First, ping the local Metal Gateway in Dallas:

root@c3-small-x86-02:~# ping 10.70.53.225
PING 10.70.53.225 (10.70.53.225) 56(84) bytes of data.
64 bytes from 10.70.53.225: icmp_seq=1 ttl=64 time=0.187 ms
64 bytes from 10.70.53.225: icmp_seq=2 ttl=64 time=0.266 ms
64 bytes from 10.70.53.225: icmp_seq=3 ttl=64 time=0.229 ms
^C
--- 10.70.53.225 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2051ms
rtt min/avg/max/mdev = 0.187/0.227/0.266/0.032 ms

Finally, ping the Metal server on the other VLAN 200 in Washington:

root@c3-small-x86-02:~# ping 10.68.50.18
PING 10.68.50.18 (10.68.50.18) 56(84) bytes of data.
64 bytes from 10.68.50.18: icmp_seq=1 ttl=55 time=34.2 ms
64 bytes from 10.68.50.18: icmp_seq=2 ttl=55 time=34.3 ms
64 bytes from 10.68.50.18: icmp_seq=3 ttl=55 time=34.3 ms
^C
--- 10.68.50.18 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 34.168/34.230/34.264/0.044 ms

Success -- we have connected two VLANs via a VRF.

Conclusion

You have successfully have deployed two VLANs in two different metros, each with private IP ranges provided by Equinix Metal, which you have deployed to your servers. You then connected the VLANs using Backend Transfer to enable full communications between them. You also tested those communications between devices on the VLANs. You can use this setup to deploy more devices to more VLANs across the globe, and connect them with full routing.

Last updated

26 September, 2024

Category

Tagged

Article
Subscribe to our newsletter

A monthly digest of the latest news, articles, and resources.