#networking

12 posts.

Migrating from a TP-Link Managed Switch to Juniper EX2200

I hit the VLAN 1 failure pattern while migrating from a consumer TP-Link managed switch to a Juniper EX2200. The configs looked equivalent, but the behavior was not.

Consumer switches are forgiving:

  • Trunk ports behave like access ports with extras
  • “Allow all VLANs” plus PVID feels safe
  • End devices often work on trunks accidentally

On the EX2200:

  • Trunks are for VLAN-aware devices only
  • Native VLAN is not a substitute for access ports
  • VLAN 1 must not be implicitly tagged
  • Ambiguous configs are accepted but behave differently

The fix was mostly mental model. Once I treated trunks as trunk-only and made VLAN intent explicit everywhere, VLAN 1 behaved and DHCP stopped failing silently.

For the working port and VLAN patterns, see: Juniper EX2200 VLAN Reference.

Expanding an OPNsense VM disk

After resizing the VM disk at the host level, OPNsense does not automatically use the extra space. gpart show may report the disk as corrupt. This is expected.

What is actually happening is the backup GPT header is still at the old end of the disk.

Fix

Enter the console shell.

Repair GPT metadata. This does not touch data.

gpart recover ada0

Resize the root partition. On a default UFS install this is freebsd-ufs, usually partition 3.

gpart resize -i 3 ada0

Grow the filesystem.

growfs /

Verify.

df -h

Notes

  • Applies to UFS installs
  • The corruption warning after a disk resize is normal
  • No reinstall required

Juniper EX2200 VLAN Reference

This is a reference note for configuring VLANs on a Juniper EX2200, written after running into a subtle but repeatable failure mode around VLAN 1. If you are migrating from a TP-Link managed switch, start here: Migrating from a TP-Link Managed Switch to Juniper EX2200.

The short version: the EX2200 is strict. Ambiguous VLAN configuration will not fail loudly, but it will break untagged traffic in ways that are easy to misdiagnose.

Core concepts that matter on EX2200

  • default should be explicitly set to VLAN 1
  • VLAN 1 uses tag value 0
  • A trunk port with a native VLAN is not equivalent to an access port
  • vlan members all is dangerous when a native VLAN is present

If you remember nothing else, remember the last point.

The failure pattern

This configuration looks reasonable but breaks VLAN 1:

  • Port mode: trunk
  • Native VLAN: 1
  • vlan members all

In this state:

  • Tagged VLANs work
  • Untagged VLAN 1 does not
  • DHCP fails silently
  • Clients, AP management, and anything relying on untagged traffic break

The switch is doing exactly what it was told. The problem is that VLAN 1 ends up treated as both tagged and untagged.

The working model

The EX2200 behaves predictably when VLAN intent is explicit.

Access ports

  • Used for non VLAN-aware devices
  • Untagged only
  • VLAN 1 only

Trunk ports

  • Used for VLAN-aware devices
  • Native VLAN 1 for untagged management traffic
  • Explicit list of tagged VLANs
  • Never use all
  • Never include default

This maps cleanly to common homelab gear:

  • Wired clients and CCTV use access ports
  • Omada access points use trunks with native VLAN 1 and tagged SSID VLANs
  • Proxmox hosts use trunks with native VLAN 1 and tagged VM VLANs
  • OPNsense uplinks use trunks with native VLAN 1 and explicitly listed VLANs

Reference commands

Define VLANs

set vlans default vlan-id 1
set vlans vlan2 vlan-id 2
set vlans vlan100 vlan-id 100
set vlans vlan2000 vlan-id 2000

Access port (VLAN 1, untagged)

set interfaces ge-0/0/X unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/X unit 0 family ethernet-switching vlan members default

Use for:

  • Laptops
  • CCTV
  • Any non VLAN-aware device

Trunk port with native VLAN 1

set interfaces ge-0/0/X unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/X unit 0 family ethernet-switching native-vlan-id 1
set interfaces ge-0/0/X unit 0 family ethernet-switching vlan members [ vlan2 vlan100 vlan2000 ]

Rules:

  • Never use vlan members all
  • Never include default
  • Native VLAN carries VLAN 1 implicitly

Omada access point trunk

set interfaces ge-0/0/X unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/X unit 0 family ethernet-switching native-vlan-id 1
set interfaces ge-0/0/X unit 0 family ethernet-switching vlan members [ vlan2 vlan100 ]
set interfaces ge-0/0/47 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/47 unit 0 family ethernet-switching native-vlan-id 1
set interfaces ge-0/0/47 unit 0 family ethernet-switching vlan members [ vlan2 vlan100 vlan2000 ]

Proxmox host trunk

set interfaces ge-0/0/46 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/46 unit 0 family ethernet-switching native-vlan-id 1
set interfaces ge-0/0/46 unit 0 family ethernet-switching vlan members [ vlan2 vlan100 vlan2000 ]

Verify configuration

show configuration
show configuration | display set
show configuration interfaces ge-0/0/X
show configuration vlans

Verify VLAN behavior

show vlans
show vlans default
show ethernet-switching interfaces
show ethernet-switching table interface ge-0/0/X

Cleanup commands

delete interfaces interface-range ALL-PORTS
delete interfaces ge-0/0/X unit 0 family ethernet-switching vlan members all

This is a reference, not a tutorial. It exists so future me does not relearn the same lesson the hard way.

Cloning Tailscale VM

/ Networking /

I wanted to create 3 Tailscale exit nodes for my 3 ISPs: Globe, PLDT, and Converge. I’m thinking of using it as a DIY VPN because sometimes some sites are slow on an ISP.

I mapped each VM to different VLAN specific to the ISP it will use.

Issue: Duplicate node key

I encountered an issue where when I clone a VM with running Tailscale, running tailscale up results in the same node key. To reset the node key, I had to:

apt-get remove tailscale
rm -r /var/cache/tailscale
rm /var/lib/tailscale/tailscaled.state
apt-get install tailscale
tailscale up -reset

Showing 4 of 12 posts