I85PREP
⌘ K
JNCIS-ENT study materials
JNCIS-ENT study resources

Trunk to a Third-Party Switch: Sales Segment Split in Two

JNCIS-ENT · Put your knowledge to work in context.

All case studies

Trunk to a Third-Party Switch: Sales Segment Split in Two

A Junos EX4300 stack provides access for 60 users on VLAN 120 (10.20.120.0/24). The gateway for 10.20.120.0/24 and the DHCP server for that subnet both sit in the core, reached over a multi-VLAN trunk on the stack's uplink. A third-party (non-Junos) access switch carrying 15 more Sales hosts was recently attached to that same trunk. On the third-party switch, the trunk port is configured with a native VLAN of 120 and VLAN 120 is allowed; on the Junos side VLAN 120 is a member of the trunk and the native VLAN is the default. After cutover, hosts behind the third-party switch lose their DHCP leases at renewal and cannot ping 10.20.120.1, while hosts on the Junos stack are unaffected. show ethernet-switching table shows the 15 MACs from the third-party switch in VLAN 1.

1. Explain the mechanism behind the failure. What happens to a frame sent by a host behind the third-party switch toward 10.20.120.1?

Read the worked answer

The two ends disagree about the native VLAN. The third-party switch tags nothing for VLAN 120: frames in that VLAN leave the trunk untagged. The Junos trunk does not have native-vlan-id 120, so the default applies and every untagged frame it receives is placed in the default VLAN (VLAN 1).

So the path of the frame is:

  1. Host sends a frame to its gateway MAC, broadcast ARP for 10.20.120.1.
  2. Third-party switch bridges it in VLAN 120 and sends it untagged.
  3. The Junos stack classifies it as VLAN 1 and floods it only within VLAN 1, which has no 10.20.120.0/24 gateway.

The ARP is never answered and DHCP renewals (broadcast) never reach the server, so hosts fall back to 169.254/16 at renewal. The MAC table confirming that the 15 MACs are learned in VLAN 1 is the proof that this is a VLAN-classification problem, not a link or STP problem.

2. How would you confirm the diagnosis on the Junos device, and what would you change to fix it? State the trade-off of each fix.

Read the worked answer

Confirmation, without a capture:

  • show ethernet-switching table - remote MACs from that switch are in VLAN 1, not 120.
  • show ethernet-switching interfaces / show vlans - confirms which VLANs the trunk is actually carrying and which is native.
  • show interfaces ae0.0 or the trunk unit, looking for the configured native-vlan-id.

Two fixes:

  1. Match the native VLAN: set native-vlan-id 120 on the Junos trunk. Fastest, but it makes a production data VLAN the untagged VLAN, which is the classic recipe for this exact fault recurring, and it merges VLAN 120 into whatever a future untagged frame is assumed to be.

  2. Preferred: define a dedicated, empty native VLAN (e.g. 999) on both ends and tag VLAN 120 explicitly on both ends. Nothing user-facing is ever untagged, so a native mismatch shows up as a harmless untagged orphan rather than a data-plane outage.

Either way, both ends must change together; changing only the Junos side simply moves the mismatch to the other direction.

3. Six months later the same trunk must also carry a voice VLAN (220) and a guest VLAN (400). What configuration principles keep this from breaking again, and what would you monitor?

Read the worked answer

Principles:

  • Explicitly list every VLAN on both ends; never rely on vlan members all on an inter-vendor trunk, because a VLAN added on one side and not the other silently blackholes rather than erroring.
  • Keep one dedicated native VLAN that carries no hosts, on both ends, and change it in the same window as the other side.
  • Verify STP agrees on the VLAN-to-instance mapping; if the other vendor maps VLANs to MSTIs differently, one side can block a VLAN the other forwards on the same physical link.

Monitoring:

  • Alarm on the count of MACs in the native VLAN on the trunk - in a correctly built trunk it should be zero (or only the other switch's own management MAC).
  • Watch show ethernet-switching table per VLAN after any change for MACs landing in an unexpected VLAN.
  • Track per-VLAN counters on the trunk so a single dropped VLAN is visible before users report it.