CloudLabBox
Try the free demo

MikroTik MTCINE lab 9 of 12

VRFs and route leaking

Host two tenants with identical addressing on one Fernvale data-centre router using VRFs, prove they can't see each other, then leak just the routes needed so one tenant reaches a shared backup service, and see why overlapping addresses limit leaking.

Run this lab

It needs Lite: its 6 nodes are set to 6 vCPU and 3,072 MB in total. That fits the free demo too.

In your workspace: Shared, then MikroTik MTCINE RouterOS v7 guided labs, then 09 - VRFs and route leaking

Try it free for 30 minutesRun it on Lite from £3 a day

The free demo needs no card and no email. Every lab plan includes every guided lab.

Level
Advanced
Time
About 60 minutes
Nodes need
6 vCPU, 3,072 MB
Smallest plan
Lite

The scenario

Fernvale has opened a small data centre. Its router DC-PE connects three networks:

  • Oakridge Clinic (CE-A) and Brightwater School (CE-B), two tenants who were both given the same addressing by the same installer: link 172.16.1.0/30 and LAN 192.168.10.0/24, with a PC at 192.168.10.10 on each side.
  • Fernvale's shared services network (SVC), with a backup server at 10.200.0.10.

The tenants must never see each other. Oakridge has bought the backup service; Brightwater hasn't. One routing table can't hold the same prefix twice for two different customers, so DC-PE needs VRFs. The CE routers and SVC are configured already (each has a default route towards DC-PE); you configure DC-PE.

NetworkDC-PE interfaceDC-PE addressFar end
VRF-A (Oakridge)ether1172.16.1.1/30CE-A 172.16.1.2, LAN 192.168.10.0/24
VRF-B (Brightwater)ether2172.16.1.1/30CE-B 172.16.1.2, LAN 192.168.10.0/24
SERVICESether3172.16.9.1/30SVC 172.16.9.2, servers 10.200.0.0/24

What you’ll practise

  • Explain VRFs: separate routing tables, interfaces bound to a table, overlapping address space
  • Create VRFs in RouterOS 7 with /ip vrf and route inside them
  • Use ping and traceroute in a VRF
  • Leak routes between VRFs with static routes and the gateway@vrf syntax
  • Explain why overlapping customer addresses limit route leaking

The tasks

  1. Create the VRFs
  2. Route inside each VRF
  3. Prove the isolation
  4. Leak routes for Oakridge's backup service
  5. Think about the overlap

The Lab Tasks pane has the scenario, these tasks, the checks to run, hints and the full solution.

Topology and devices

The network as it opens in EVE-NG, drawn from the lab’s own canvas, and the image each node runs.

Topology of VRFs and route leaking6 nodes, 5 links. Every link is listed as text below the diagram.DC-PECE-ACE-BSVCPC-APC-Beth0ether2eth0ether2ether3ether1ether1ether1ether1ether2
6 nodes, with the interface names each link uses. On a narrow screen, scroll the diagram sideways.
Every link, as text
  • CE-A ether1 to DC-PE ether1
  • CE-B ether1 to DC-PE ether2
  • DC-PE ether3 to SVC ether1
  • PC-A eth0 to CE-A ether2
  • PC-B eth0 to CE-B ether2
Nodes in VRFs and route leaking, with the image each runs and the vCPU and RAM it’s set to
NodeDeviceImage in Add NodeSet to
DC-PEMikroTik RouterOSmikrotik-7.14.21 vCPU, 256 MB
CE-AMikroTik RouterOSmikrotik-7.14.21 vCPU, 256 MB
CE-BMikroTik RouterOSmikrotik-7.14.21 vCPU, 256 MB
SVCMikroTik RouterOSmikrotik-7.14.21 vCPU, 256 MB
PC-AVPCS hostBuilt in to EVE-NGCounted as 1 vCPU, 1,024 MB
PC-BVPCS hostBuilt in to EVE-NGCounted as 1 vCPU, 1,024 MB

How to open this lab

  1. Sign in to your workspace at lab.cloudlabbox.com.

  2. In File Manager, open Shared, then the folder MikroTik MTCINE RouterOS v7 guided labs.

  3. Open 09 - VRFs and route leaking and start its nodes, then open Lab Tasks for the scenario and the steps.

The lab is read-only. You can start the nodes and configure the devices, but changes to the topology can’t be saved. To change it, rebuild it in your own folder.

More MikroTik MTCINE labs

All MikroTik MTCINE labs

Related labs in other courses

CloudLabBox is independent of MikroTik. The lab follows exam topics and isn’t vendor training material; vendor names identify the exams and the images in the workspace.