你將學到3點：
1) 同一個局域網是工作在二層網絡，二層網絡是在數據鏈路層。
2) Trunk網口通過IEEE 802.1Q協議，在以太網幀增加一個802.1Q頭。
3) native vlan通常用於管理。
轉載自https://www.redhat.com/sysadmin/vlans-sysadmins-basics
廣播域
A broadcast domain is a network segment where hosts can send broadcast frames to each other. In the case of an Ethernet network, the broadcast address is FF:FF:FF:FF:FF:FF. Ethernet frames sent to this address will be sent to all hosts on the local network.
Generally, most networks ensure that their broadcast domains and IP subnets match up, although this isn’t a technical limitation. For example, a subnet of 192.168.1.0/24 will correspond to a single broadcast domain at the Ethernet level. It’s generally a best practice to keep your broadcast domains and subnets small (e.g., a /24 network) because this setup ensures that lots of broadcast traffic (such as ARP) isn’t tying up all of your bandwidth.
A basic, unmanaged switch (like the one in your home router) without any VLAN support will only have one broadcast domain. Such a simple network would look something like this:
All of the hosts on this network will be able to talk to each other at layer two (the data link layer). If a third host is added to the network and begins to send broadcast traffic, then this traffic will be received by the other two hosts that are currently in the diagram. This might be fine for a small office or home network, but over time your network will invariably grow and you’ll want more subnets (and with that, more broadcast domains). You can imagine a network growing to look like the one below:
VLAN
This is where VLANs come in. It wouldn’t make sense for you to buy a single switch for each subnet (as in the above diagram), as that option would be expensive and inflexible. VLANs allow you to create virtual broadcast domains. Your network engineering team can create a VLAN on a switch, and then configure a network port for the appropriate access. Only hosts on the same VLAN would be able to talk to each other directly at layer two. A network with VLANs might look something like the diagram below:
VLANs are created on the switch, and then the switch ports that connect to hosts (or other switches) must be configured to support VLANs. Switch ports are usually considered either access ports or trunk ports.
Access ports are used for hosts that only need to connect to a single, logical network, and are assigned to a single VLAN. For example, end-user PCs typically have no reason to access VLANs other than their designated client network. However, certain hosts (or other switches) may need access to multiple VLANs on the same connection. This is where trunk ports come in.
A trunk port can carry multiple VLANs on a single port. Trunks do this via the IEEE 802.1Q protocol, which adds a special 802.1Q header to the Ethernet frame. This header provides the numeric VLAN ID to the connected device, allowing for the frames to be differentiated by VLAN when they are received, as seen here:
When might you encounter trunk ports? The most common use for trunk ports in simple networks is for connecting multiple switches together. You might have several switches in your network, and they may all have some of the same VLANs. Your network team needs a way to span these VLANs across many switches, so they may use trunk ports to accomplish this, as seen below:
Another use case that may be more familiar to sysadmins is for hypervisor connectivity. In more complex networks, a hypervisor may need to support virtual machines on many different logical networks (VLANs and IP subnets). In order to support connectivity to all of these networks, the network port connected to your hypervisor will likely be a trunk port, and you need to create multiple, logical VLAN interfaces to support the VLANs carried by the trunk.
One other concept about trunking that you may come across is the idea of a native VLAN. A native VLAN is carried on the trunk without a VLAN tag. Therefore, the end host doesn’t need any special configuration to begin using the native VLAN. You would just configure a network port like any other network port, and away you go.
Native VLANs are useful for management purposes because they don’t require any special configuration to use. For example, your hypervisor may come online and obtain an IP address through DHCP (e.g., via a static DHCP reservation) without any additional configuration. You can then log into the hypervisor via its management IP to configure all of the VLANs that you need.