Using VLANs and trunks in hybrid physical-CML lab environments

[Noosphere]

Please forgive me if this is misplaced, as this is my first post.

TL;DR: How do I allow VLANs and trunking between a physical router or switch and a virtual router or switch in Cisco Modeling Labs when the layer 2 network between the two lab nodes itself uses VLANs and trunks?

I administer an instructional data center used by Cisco Academy students studying for the CCNA certification. We purchased Cisco Modeling Labs with the intention of allowing students to have hybrid labs consisting of a mix of CML virtual nodes and physical routers and switches.

I have read the relevant documentation regarding external connectors and have set up several to meet our needs, however, because there are several trunked switches between the virtual and physical nodes, The nodes themselves cannot pass tagged traffic or be trunked. Below is a simple schematic showing how the nodes are connected.

[CML LAB NODE CONFIGURED BY STUDENT] ---> [EXTERNAL CONNECTOR (LINUX BRIDGE)]---->[ESXi vSWITCH (adds VLAN tag)]---trunk-->[PHYSICAL SWITCH NOT MANAGED BY ME]--trunk-->[BACKBONE ROOT SWITCH]---trunk--->[BACKBONE RACK SWITCH (removes VLAN tag]---->[PHYSICAL LAB NODE CONFIGURED BY STUDENT]

As long as the student does not configure trunking or vlans on the physical and virtual nodes, everything works fine since the intervening switches treat it like access layer traffic. However, you cannot connect a virtual lab switch and a physical lab switch via a trunk because the intervening infrastructure ITSELF uses trunks.

Ideally what I'd like is for the two lab nodes to think they're connected directly at layer 1 as though there's no intervening infrastructure. Failing that, I'd at least like students to be able to use VLANs and trunking when using mixed virtual and physical lab equipment.

[Flavio Miranda]

@Noosphere 

 The limitation could be here "[CML LAB NODE CONFIGURED BY STUDENT] ---> [EXTERNAL CONNECTOR (LINUX BRIDGE)]--"

ESXi surelly supports trunk. The linux may not support trunk.  

[Ramblin Tech]

Your transport service infrastructure should be provisioned as an L2VPN. What you need is really no different than enterprise customers needing a carrier-ethernet service from an SP that transports their L2 enterprise traffic unchanged from CE to CE (ie, VLAN tags intact).

Are you able to negotiate with the group that manages the transport infrastructure? The L2VPN need not be anything more complicated than a QinQ service that accepts your C-tag and pushes their own S-tag on top at the first switch (PE), and pops off the S-tag at the last PE; your original C-tag is then delivered intact. If that infrastructure group might give you a blank stare if you say "L2VPN", just go right to saying "QinQ" instead. ("L2VPN" generically covers all flavors of L2 transport technologies including QinQ, EoMPLS, VPLS, EVPN, VXLAN, etc and might be intimidating to some.)

[Noosphere]

I'll have to look further into this. I've experimented with Q in Q and toyed with using MPLS as well. Framing the situation as a customer/provider relationship is tremendously helpful.

Another criterion I'd like to meet is to make it so the whole setup is transparent to both students and instructors. Ideally they shouldn't have to modify lab instructions, to use different vlans for each student, for example, which some of these tunneling solutions may require.

[Ramblin Tech]

Ideally, the QinQ service would be provisioned as port-based, rather than vlan-based. A vlan-based l2vpn uses the CE’s c-tag as a discriminator to identify which EVC will transport the frame to the remote destination, as there can be multiple EVCs multiplexed at the UNI (the interface between CE and PE). A port-based l2vpn is agnostic toward the c-tags (or lack of c-tags) and transports all transit traffic on the same EVC. A vlan-based service requires pre-coordination of the vlan IDs to be used across the UNI, while a port-based service does not. The implication of this is that with a port-based service, the only vlan ID coordination that has to take place is between students and instructors, with no coordination required with the transport infrastructure provider.