I found pages like this https://0x2142.com/whats-wrong-with-vlan-1 which seem to say VLAN 1 is “bad” because it’s commonly used so a hacker can try VLAN 1 first. Changing it to something else is simply security through obscurity. The real fix is to be careful which ports are allowed to be trunk ports.
I use untagged (hybrid VLANs) because I have many virtual machines, some on different VLANs. I don’t want to configure the host machine to be only on a VLAN, for a variety of reasons.
I use the same VLAN 1 as used by default on my Dell switch. So far, nobody here has said why VLAN 1 is “bad”, if you have a very good example please post that. But we are already very off topic here; using VLAN 1 is not the reason my packets have an 802.1Q header with VLAN ID 0.
I don’t know why @anav keeps trolling. Just stop posting to my thread.
Did you not see the avatar, I do not even come close to resembling a troll, quite insulting to us induced ovulators ( for the layperson - calmidae family).
Perhaps you need to chill just a bit more,
A classic!! https://www.youtube.com/watch?v=Pe2K5iT8lwE
PS. Take your vlan1 and put it where the sun don’t shine! In plain english, vlanX (where x does not =0,2-9) not good!!
Seriously, if it works for you, then thats great! It has given me problems in the past and we all strive for happy outcomes..
Nothing in that bit of code looks odd to me. I tried to break VLAN 1 and couldn’t. I was consistently able to ping from one computer to another. The only other random place I can think to look is at your switch settings in ROS to be sure the VLAN header setting isn’t set to Add if Missing and to be sure VLAN 0 isn’t assigned to any ports in the switch VLAN settings assuming you’re using a device with a switch chip that supports VLAN table. Beyond that, I’m out of ideas.
Its well known in the network world to avoid tagging with VLAN 1. Different vendors treat this in different ways and causes all sorts of hassles so most just avoid it.
Usually a tagged frame with vlan.id 0 is used for QoS - this allows the priority to come through without actually assigning a vlan. I see you are using tcpdump on a host - though a I am a big proponent of packet capture, I suggest that you take it to the next level - remove the end host behavior (is this a VM, perhaps?) and use a tap and grab the traffic off the link, not via the end host nor the transmitting device. Best to get a third party view of the problem at this point.