CloudLabBox
Try the free demo

MikroTik MTCSE lab 5 of 10

Layer 2 troubleshooting: a rogue DHCP server, DHCP snooping and bridge filters

Staff at Harbourside are getting 10.99.0.x addresses and can't reach anything. Find the rogue DHCP server plugged into the office switch, stop it with DHCP snooping and a bridge filter, and fix the real DHCP server, which a maintenance change had quietly broken. A troubleshooting lab with two planted faults.

Run this lab

It needs Lite: its 4 nodes are set to 4 vCPU and 1,024 MB in total. That fits the free demo too.

In your workspace: Shared, then MikroTik MTCSE RouterOS v7 guided labs, then 05 - Layer 2 troubleshooting - a rogue DHCP server DHCP snooping and bridge filters

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
4 vCPU, 1,024 MB
Smallest plan
Lite

The scenario

Monday morning at Fernvale Harbourside: staff PCs have addresses like 10.99.0.150 and can't reach anything. The office LAN is 192.168.40.0/24, served by GW's DHCP server through the office switch SW (a RouterOS router used as a switch, its ports bridged). Someone has plugged a home router into the meeting-room socket, and something else is wrong too. Find and fix both faults, and make sure a plugged-in DHCP server can never do this again.

DevicePortNotes
GWether1 → SW ether1192.168.40.1/24, DHCP server staff (pool .100–.199)
SWbridge office: ether1 (uplink), ether2 (desk 12), ether3 (meeting room)no IP address
PC1ether1 → SW ether2DHCP client
ROGUEether1 → SW ether310.99.0.1, a DHCP server handing out 10.99.0.0/24

What you’ll practise

  • Recognise a rogue DHCP lease from the client's point of view
  • Find the port a rogue device is on with the bridge host table
  • Use DHCP snooping with a trusted uplink so only the real server's answers reach clients
  • Add a bridge filter that drops DHCP server traffic from access ports
  • Explain DHCP starvation and the layer 2 tools that limit it

The tasks

  1. Look at the problem from the client
  2. Find the rogue's port, and the second fault
  3. Fix the real server
  4. DHCP snooping on the switch
  5. A bridge filter for defence in depth
  6. Get a good lease

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 Layer 2 troubleshooting - a rogue DHCP server DHCP snooping and bridge filters4 nodes, 3 links. Every link is listed as text below the diagram.GWSWPC1ROGUEether1ether1ether2ether1ether3ether1
4 nodes, with the interface names each link uses. On a narrow screen, scroll the diagram sideways.
Every link, as text
  • GW ether1 to SW ether1
  • SW ether2 to PC1 ether1
  • SW ether3 to ROGUE ether1
Nodes in Layer 2 troubleshooting: a rogue DHCP server, DHCP snooping and bridge filters, with the image each runs and the vCPU and RAM it’s set to
NodeDeviceImage in Add NodeSet to
GWMikroTik RouterOSmikrotik-7.14.21 vCPU, 256 MB
SWMikroTik RouterOSmikrotik-7.14.21 vCPU, 256 MB
PC1MikroTik RouterOSmikrotik-7.14.21 vCPU, 256 MB
ROGUEMikroTik RouterOSmikrotik-7.14.21 vCPU, 256 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 MTCSE RouterOS v7 guided labs.

  3. Open 05 - Layer 2 troubleshooting - a rogue DHCP server DHCP snooping and bridge filters 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 MTCSE labs

All MikroTik MTCSE 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.