A lab project that demonstrates how multiple customer VLANs can be transported across a provider network using QinQ (802.1Q tunneling). The topology combines MikroTik routers on the customer/distribution side and a Cisco switch acting as the provider-edge device responsible for QinQ encapsulation.
The goal of this lab is to simulate how different customer services can remain logically separated on their original VLANs while still being delivered through a shared provider transport infrastructure using a single provider service VLAN.
Repositories : https://github.com/ferisigitpratama/qinqmpls.git
Project Overview
This project simulates a QinQ-based service transport network where multiple customer VLANs are aggregated at a central router and then carried across the provider side using 802.1Q tunneling.
The lab uses RO-DIST as the central distribution router and connects it to three remote site routers:
- RO-SITE-A
- RO-SITE-B
- RO-SITE-C
Each site is assigned its own customer VLAN:
- VLAN 10 for Site A
- VLAN 20 for Site B
- VLAN 30 for Site C
On the provider edge, a Cisco switch named SW-QINQ is configured to encapsulate those customer VLANs into VLAN 500 as the provider service VLAN, allowing multiple services to be transported across a shared network while preserving the original customer VLAN tags.
Objectives
This lab was built to demonstrate how a provider can transport multiple customer VLANs across a shared network while maintaining end-to-end VLAN separation. The main objectives are:
- Simulate QinQ / 802.1Q tunneling in a provider transport environment
- Carry multiple customer VLANs over a single provider service VLAN
- Preserve customer VLAN separation across the provider network
- Demonstrate the relationship between customer VLAN tags and provider outer VLAN tags
- Build a practical interoperability lab using MikroTik and Cisco
- Validate connectivity between a central distribution router and multiple remote sites
Topology Overview
The lab consists of:
- RO-DIST → MikroTik distribution router
- RO-SITE-A → remote site router for VLAN 10
- RO-SITE-B → remote site router for VLAN 20
- RO-SITE-C → remote site router for VLAN 30
- SW-QINQ → Cisco provider-edge switch performing QinQ encapsulation
High-Level Topology
```text id="m9s8q2"
RO-SITE-A --- VLAN 10 ---\
RO-SITE-B --- VLAN 20 ---- RO-DIST ---- SW-QINQ ---- Provider Transport
RO-SITE-C --- VLAN 30 ---/
This design represents a simple provider handoff model where multiple customer services are aggregated at the distribution router and then forwarded toward the provider edge switch, which performs QinQ tunneling using a shared service VLAN.
---
## Architecture Summary
This project follows a basic provider transport model:
* Customer services are separated using **VLAN 10, VLAN 20, and VLAN 30**
* **RO-DIST** aggregates those services using VLAN subinterfaces on a single physical interface
* **SW-QINQ** acts as the provider-edge switch and encapsulates customer-tagged traffic into **VLAN 500**
* The provider network transports all customer services using the outer service VLAN while preserving the inner customer VLAN tag
This model reflects a common **Metro Ethernet / service provider** design pattern where multiple customer VLANs must be extended across a shared infrastructure without modifying the customer-side VLAN structure.
---
## VLAN and IP Plan
### Customer VLAN Mapping
| Site | Customer VLAN | RO-DIST IP | Site Router IP | Subnet |
| ------ | ------------- | --------------- | --------------- | --------------- |
| SITE-A | 10 | 192.168.10.1/30 | 192.168.10.2/30 | 192.168.10.0/30 |
| SITE-B | 20 | 192.168.20.1/30 | 192.168.20.2/30 | 192.168.20.0/30 |
| SITE-C | 30 | 192.168.30.1/30 | 192.168.30.2/30 | 192.168.30.0/30 |
### Provider Service VLAN
| Purpose | VLAN |
| ------------------------------ | ---- |
| QinQ Service VLAN / Outer VLAN | 500 |
---
## Device Roles
## RO-DIST
`RO-DIST` acts as the **central distribution router** in this lab.
Its role is to:
* terminate multiple customer VLANs on a single physical interface,
* assign IP addresses for each site-facing VLAN,
* aggregate customer traffic from multiple remote routers,
* forward the traffic toward the provider-edge switch.
### Actual VLAN Interfaces Used
Based on the configuration, RO-DIST creates the following VLAN subinterfaces on `ether1`:
* `SITE-A` → VLAN 10 → `192.168.10.1/30`
* `SITE-B` → VLAN 20 → `192.168.20.1/30`
* `SITE-C` → VLAN 30 → `192.168.30.1/30`
This makes RO-DIST the aggregation point for all remote site services.
---
## RO-SITE-A / RO-SITE-B / RO-SITE-C
These MikroTik routers represent **remote customer / branch sites**.
Each router connects to RO-DIST using its own VLAN and /30 subnet:
* **RO-SITE-A** → VLAN 10 → `192.168.10.2/30`
* **RO-SITE-B** → VLAN 20 → `192.168.20.2/30`
* **RO-SITE-C** → VLAN 30 → `192.168.30.2/30`
Their role is to simulate separate customer sites that need to be transported through the same provider infrastructure while remaining logically isolated.
---
## SW-QINQ
`SW-QINQ` acts as the **provider-edge switch** responsible for QinQ encapsulation.
Its role is to:
* receive customer-tagged traffic from the MikroTik side,
* apply **802.1Q tunneling**,
* map the customer traffic into **provider VLAN 500**,
* forward the encapsulated traffic toward the provider transport side.
### Actual QinQ Logic from the Configuration
Based on the switch configuration:
* the interface toward **RO-DIST** is configured in **dot1q-tunnel** mode,
* the customer-facing side is associated with **VLAN 500**,
* the provider-facing side is configured as a **trunk** allowing **VLAN 500**.
This means the switch preserves the inner customer VLAN and uses VLAN 500 as the outer transport tag.
---
## QinQ Service Design
The core concept of this lab is **QinQ / 802.1Q tunneling**.
### Customer VLAN Layer
The customer side uses:
* **VLAN 10** → Site A
* **VLAN 20** → Site B
* **VLAN 30** → Site C
These VLANs represent separate customer services or site connections.
### Provider Transport Layer
The provider side uses:
* **VLAN 500** as the **service VLAN**
This outer VLAN is used by the provider network to carry all customer traffic across a shared infrastructure.
### Double Tagging Model
The traffic flow in this lab follows a double-tagging structure:
* **Inner VLAN tag** = customer VLAN (`10`, `20`, `30`)
* **Outer VLAN tag** = provider VLAN (`500`)
This allows the provider to transport multiple customer services without changing the customer VLAN design.
---
## How QinQ Works in This Lab
The traffic flow can be summarized as follows:
1. A site router sends traffic using its assigned customer VLAN.
2. `RO-DIST` receives the traffic on the corresponding VLAN subinterface.
3. The traffic is forwarded toward `SW-QINQ`.
4. `SW-QINQ` applies **QinQ encapsulation** by placing the customer-tagged frame into **VLAN 500**.
5. The provider network carries the frame using VLAN 500 while preserving the original customer VLAN tag.
6. On the far side, the traffic can be delivered back to the correct customer service based on the inner VLAN.
This is one of the key ideas behind provider-managed Layer 2 service transport.
---
## Traffic Flow Example
### Example: SITE-A
1. **RO-SITE-A** sends traffic using **VLAN 10**
2. The frame reaches **RO-DIST** on the **SITE-A VLAN interface**
3. RO-DIST forwards the frame toward **SW-QINQ**
4. **SW-QINQ** places the frame into **provider VLAN 500**
5. The provider network transports the traffic using the outer VLAN
6. The original customer VLAN information remains preserved as the inner tag
The same logic applies to:
* **SITE-B** using **VLAN 20**
* **SITE-C** using **VLAN 30**
---
## Configuration Highlights
## RO-DIST
RO-DIST creates three VLAN interfaces on `ether1` to connect to the three remote sites.
### Example Configuration Logic
```mikrotik id="yl0mpp"
/interface vlan
add interface=ether1 name=SITE-A vlan-id=10
add interface=ether1 name=SITE-B vlan-id=20
add interface=ether1 name=SITE-C vlan-id=30
/ip address
add address=192.168.10.1/30 interface=SITE-A
add address=192.168.20.1/30 interface=SITE-B
add address=192.168.30.1/30 interface=SITE-C
RO-SITE Routers
Each remote site router creates a VLAN interface toward RO-DIST and uses a /30 IP address for the point-to-point site connection.
Example Site Configuration Logic
```mikrotik id="grqzjv"
/interface vlan
add interface=ether1 name=to-dist vlan-id=10
/ip address
add address=192.168.10.2/30 interface=to-dist
The same logic is used for:
* Site B with **VLAN 20**
* Site C with **VLAN 30**
---
## SW-QINQ
The Cisco switch provides QinQ encapsulation and service transport.
### QinQ Configuration Logic
```cisco id="0f5rvl"
vlan 500
name SERVICE-VLAN
interface GigabitEthernet0/1
switchport access vlan 500
switchport mode dot1q-tunnel
interface GigabitEthernet0/0
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 500
switchport mode trunk
This allows customer VLAN traffic to be tunneled through the provider network using VLAN 500 as the outer tag.
Verification and Testing
The purpose of verification in this lab is to confirm that:
- each site router can communicate with RO-DIST using its assigned VLAN,
- customer VLANs are transported correctly across the provider side,
- QinQ encapsulation is working as expected,
- the provider switch preserves customer VLAN separation.
Validation Checklist
- Verify VLAN interfaces on RO-DIST
- Verify VLAN configuration on RO-SITE-A / B / C
- Confirm IP addressing on all MikroTik routers
- Validate dot1q-tunnel configuration on SW-QINQ
- Confirm that VLAN 500 is allowed on the provider-facing trunk
- Test connectivity between RO-DIST and each remote site router
Example Test Scenarios
RO-DIST ↔ RO-SITE-ARO-DIST ↔ RO-SITE-BRO-DIST ↔ RO-SITE-C
If these tests succeed, it indicates that the VLAN transport and QinQ handoff are functioning correctly.
Repository Contents
This repository contains the main configuration files used in the lab:
| File | Description |
|---|---|
ro-dist.cfg |
MikroTik configuration for the distribution router |
RO SITE A.cfg |
MikroTik configuration for Site A |
RO SITE B.cfg |
MikroTik configuration for Site B |
RO SITE C.cfg |
MikroTik configuration for Site C |
SW-QINQ.cfg |
Cisco switch configuration for QinQ transport |
Why I Built This Lab
I built this project to better understand how customer VLAN services can be transported across a provider network without modifying the original VLAN design on the customer side.
Rather than only studying QinQ in theory, I wanted to build a simple end-to-end lab that shows how a distribution router, several remote sites, and a provider-edge switch work together to carry multiple customer services through a shared transport VLAN. This helped me visualize the difference between the customer service layer and the provider transport layer, which is a key concept in Metro Ethernet and service provider environments.
Conclusion
This project demonstrates a practical implementation of QinQ transport using MikroTik routers and a Cisco provider-edge switch. By separating customer services into VLAN 10, VLAN 20, and VLAN 30, and transporting them through provider VLAN 500, the lab shows how multiple customer services can be delivered across a shared infrastructure while preserving VLAN separation.
Although simplified for lab purposes, the design reflects a real provider concept where customer VLANs are preserved across the backbone using a service VLAN. It is a useful project for understanding QinQ service delivery, provider VLAN tagging, and site-to-site transport in an enterprise or ISP context.
If you are learning about QinQ, Metro Ethernet, or basic provider transport design, this type of lab is a great way to understand how customer VLANs can be extended across a shared network while maintaining logical isolation.
