Learning Switching with Scenarios¶

Estimated time to read: 6 minutes

Originally Written: June, 2024

I'm just documenting some interesting scenarios I see on forums.

Warning

These are not production ready solutions or any kind of recommendation. They are designed as learning scenarios.

Bridging two access VLANs¶

Imagine a scenario an L2 switch has two ports configured as access ports in different VLANs. However the hosts connected to these ports are within the same subnet.

Traffic received by a switch which arrives on one VLAN will be forwarded only to ports in the same VLAN unless IP routing is enabled. In this case it's just an L2 switch and the hosts are within the same subnet.

How could we bridge these two VLANs?

Where could this be really used?

Have a look at the VLAN stitching with transparent firewalls post for an example of why we might use two VLANs in the same subnet. i.e. replace the unmanaged switch or cable (shown in the answer below) with a transparent firewall.

Inspecting traffic when both ports are in the same VLAN¶

We can start by investigating the traffic captured on various interfaces in a topology where a single VLAN is configured. Both ports are still configured as access ports however a second switch has been added and a trunk port has been configured between the two switches.

As you can see from the images above, when traffic enters and exits the interfaces towards the hosts there is no indication in the packet as to which VLAN they belong. This information is local to the switch.

It's only when the packet moves between the two switches that an 802.1Q VLAN tag is added. This is because the interface has been configured as a trunk port, i.e. can carry traffic that belongs to more than one VLAN. Therefore there needs to be some way for the receiving switch to understand to which VLAN this traffic belongs. In this example the tag is VLAN 10.

Hiding the VLAN¶

As we've just seen, when traffic is sent out an switchport configured as an access port there is no VLAN tag attached. The VLAN in this case is local and tells the switch where to send L2 traffic (e.g. which ports belong to the same broadcast domain).

So if we added another interface in VLAN 10 any broadcast traffic such as ARP would be sent out the new interface.

How do we get the packet back?¶

If we can send untagged traffic out of an interface in VLAN 10 then we can also accept untagged traffic on another interface in another VLAN. In the image below, we've configured another interface with switchport access vlan 20 which means any untagged traffic received on that interface will be part of VLAN 20 and we can then forward it to any other endpoints in this VLAN.

Bridging the VLANs¶

Warning

Again this is just a learning exercise, DON'T do this in a real production network!

To bridge these VLANs you could connect a cable between the two interfaces as shown in the following diagram.

192.168.10.1 will first ARP for the MAC address of 192.168.10.2
The broadcast will be sent to all interfaces in VLAN 10 (except the one on which it was received)
Traffic will exit the new blue interface untagged, traverse the cable, and enter the new pink interface which belongs to VLAN 20
It's broadcast traffic so will be sent to all interfaces in this VLAN (except the one on which it was received)
192.168.10.2 will receive the ARP request and respond

Verifying it works¶

In this example I'm using Cisco Modeling Labs which doesn't allow you to connect a cable between ports on the same switch (probably a good idea!). Therefore to make this scenario work in CML I've just added an unmanaged switch to connect the ports. It also takes a while for traffic to flow as I didn't have spanning-tree portfast configured on any of the interfaces.

As you can see in the following images, there is never a VLAN tag seen in the packet captures. In this scenario the VLAN is only used by the switch to determine where to forward traffic and never needs to share this VLAN tagged traffic with another switch like we saw in the first example.