Lab 03-01 · Bridge: turn your router into one big network¶

Picture two classrooms next to each other, separated by a sliding wall. Each class has its own teacher, its own whiteboard and its own announcements. Now somebody slides the wall open. Suddenly it is one big room: everybody hears every announcement, and you can walk over to a student from the other class without asking anybody for permission.

Your MikroTik router normally keeps your laptop in its own little room (192.168.88.0/24), separated from the classroom network (10.0.0.0/24). To get out, every packet has to go through the router's "door" (routing and NAT). In this lab you slide the wall open: the router becomes a bridge, your laptop joins the classroom network directly, gets its address from the trainer's router, and can talk to your neighbour's laptop face to face.

The analogy: sliding the wall open¶

Keep this picture for the whole lab.

What is a bridge?¶

A bridge is a device that joins several network segments into one network. It works at Layer 2 (the data link layer of the OSI model): it forwards frames by looking at their MAC addresses, and it does not change them.

The slides stress three ideas:

• It is transparent. The bridge does not rewrite anything. Your laptop does not even know it is there.
• It learns. The bridge keeps a table of "which MAC address lives behind which port" (the host table, WinBox Bridge → Hosts). A frame for a known MAC goes out of that port only; a frame for an unknown MAC, or a broadcast, goes out of every port.
• It joins different physical media. In RouterOS a bridge can join Ethernet ports, WiFi interfaces, tunnels... into a single network. A switch chip can only join the ports wired to that same chip.

Collision domain vs broadcast domain¶

Two words appear on slides p137–139 and on the exam.

So a bridge separates collision domains but keeps a single broadcast domain. That is exactly why your laptop will receive the trainer's DHCP answer after this lab: the DHCP Discover is a broadcast, and now it crosses your router.

The bridge inside your router¶

A MikroTik home router already uses a bridge: the factory configuration puts all LAN ports into one bridge (called bridge1 in our virtual lab, bridge on a real hAP). A port inside a bridge is a bridge port (RouterOS also says slave, flag S). The slides warn: an interface inside a bridge must not be treated individually any more. Addresses, DHCP servers and DHCP clients go on the bridge, never on its ports.

flowchart TB
    subgraph BEFORE["Before: a router (two rooms)"]
        direction LR
        L1["pc1<br>192.168.88.254"] --- B1["bridge1<br>192.168.88.1"]
        B1 -.->|"routing + NAT"| W1["ether2<br>10.0.0.x"]
        W1 --- C1["class network<br>10.0.0.0/24"]
    end
    subgraph AFTER["After: a bridge (one big room)"]
        direction LR
        L2["pc1<br>10.0.0.x"] --- B2["bridge1<br>ether3 + ether2"]
        B2 --- C2["class network<br>10.0.0.0/24"]
    end

The scenario¶

flowchart LR
    INET["<b>internet</b><br>198.51.100.10<br>web server"]
    CAP["<b>class-ap</b><br>trainer's router<br>10.0.0.1 · DHCP 10.0.0.100-200"]
    subgraph R1["r1 · your router"]
        R1W["ether2<br>Internet port"]
        R1B["<b>bridge1</b><br>192.168.88.1/24"]
    end
    subgraph R2["r2 · neighbour's router"]
        R2W["ether2<br>Internet port"]
        R2B["<b>bridge1</b><br>192.168.89.1/24"]
    end
    PC1["<b>pc1</b><br>your laptop"]
    PC2["<b>pc2</b><br>neighbour's laptop"]
    INET ---|"198.51.100.0/24"| CAP
    CAP ---|"ether2 · 10.0.0.0/24"| R1W
    CAP ---|"ether4 · 10.0.0.0/24"| R2W
    R1B ---|"ether3"| PC1
    R2B ---|"ether3"| PC2

You will configure both routers: r1 is yours, r2 plays your neighbour. In class, your neighbour does r2 on their own hAP.

Start the lab¶

Download the lab files and unzip them: 03-01-bridge.zip. Open a terminal inside the 03-01-bridge folder.

sudo containerlab deploy -t topology.clab.yml

Three RouterOS routers have to boot: give it two or three minutes. Then open one terminal per device:

ssh admin@clab-mtcna-03-01-r1            # password: admin   (also r2)
docker exec -it clab-mtcna-03-01-pc1 bash   # also pc2

At any moment you can run CLAB_EXEC="docker exec" ./check.sh to see which parts are already solved.

Step 1 · Look at the two rooms (and make a backup)¶

The slides say it twice: be careful when connecting networks and make a backup before starting. One wrong click in this lab can hand out wrong addresses to the whole classroom.

On r1 (WinBox: Files → Backup, then Bridge → Ports, IP → DHCP Server, IP → DHCP Client):

/system backup save name=before-bridge
/interface bridge port print
/ip dhcp-server print
/ip dhcp-client print

Expected: bridge1 has one port, ether3. A DHCP server defconf runs on bridge1. A DHCP client on ether2 is bound to an address 10.0.0.x (you may also see a client on ether1: that is the lab's own management port, ignore it).

On pc1, ask for an address and look at where you are:

dhclient -v eth1
ip -br address show eth1

You should get 192.168.88.254/24: an address from your router's room.

Done when the backup before-bridge.backup is listed in /file print and pc1 has a 192.168.88.x address.

Step 2 · Switch off your DHCP server¶

In one big room there must be one teacher handing out seat numbers. If your router kept its DHCP server running after joining the class network, it would answer the DHCP Discover of every laptop in the classroom, handing out 192.168.88.x addresses that lead nowhere. This is called a rogue DHCP server, and it is the number-one way to break a classroom network in this lab.

WinBox: IP → DHCP Server, select defconf, click the red X (disable).

/ip dhcp-server disable defconf
/ip dhcp-server print

Expected: the server shows the flag X (disabled). Disabled, not removed: you can switch it back on later.

Done when /ip dhcp-server print shows defconf with the X flag.

Step 3 · Add the Internet port to the bridge¶

This is the "slide the wall open" moment. You make ether2 (the cable to the trainer's router) a port of bridge1, next to ether3 (your laptop). From now on, frames flow between them without being routed.

WinBox: Bridge → Ports → +, Interface ether2, Bridge bridge1.

/interface bridge port add bridge=bridge1 interface=ether2
/interface bridge port print

Expected: two ports in bridge1, ether3 and ether2.

Now look at the DHCP client again:

/ip dhcp-client print

The client on ether2 now carries the flag I (invalid) and the comment DHCP client can not run on slave or passthrough interface! ether2 has handed its traffic over to the bridge, so it cannot have an IP configuration of its own any more.

Done when bridge1 has the ports ether2 and ether3.

Step 4 · Move the router's DHCP client to the bridge¶

The slides stop at Step 3, but the invalid DHCP client shows a loose end: your router itself lost its classroom address. Give the router a seat in the big room too, by asking DHCP on the bridge. That way you can still reach it, and it can still reach the Internet for itself (updates, NTP...).

WinBox: IP → DHCP Client, remove the invalid entry on ether2, then +, Interface bridge1.

/ip dhcp-client remove [find interface=ether2]
/ip dhcp-client add interface=bridge1
/ip dhcp-client print

Expected after a few seconds: a client on bridge1, status bound, with an address 10.0.0.x.

Done when the DHCP client on bridge1 is bound.

Step 5 · Do the same on your neighbour's router¶

Repeat Steps 1 to 4 on r2 (in class, your neighbour does it on their own hAP):

/system backup save name=before-bridge
/ip dhcp-server disable defconf
/interface bridge port add bridge=bridge1 interface=ether2
/ip dhcp-client remove [find interface=ether2]
/ip dhcp-client add interface=bridge1

Done when r2's bridge1 also has the ports ether2 and ether3, and its DHCP server is disabled.

Step 6 · Renew the laptops and talk to your neighbour¶

The slides say: renew your laptop's IP address; it must get its address from the trainer's router. Ask your neighbour for their laptop's address and ping it.

On pc1 and on pc2:

dhclient -r eth1          # give the old address back
dhclient -v eth1          # ask again
ip -br address show eth1
ip route

Expected: an address between 10.0.0.100 and 10.0.0.200, and default via 10.0.0.1. The DHCP answer came from class-ap, through your router, which did not even notice.

Now, from pc1, ping your neighbour's laptop (use the address pc2 got) and open a web page:

ping -c 3 10.0.0.1xx      # pc2's address
curl http://www.mikrotik.com/

ping must answer, and curl prints Welcome to the Internet.

Finally, on r1, look at the bridge's host table (WinBox Bridge → Hosts):

/interface bridge host print

You will see 02:00:00:00:01:01 (pc1) learned on ether3, and pc2's MAC 02:00:00:00:02:01 plus the other routers learned on ether2. The bridge knows who sits on which side.

Done when both laptops have 10.0.0.x addresses, pc1 pings pc2, and curl works. Run CLAB_EXEC="docker exec" ./check.sh: every line must say PASS.

If something goes wrong¶

Clean up¶

sudo containerlab destroy -t topology.clab.yml --cleanup

Key takeaways¶

• A bridge joins segments into one network at Layer 2, forwarding frames by MAC address without changing them.
• A bridge splits collision domains but keeps one broadcast domain; a router splits both.
• Adding the Internet port to the LAN bridge turns the router into a transparent bridge: laptops get addresses from the upstream DHCP server.
• Disable your own DHCP server first, or you become a rogue DHCP server for the whole class.
• Addresses and DHCP clients go on the bridge, never on a bridge port.
• Over WiFi, a plain station cannot bridge; RouterOS uses station bridge (RouterOS to RouterOS) or station pseudobridge.

Quick check¶

Next: the bridge you just built works in software. In the next lab you measure how fast it can go, and what Fast Path, Fast Forward and hardware offloading change.