CloudLabBox
Try the free demo

MikroTik MTCRE lab 9 of 14

Stub, totally stubby and NSSA areas, and virtual links

Shrink a branch's routing table with stub and totally stubby areas, then turn the area into an NSSA so the branch can still inject its own external routes, and rescue an area that isn't connected to the backbone with a virtual link.

Run this lab

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

In your workspace: Shared, then MikroTik MTCRE RouterOS v7 guided labs, then 09 - Stub totally stubby and NSSA areas and virtual links

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 70 minutes
Nodes need
6 vCPU, 2,304 MB
Smallest plan
Lite

The scenario

OSPF from lab 8 is running, but two problems landed on your desk. The branch router R1 is a small box and its routing table keeps growing with routes it doesn't need, yet the branch must keep advertising its own customer network (172.31.1.0/24) to the rest of Fernvale. And Fernvale has bought a small company whose network sits behind R5 in a new area 3; nobody can reach it, because area 3 doesn't touch the backbone.

AreaRoutersNotes
1R1, R2 (ABR)Branch; R1 redistributes 172.31.1.0/24
0R2, R3, R4R3 redistributes the partner network 172.30.1.0/24
2R4 (ABR), R5Transit for the virtual link
3R510.3.0.0/24, not attached to area 0

What you’ll practise

  • Explain which LSA types each special area type blocks
  • Configure stub and totally stubby (no-summaries) areas and read the result
  • Configure an NSSA and follow type 7 LSAs being translated to type 5 by the ABR
  • Recognise an area that isn't attached to the backbone
  • Repair it with a virtual link through a transit area

The tasks

  1. Look at the branch's table before you change anything
  2. Make area 1 a stub
  3. Make it totally stubby
  4. Turn area 1 into an NSSA
  5. Find out why area 3 is unreachable
  6. Build the virtual link

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 Stub totally stubby and NSSA areas and virtual links6 nodes, 5 links. Every link is listed as text below the diagram.R1R2R3R4R5PC1ether2eth0ether1ether1ether2ether1ether2ether1ether2ether1
6 nodes, with the interface names each link uses. On a narrow screen, scroll the diagram sideways.
Every link, as text
  • R1 ether1 to R2 ether1
  • R2 ether2 to R3 ether1
  • R3 ether2 to R4 ether1
  • R4 ether2 to R5 ether1
  • R1 ether2 to PC1 eth0
Nodes in Stub, totally stubby and NSSA areas, and virtual links, with the image each runs and the vCPU and RAM it’s set to
NodeDeviceImage in Add NodeSet to
R1MikroTik RouterOSmikrotik-7.14.21 vCPU, 256 MB
R2MikroTik RouterOSmikrotik-7.14.21 vCPU, 256 MB
R3MikroTik RouterOSmikrotik-7.14.21 vCPU, 256 MB
R4MikroTik RouterOSmikrotik-7.14.21 vCPU, 256 MB
R5MikroTik RouterOSmikrotik-7.14.21 vCPU, 256 MB
PC1VPCS 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 MTCRE RouterOS v7 guided labs.

  3. Open 09 - Stub totally stubby and NSSA areas and virtual links 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 MTCRE labs

All MikroTik MTCRE labs

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.