Network VLAN tagging and trunking

A tagged VLAN and a trunked VLAN are related networking concepts that work together to enable VLAN communication across network infrastructure.

Tagged VLAN

A tagged VLAN refers to Ethernet frames that have been “tagged” with VLAN identification information. When a frame is tagged, an additional 4-byte header (called an 802.1Q tag) is inserted into the Ethernet frame that contains:

  • VLAN ID (12 bits) - identifies which VLAN the frame belongs to (1-4094)
  • Priority bits (3 bits) - for Quality of Service (QoS)
  • Other control bits (1 bit)

This tagging allows a single physical network link to carry traffic from multiple VLANs simultaneously, with each frame clearly identified as belonging to a specific VLAN.

Trunked VLAN

A trunk is a network link (typically between switches, or between a switch and router) that is configured to carry traffic for multiple VLANs. The trunk link uses VLAN tagging to distinguish between different VLANs’ traffic.

Key characteristics of trunk links:

  • Carry multiple VLANs on a single physical connection
  • Use 802.1Q tagging (or the older ISL protocol) to identify VLAN membership
  • Have a “native VLAN” - one VLAN that travels untagged across the trunk
  • Reduce the number of physical connections needed between network devices

How They Work Together

When a frame from VLAN 10 needs to travel across a trunk link:

  1. The sending switch adds an 802.1Q tag identifying it as VLAN 10
  2. The frame travels across the trunk link with this tag
  3. The receiving switch reads the tag, knows it belongs to VLAN 10
  4. The receiving switch forwards it only to ports that are members of VLAN 10
  5. If forwarding to an access port, the tag is removed before transmission

This system allows network administrators to segment traffic logically while using shared physical infrastructure efficiently.

You’ve identified a potential discrepancy that’s worth clarifying. Without seeing the specific blog post you’re referencing, there are a few possibilities to consider:

About the CRS304-4XG-IN Port 5

You’re correct that on the MikroTik CRS304-4XG-IN, port 5 is typically designated as the Management/Boot PoE port. This port is usually:

  • An RJ45 Ethernet port
  • Intended primarily for initial configuration and management access
  • Capable of providing PoE power
  • Often configured as a separate management interface

Possible Explanations

  1. Different Model: William Lam might be using a different MikroTik switch model than the CRS304-4XG-IN. Many CRS series switches have different port configurations.

  2. Port Numbering Confusion: There might be inconsistency in how ports are numbered (software vs. physical labeling, or 0-based vs. 1-based counting).

  3. Repurposed Management Port: It’s technically possible to configure the management port as a trunk port for VLAN traffic, though this would be an unconventional setup.

  4. Documentation Error: There could be a typo or error in the blog post.

Verification Steps

To clarify this, you could:

  • Check the exact switch model mentioned in the blog post
  • Look at the MikroTik configuration commands shown (they would reveal the actual interface being configured)
  • Verify the physical connection description in the post

Could you share the link to William Lam’s blog post? That would help identify exactly what’s happening in his specific configuration.

Now I can see exactly what William Lam is describing! Looking at his blog post, he clearly states:

“Port 5 on the MikroTik is connected to Port 6 (10GbE SFP+) on the Sodola Switch This is configured as a Trunked VLAN (802.1Q) that will carry all VLANs that have been defined from the MikroTik”

You’re absolutely right to question this. There’s a definite discrepancy here because:

The Issue

On the MikroTik CRS304-4XG-IN, Port 5 is indeed the Management/Boot PoE port - it’s an RJ45 copper port, not an SFP+ port. However, William is describing connecting it to an SFP+ port on the Sodola switch, which would require a fiber or DAC connection.

Possible Explanations

  1. Different MikroTik Model: He might be using a different CRS series switch (like the CRS305-1G-4S+IN or another variant) where port numbering differs

  2. Port Numbering Error: He might actually be using one of the 10GbE SFP+ ports (ports 1-4 on the CRS304-4XG-IN) but mislabeled it as port 5

  3. Physical vs. Logical Numbering: There could be confusion between how RouterOS numbers interfaces versus physical port labels

What’s Most Likely

Given that he mentions connecting to a “10GbE SFP+” port on the Sodola switch, he’s almost certainly using one of the actual SFP+ ports (1-4) on the MikroTik, not the management port. The reference to “Port 5” is likely an error in his documentation.

Your technical knowledge is spot-on - this does appear to be an inconsistency in his blog post description versus the actual hardware capabilities.

I think William might actually be referring to the MikroTik CRS305-1G-4S+ switch or confusing the layout to this one. In either case, why would he need to create a trunk vlan on the port connecting to the Sodola switch?

Excellent detective work! You’re absolutely right - he’s most likely referring to the MikroTik CRS305-1G-4S+ which has:

  • Port 1: 1GbE RJ45 (management/uplink)
  • Ports 2-5: 10GbE SFP+ ports

This would make “Port 5” a legitimate SFP+ port that could connect to the Sodola switch’s SFP+ port.

Why Create a Trunk VLAN?

William needs a trunk VLAN on that connection for a very practical reason: he’s running multiple VLANs in his VCF lab environment and needs to carry all of them across a single physical link.

Looking at his setup:

  1. Multiple VLANs Required for VCF: VMware Cloud Foundation typically requires several network segments:
    • Management network (for vCenter, ESXi management, etc.)
    • vMotion network
    • vSAN network
    • VM networks
    • Potentially others (backup, replication, etc.)

  2. Limited Physical Connections: He only has one 10GbE connection between the MikroTik and Sodola switches

  3. Trunk Solves the Problem: By configuring that single link as an 802.1Q trunk, he can:
    • Carry traffic for all VLANs across one physical cable
    • The MikroTik tags frames with VLAN IDs as they cross the link
    • The Sodola switch receives the tagged frames and can distribute them to appropriate ports/VLANs
  4. Downstream Distribution: On the Sodola side, he can then:
    • Connect his iMac to an access port (untagged) for management VLAN access
    • Connect the Synology NAS with tagged VLANs for specific network access
    • Have the flexibility to add more devices to different VLANs as needed

Without the trunk, he’d need separate physical cables for each VLAN - which would quickly exhaust his available ports and be much more expensive and complex to manage.

This project is for educational and home lab purposes.