I'm not exactly sure what your graphic is suppposed to ask or illustrate... but the basic principle is fairly simple:
If it helps, you might consider these devices separately:
- a router (L3 functionality, two ports - lan and wan, no switch)
- a managed switch (L2 functionality, vlan aware, multiple ports connected to a switch chip).
- optionally a wireless AP (L2 functionality, ethernet port + one or more radios, can support VLANs; we'll punt this for now, but basically it's treated in large part as just a wireless equivalent for the wired network except that standard user wifi itself doesn't have the concept of 802.1q tagging so each VLAN is assigned to a unique SSID, or it is actually possible to have a single SSID with multiple passwords that correlate to the desired VLAN; the wifi client doesn't know anything about VLANs, though).
The router's CPU is connected to the switch chip. The port on the CPU that makes that connection is eth0. On the switch, that connection is basically (from a logical standpoint) just another ethernet port but it's obviously not wired to an external physical port. So... eth0 connects to the switch (switch0).
The switch chip is VLAN aware, making it possible to have a single switch pass multiple VLANs and configure vlan-port membership. Each VLAN represents a single subnet.
In the case of swconfig based devices (such as the C7), we have switch config stanzas -- this allows us to define the configuration of the switch. For example (from a different device):
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '2 3 4 0t'
The above stanza says that VLAN 1 should be tagged on logical port 0, and untagged on logical ports 2-4. In this device, the CPU is connected to logical port 0.
We can have many of these VLAN assignments with any combination of the ports and the tagging/untagging status so long as we obey the following:
- a port may have zero or one untagged network
- a port may have zero, one, or many tagged networks.
- valid VLAN IDs are 1-4095.
- (ancilary, but sometimes relevant) some hardware may have limitations on the absolute number of VLANs that are supported and/or may have a limited range of VLAN IDs (such as 1-15).
- in certain rare cases, there may be hardware requirements that all VLANs on a trunk port (i.e. multiple networks on a single port) must be tagged. Most hardware is tolerant of an untagged network on a trunk, but this limit does come up from time to time (and then there is the personal/professional opinion about never mixing tagged+untagged on a trunk -- but that's another discussion).
As far as the switch is concerned, the tagged/untagged status of a VLAN on a given port is a method of ensuring that the next connected device (upstream or downstream) knows what VLAN a given ethernet frame belongs to -- that's the whole purpose of tagging -- it's just a label to ensure things don't get jumbled up.
Internally, the switch fabric will account for the VLANs so that it keeps them separate. It may or may not literally carry the same 802.1q tagging method internally, but you can certainly think of it this way if it helps simplify the internal logic of the switch fabric. Basically, the rule is to move traffic through the switch, keeping all VLANs separated and then applying or stripping the tags at the point of egress on the ports based on VLAN port-membership configuration.
To properly participate on a given network, the device connected to a switch port must match that port's configuration with respect to the untagged and/or tagged status of the VLANs. If the device does not match the configuration for one or more of the VLANs, it cannot participate on that network. A simple example here would be a regular computer or end-user device that is typically not configured to be VLAN aware... it will expect an untagged network. If it is plugged into a trunk port, it will pick up the untagged network (if it exists) but it will be unaware of the tagged networks. Likewise, if only tagged networks exist, it will not be able to connect at all since there is no untagged network.
Once we have configured the switch, any traffic enters one port destined for a device that is connected to another switch port on the same VLAN will be forwarded through the switching fabric and never needs the router's CPU involvement. The switch chip is specifically designed for switching (L2), and it does this by MAC address.
Now, using dotted notation, eth0.x where x is the VLAN ID, we create a VLAN on the CPU's ethernet port. This must match the switch configuration in order for it to 'connect' to the VLAN on the switch via tagging (so in the above example, if logical port 0 is eth0, that would be eth0.1 because we see port 0 tagged). We can repeat this for other VLANs, too. (and yes, it's possible to have a network untagged on the switch's logical port 0 and then use the base eth0 on the CPU... this isn't recommended, but it should be possible unless the hardware has the limitation described above).
When traffic is destined for another subnet (or the internet), the host will be send that traffic to the gateway/router address for L3 routing to occur. The gateway must be on the same VLAN/subnet as the host -- it represents the egress path for traffic where the destination is not on the current network. Here, the switch simply forwards traffic from the host to the router in standard L2 fashion, and then the router makes the L3 decisions (firewall/routing) according to its configuration and rules.
If we think about this in the separate devices context, the switch forwards traffic between devices on the same network. In the case of traffic going to a differnet network or the internet, the switch is actually still moving traffic between devices on the same network -- it just happens to be that one of those devices is a router which has the ability to route to other networks.
Does that help?
