Does all frames from all VLANs lose all taggings and all gets dumped to the end device? Even if the end device on this port is vlan-unaware, it can see all the frames.
Background:
obviously trunk port should always be tagged, but while I am looking at a network, this is exactly what I have found...
I'm not sure what you mean. Frames on trunks are tagged, except for the native VLAN. That is how the devices on each end of the trunk can separate frames into the correct VLANs.
Please expand on what you have. For example, a good network description or diagram, the network device models, and the network device configurations. You can refer to the Network Engineering Question Checklist for guidance, then edit your question.
We simply do not have enough information to answer the question. Without the configurations, we simply cannot understand because the question is not clear as asked.
It appears that all those interfaces are disabled, but the interfaces use GVRP to negotiate the trunk and allowed VLANs. A trunk tags frames for all the VLANs, except the native VLAN. That is the definition of a trunk.
Trunk port is Cisco terminology and most widely accepted. However some vendors use trunk to refer to link aggregation, and instead they do use the terminolgy of tagged port for a port that carries multiple tagged VLANs.
You are mistaken in that the port is tagged. That is explaining that the PVID is tagged or not. That means frames for the primary VLAN for the interface (VLAN 1 by default) are either tagged or not tagged. It is frames that get tags, not the ports.
Now, typically on a trunk/tagged port the native VLAN, or in the case of this swtich the PVID, is the VLAN that is not tagged and all received untagged traffic is assigned to.
And this switch does use the Cisco terminology for Edge/Trunk.
@ugn A trunk will tag all frames, except those for the native VLAN, except where the native VLAN traffic is also tagged, essentially having no native VLAN.
A client device connected to trunk port will typically drop all tagged frames. So a client connected to a trunk port with untagged native VLAN will operate on the native VLAN.
But you really don't want to operate like that as you are sending unnecessary traffic to the end device and if it were configured to do so, it could receive all your tagged traffic as well.
if this client device is a computer, with Intel Advanced network, is configured to see all VLANs except for the native vlan. Can this computer see the native vlan?
rigth, but this is a faulty network that is, for some miracle, somehow functional
A client device will always see the traffic on the native VLAN, as it is untagged. The actual VLAN number it won't see, but those are really unimportant anyhow.
They are just a tag to keep traffic sorted when sending across a link carrying multiple VLANs.
If the native VLAN is tagged, then the client will also get the VLAN number. But they will likely drop all traffic unless configured to accept tagged frames.
the client is a computer that can see all VLANs EXCEPT for the native vlan, yet the native vlan's packets shows up in wireshark in one of the VLANS on the computer
because the native vlan's ip address belongs to one of the vlans
Say you have two devices on two ends of a trunk port. One device (D1) is configured to use VLAN 10 as the native VLAN. The second device (D2) is configured to use VLAN 20 as the native VLAN. Both are set to send native VLAN traffic as untagged. What happens?
Basically, for children's bed story: we have a dumb device on a trunk port communicating with a PLC that is on a VLAN... and the traffic between them is being flooded across the network...
to answer your question, they don't see each other.
I could be wrong, but native vlan is all 1 in this case.
You would need to start with what is the configuration on the port the "dumb device" is connected to and the configuration on the port the PLC is connected to?
the dumb device should be on an edge port obvious mistake on our part. but the question is really, HOw can the current faulty state be functional?
flood traffic: we know the devices are communicating with each other, modbus TCP traffics are getting thru. dumb's traffic can reach the PLC, but the PLC's traffic can't go directly to dumb, it is visibel to the computer on the big switch
Again, anyone would need to know more to answer that. Networks work pretty well according to standards. In the IT world, network traffic tends to be the most "logically" behaved thing to troubleshoot. If it isn't doing what you expect it is most likely misconfiguration somewhere.
oh... another complication is that, there are 3 separate small switches with 3 separate dumb devices, and all those 3 dumb devices have the same MAC address. This is a purely switched network, no Router
Basically, what you are doing is providing information you believe is relevant, but there is likely more information that is necessary to understand the problem.
I often find that when people do packet captures with filtering enabled. They often inadvertently filter out the exact traffic they need to resolve the problem. It is better not assume you know what the problem is, capture it all and use display filters as this allows you go back and look at it differently as well.
Don't focus on what you believe the problem is, look at all the information and see where it takes you.
Limiting what you look at is a sure way to miss details that are important.
I personally strongly dislike the whole network "black magic" thought process that often takes place. Networks tend to work as designed, but far too many people (even in IT circles) simply do not understand enough about how they operate.
So networks are often thought of as some "mysterious" black box that you put data into and sometimes get out at the right points. But they can be understood.
With the somewhat rare exception of running into a bug. But often you can determine that if you know how they operate enough to spot when they actually aren't operating as they should.
Discussion between ugn and Ron Maupin
Discussion between ugn and Ron Maupin