A tenant VM landed on the wrong network
Two tenants run on one host, each on its own bridge so they can't see each other. One VM is on the wrong bridge and can reach the other tenant. Move it back.
Scenario
One host runs two tenants. Each tenant has its own Linux bridge so the tenants are isolated at
layer 2: tenant A on br-tenant-a, tenant B on br-tenant-b. A VM was attached to the wrong
bridge, so it can see the other tenant's traffic, and meanwhile its own tenant is split across
two bridges.
Topology
- Tenant A:
vm-web,vm-app→br-tenant-a - Tenant B:
vm-db,vm-cache→br-tenant-b
Your job
Find the misattached VM and move it to its own tenant's bridge, so each tenant's VMs share a broadcast domain and neither tenant can reach the other.
What "done" looks like
Tenant A's two VMs reach each other, tenant B's two VMs reach each other, and no VM can reach a VM in the other tenant.
Teaches: layer-2 tenant isolation on a host comes from bridge membership: a VM on the wrong bridge both breaks its own tenant and leaks into another. (macvlan/ipvlan achieve the same separation per parent interface; here it's modelled with one bridge per tenant.)
What gets checked
Your solution is verified against each of these:
- All four tenant VMs are attached to a bridge
- Tenant A's VMs (web, app) share a broadcast domain
- Tenant B's VMs (db, cache) share a broadcast domain
- No VM can reach the other tenant
Solve it in your browser
No setup, no install. Write your solution in the editor and hit Check. The in-house engine renders and grades it instantly, then issues your proof the moment every check passes.
Solve in browser →Prefer your own lab?
- Build the fix locally. New to the tooling? See setting up your lab.
- Push your topology file, device configs, and any playbooks to a public repo (GitHub or GitLab).
- Submit the repo link. We review it by hand, confirm it works, and issue your proof page.