meckhardt wrote

I dont understand how Tagged Workds as ACCESS; and UNTAGGED works as GENERAL.

In cisco Tagged is ACCESS and Untagged is TRUNK

 

Definitely not! Even for Cisco switches the same is true as for TP-Link switches:
 

• An Ethernet port can be either an access port or a trunk port.
   
• An access port is a port which is member of exactly one VLAN. Since its purpose is to connect VLAN-unaware devices, it almost always is an untagged member of this single VLAN. From the view of the connected device there is no VLAN. The VLAN is said to be »terminated« for egress traffic in the switch and the switch »starts« this VLAN for ingress traffic by assigning the VLAN ID according to the Port VLAN ID (PVID) setting.
   
• A trunk port is a port which is member of several VLANs. Its purpose is to carry traffic for different VLANs over the same physical cable. Since a trunk is used to connect VLAN-aware devices, the port is almost always a tagged member of all VLANs it carries traffic for. From the view of a connected device the VLAN »starts« in the device itself and is »terminated« in this device (or – if a switch – in another device to which it forwards the trunk).

 

There are no different types of trunks. A GENERAL port was a special setting for a trunk in old switches, but it was way to unflexible. Nevertheless, a GENERAL port is a trunk, too. It just behaves differently from a (former) TRUNK port on egress of tagged frames.

 

Usually, a trunk in modern networks does not handle untagged frames. The ability of a trunk to handle untagged traffic (by adding a VLAN ID to untagged frames on ingress according to the PVID and by removing this VLAN ID from frames on egress if it matches the PVID) has been introduced to help migrating an existing non-VLAN network with legacy devices to a VLAN network.

 

If your whole network can handle VLANs, there is no need to use untagged frames at all on trunks. In fact, there are no untagged frames inside a VLAN network. All frames always get assigned to a VLAN, at least inside the switch. A managed switch does not forward untagged frames internally, all frames are always tagged internally even if they had been received untagged and will be emitted untagged by the switch.

 

Setting up VLANs is so easy if you keep some basic rules of thumb in mind:
 

• Design your networks as if they were separate networks. E.g. for five networks draw a picture (in mind) of five routers, five switch layers, five different client device layers and plenty of cables.
   
• Now check which device is VLAN-aware:
  • If the router is VLAN-aware, you can use one router for all five networks.
  • If the switch layer (one or more switches) is VLAN-aware, you can use one switch layer for all five networks.
  • If the connected device is VLAN-aware, e.g. a wireless access point, a server / NAS, you can connect this device to all five networks.
  • If a connected device is not VLAN-aware, e.g. a laptop, PC or a camera, your VLAN must be terminated in the switch (or AP) this device is connected to and the device will reside in only one of the five networks.
     
• Now connect all VLAN-aware devices over trunks to save cables.
• Then connect all non-VLAN-aware devices to an access port of a switch (or to a SSID of an access point).

 

For example, your router knows five different networks assigned to VLANs 101, 110, 120, 130 and 140. I would start those VLANs on the router, that means the router sets the VLAN tag and the router's port which is connected to the switch therefore is a trunk port. In this case, the switch's port must be a trunk, too. So you assign the router's and the switch's port a tagged membership of all five VLANs.

 

The switch carries traffic of all five networks to another switch over a trunk, too. The other switch also uses a trunk port which is a tagged member of all five VLANs. The PVID does not matter, except if you expect untagged frames appearing on a trunk. But where should untagged frames come from on a trunk? There are none as long as you don't use exotic protocols like those used on some legacy HP servers which did mix untagged and tagged frames on its trunk ports. However, for such weird protocols a trunk can still carry untagged frames if necessary.

 

Of course, if you want to complicate things, you can mix untagged traffic (VLAN 140) and tagged traffic (remaining VLANs) on a trunk. You can also shoot yourself in the foot with a gun, nobody will keep you away from doing so. :-)

 

If you want, you can call such a VLAN 140 an »untagged VLAN« or a »Default VLAN« or a »Native VLAN« or a »System VLAN«, but it isn't untagged inside the switch. It gets tagged with VLAN ID 140, else it would be no VLAN. And managed switches always know only VLANs.

 

Let's assume your wired device is an access point which offers three SSIDs for three of your five networks. The switch port to which the AP is connected to and the port of the AP are trunk ports and as such they must be tagged members of those three VLANs. The VLAN is terminated in the SSID (to be precise: in the virtual interface assigned to this SSID). A client device connecting to one of the three SSIDs connects to one of those three networks provided by the AP, it does not need to know anything about VLANs, it just resides in a single network. Note that the AP itself can also use VLAN-tagged frames (»Management VLAN«) or use untagged frames for management access.

 

A non-VLAN-aware wired laptop or a non-VLAN-aware wired camera will be connected to the switch over an access port. The goal of an access port is to start and to terminate the VLAN in the switch, so the device sees itself as connected to only one (supposedly) non-VLAN network. You assign this switch port an untagged membership of only one VLAN and set the Port VLAN ID (PVID) to this VLAN ID. Frames on ingress now get tagged by the switch (due to the PVID setting) and frames on egress will have the VLAN tag removed by the switch (b/c of untagged membership of the port in this VLAN).

 

Now you might wonder what's the difference of an ancient TRUNK port switch setting vs. a GENERAL port setting.

 

Assume switch #1 adds VLAN tag 140 to untagged frames arriving from the router since you emit untagged frames on the router and have set the switch's PVID to 140 to start VLAN 140 on the switch.

 

Next, assume switch #1 is connected to switch #2 over a trunk. Switch #1 needs to decide how to egress frames in VLAN 140 to switch #2.

 

Should the switch remove the VLAN tag or should it keep the tag? The ancient answer to this question was a subtype for the trunk, namely a GENERAL port:
 

• A GENERAL port will force the switch to keep the VLAN tag on egress.
• A TRUNK port will remove the VLAN tag for VLAN 140 on egress since its PVID is 140.
  That's because the PVID rules the switch's behavior on egress to a TRUNK port.

 

This is old style and too unflexible.

 

With the untagged/tagged flag of a switch port you have much finer control of the switch's behavior:
 

• If the port is an untagged member of VLAN X, the switch removes the tag on egress for all frames with VLAN tag X.
• If the port is a tagged member of VLAN X, the switch will keep the tag on egress for all frames with VLAN tag X.
• The PVID no longer determines whether a tag is removed on egress. It still is used to assign untagged frames a VLAN tag on ingress.

 

Nowadays, TP-Link switches use trunk ports which behave like former GENERAL ports used in TP-Link firmwares two generations back (keep tag on egress, that's tagged behavior unless explicitly told to egress untagged frames). The old switches are EoL meanwhile.
 
Don't be confused, there are no GENERAL ports anymore, albeit you still find this ancient port type in the CLI commands. It will force admins who were used to this old notation to use (former) GENERAL ports for trunks. But those ports are trunk ports as per definition.

 

Home work left to the reader:

1. Can an access port be a member of two VLANs if untagged? And if so, for what purpose?
2. Can a trunk port be a member of only one VLAN if tagged? If so, does this make any sense?
3. Can a VLAN be terminated inside a client device such as a laptop or PC? If so, for what purpose?