I am working on your setup Josh but I want to stress that to do what you are doing you "need" to have an MTU of at least 1522 preferably 1528 on all your ports. You still have not answered me as to the MTU settings.
This switch is an older RevB board which means it shipped with a much older firmware that we originally had a standard MTU of 1518 which is not enough for what you're doing. If you never factory defaulted the switch after upgrading to v1.2.2 but just upgraded them the MTU would remain at the original 1518 standard.
The primary differences between Revs was the Polyfuses we used but there are "very" few Rev B boards out there, less than 200 total. There are some other minor changes between RevB and RevC but from RevC up just heavier PolyFuses. The board Rev would have nothing to do with this issue. Just thought I would throw that out there as people keep asking me what the differences are. So to re-cap the only differences between RevA and the current RevD boards only deal with PolyFuses used and some changes to the MOSFET control circuits nothing to do with how the switch does switchy kind of stuff.
If your switch still has an MTU of 1518 PLEASE set them all up to 1522 or preferably 1528 which is what is our new standard MTU size and YES if the MTU is still 1518 it can mess with the way you are passing VLANs as it increases the packet sizes. Not all packets would care as a lot of packets as smaller than the MTU to begin with.
Now why enabling an IP on the interface seems to fix your issue we are totally baffled however if your MTU is indeed 1518 assigning an IP address to the VLAN "could' cause somethings to happen differently.
But in the mean time "if" what you say is true that assigning an IP to the VLAN prevents it from happening why not leave the IP on there until we fix this.Since nobody else is reporting VLAN issues this means there is "something" different with your config than other people are using which I want to stress does not mean this is not our fault but rather it makes it more difficult to figure out.
Every customer is important and we want to try and solve this with you Josh but it may take some time and we will have to pass information back and forth. I have asked Eric to review this post and will ask him to LAB what you outlined above tomorrow. I am also going to reach out to Rory (my old CTO) as his VLAN experience is far better than mine and maybe he can weigh in on what might be happening.
As I have said before we do not write the code that runs the switch core no more then Ubiquiti writes the code that runs their ToughSwitch. The ToughSwitch was originally based on the BCM53118 Switch core with an AR7240 SOC driving the UI. The UI is used to configure the core, the switch core itself and ALL the switch abilities are handled by the Core's internal code. With that being said Vitesse who makes our switch core which is from the VSC-742X family of switch Cores is a mature product that has been on the market for several years and is used in many switches under different Names likes Cisco, Level 1, and so on so I highly doubt there is anything wrong with the core. Now there could be something in the way we are configuring the core which is what we have to find out.
One possible difference is in the way we configure the VLAN Tag INGRESS filtering and maybe when we assign an IP to a VLAN it messes with the filters but I do not think this is it either.
Also "if" your MTU is set at 1518 and you assign an IP to the VLAN is Linux somehow increasing the MTU setting but then you remove the IP and the MTU setting sticks or the INGRESS filters for that matter but when you reboot the switch it reverts back to the saved MTU or standard INGRESS Filtering we are using?
We are here to help Josh that is all I can say, I think we make a damn good switch and we try very hard to solve everyone's problems as fast as we can and I know it can be frustrating on your end when something does not work the way you want it to.
- Josh.jpg (36.24 KiB) Viewed 7969 times
