Early one morning, an engineer end user discovered that the Engineer servers were unreachable, and he didn’t know if he could reach the Internet. The administrator investigated the user’s PC with the IPCONFIG /ALL command and verified that the PC was a DHCP client, but it had received an address from the Accounting DHCP server, not the Engineering DHCP server. The administrator wrote down the engineer’s MAC address and proceeded to the data center, expecting to find that the engineer’s PC was connected to the wrong access port on the access switch or that the port was assigned to the wrong VLAN.
The administrator was surprised to find the user’s port Fa0/1 configured for the correct Engineer VLAN (VLAN 10). Upon closer examination, the DHCP server for the engineers was operational and connected to Engineer VLAN 10, and the Accounting DHCP server was operational and connected within the Accounting VLAN 20.
So there are two separate VLANs, but they are performing as a single broadcast domain. How is this possible?
The engineer’s PC sent a DHCPDiscover message within its VLAN 10, but the Engineer DHCP server was busy responding to other requests. So the second DHCPOffer coming from the Accounting DHCP server was accepted.
A DHCPDiscover frame uses a destination MAC address of 12 hexadecimal Fs (broadcast), which will result in a flood. Since this frame will exit the access port of VLAN 10 untagged or modified in any way, when it is received on the other end of the cable into an access port of VLAN 20, the switch will not care and will continue to flood the frame throughout VLAN 20.
OSI Layer 2 devices, such as a bridge or switch, create multiple smaller collision domains from a larger single collision domain.
VLANs create multiple smaller broadcast domains from a larger single broadcast domain. Prior to VLANs, the only way to segment a broadcast domain was by using a router, an OSI Layer 3 device. Therefore, broadcast domains existed long before VLANs, and VLANS can be comprised of a single broadcast domain.
In a properly designed IP network, a VLAN should map to a single broadcast domain, which in turn should map to a unique IP network. For ease of troubleshooting (and for avoiding trouble!), traffic from one VLAN should not reach another VLAN without an OSI Layer 3 device, such as a router. Historically, as in the days of Novell IPX, two frame types (802.3 and 802.2) constituted two unique networks and operated on the same cable/broadcast domain.
If a user was to walk into a data center and a cable was to fall from the wire nest of the rack-mounted devices, it could easily be placed back into an incorrect port. VLAN membership is not visible on the exterior of the device. This will result in combining the VLANs into a single broadcast domain and would be an undesirable result in most cases.
Cabling an access port belonging to VLAN 10 into an access port belonging to VLAN 20 on the same switch or on a different switch would achieve this compromise. Some would argue CDP, if enabled, would catch this and send a console message stating native VLAN mismatch, but the compromise would still exist and traffic would still flow.
Keep in mind that when a switch looks up the destination MAC address and is unable to find it, it will flood the frame. Flooding means it will allow the frame to exit out all ports of the VLAN in which the frame was received but not out of the port in which it entered. The frame will also flood out trunk ports.
Another way to combine two VLANs into a common single broadcast domain is using a trunk port with 802.1q trucking protocol. 802.1q tags all VLAN traffic except one. This untagged VLAN is called the native VLAN.
It is possible to create a trunk between two switches, with each switch having a different native VLAN on its end of the trunk. Though CDP will generate a native VLAN mismatch message, the trunk will still form and untagged traffic from one switch will be deposited into the neighboring switches’ native VLAN.
Of course, CDP can be turned off to silence the warning.
So, can one VLAN reach another without a router or OSI Layer 3 device? Yes, but this is normally found as a fault, not a proposed design. Depending on manufacturer, make, model, IOS release and lunar position, some devices may respond differently to this mostly undesirable outcome.
Related Courses
ICND1 v2.0 — Interconnecting Cisco Networking Devices, Part 1
CCNAX v2.0 — CCNA Routing and Switching Boot Camp
SWITCH — Implementing Cisco IP Switched Networks v1.0