1

Supposing we have a Trunk switch architecture with multiple VLANs as shown below :

enter image description here

A computer that belongs to the VLAN1 on the first switch (from the left) will be able to communicate with the VLAN1 on the third switch (from the left).

However, what prevents this computer from tagging his frames with the number "3" and being able to communicate with any VLAN3 even if he belongs to VLAN1?

Does it mean that Access mode architecture is preferred for security purposes?

2

To rephrase a bit what Ron Trunk already said:

However, what prevents this computer from tagging his frames with the number "3"

Nothing. There's nothing you can do from a switch administrator's perspective to prevent this. If the connected computer has the capability to send tagged frames, it may do so.

and being able to communicate with any VLAN3 even if he belongs to VLAN1?

Now here's something a switch admin can (and probably should) do, in (at least) two ways (and some add-on).

  • By dropping any incoming tagged frames on the port, and by mapping any incoming untagged frames into VLAN x, and by stripping the (internal) VLAN tag "x" from any outbound frame before forwarding it out of the given switch port (Cisco speak: switchport mode access and switchport access vlan X)
  • By restricting the set of 802.1q tags the given switchport will accept inbound and forward outbound, and by dropping the rest (Cisco lingo: switchport mode trunk and switchport trunk allowed vlan <myListOfVlans>). Optionally with a definition what happens to untagged frames on the given switch port (Cisco:switchport trunk native vlan X).
  • (vendor specific) by disabling any protocol that would allow dynamic negotiation of trunking/non-trunking mode of the given port (Cisco: setting the switchport mode explicitely switchport mode access|trunk, as above, and by disabling Dynamic Trunking Protocol with switchport nonegotiate)

Does it mean that Access mode architecture is prefered for security purposes?

Running all and every port untagged will sooner or later show some scaling (cable and port density) and cost issues, worsened by growth of the computing infrastructure.

In the end, it mostly will depend on the level of trust between computing infrastructure ("the server admins") and the network infrastructure ("the network admins") and what the given security policies mandate.

Some policies will say to never mix VLANs of different security zones (as in "internal" vs "DMZ" vs "external") on the same 802.1q trunk [1], while some will let you mix internal and DMZ while keeping external VLANs separated, and some may just not care.


[1] mandating not to mix internal/dmz/external VLANs on a given 802.1q trunk to a server/computer also suggests to segregate switching platforms for internal/dmz/external. After all, if a 802.1q trunk to a server/computer may not contain VLANs of different security zones, why should a trunk between two switches be allowed to? Still, there may be good reasons to run the internal VLANs and the dmz VLANs on separate trunk links from the same single switching platform to the same single host, but again, it's all up to the given security and operational policy to allow or forbid.

5

Most of the time, a computer is connected to an access port--not because of security, but because most computers don't need to switch VLANs. And since they don't switch, most NIC cards can't create 802.1q frames required for tagging VLANs anyway.

On most enterprise-class switches, an access port will drop tagged frames as a security measure.

  • 3
    The only thing I'd add to this is that it's generally considered best practice to limit the VLAN's accepted over a given trunk. In the example above the trunk to the third switch might only permit VLAN 1, which would also prevent traffic to VLAN 3 from being sent upstream. – rnxrx Dec 31 '18 at 2:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.