So this register is essentially a bitmask describing which VLAN VIDs are valid and have members which should apply VLAN filtering on ingressing packets. I.e. 0b0 would mean no VIDs are valid, 0b10 would mean only VID1 is valid, 0b110 means VID1 and VID2 are valid, etc.
Given you’re just looking at two VLAN VID entries, you’re correct!
I don’t believe you are mistaken, this should be written by ARIES and we’ve had some customers use it similarly to yourself and not have issues but we’ve had two here that have… we shall take a look at this.
I’m now running across a strange issue when trying to save this configuration into the EEPROM. I record the input following the documentation and end up with:
Following the advice in the other post I similarly removed any of the lines that ended in
0000 as I assumed those are default values so it would fit in the EEPROM.
However when I restart the switch and reload the vlan configuration the settings under vlan classification have not been persisted - but the rest have.
I also notice that some of the EEPROM values being written differ from the poster in the other thread - this seems odd given that I am mostly using the same setup minus the 3rd vlan. I have tried this multiple times and the switch has the proper configuration and is working before I power it off - when it is powered back on it no longer works as those classification settings are not properly loaded again.
So just to confirm, when you power-cycle and read from EEPROM straightaway, do you get the values you expect (the register values you outlined above which are similar to another poster, except with no VID2 configured) or some other values?
Given that you want the same setup as the previous poster, I agree that you should have the same register values except the changes to (18,00) register and ignoring (18,03) so I’m not sure why it would’ve captured different values.
I just confirmed that on power on I was seeing the expected values in the EEPROM.
To add to my confusion - I’m not sure what the “clear VLAN Table” toggle is meant to do exactly - but I noticed it was toggled on one of the screen shots in the other thread. I just went through the EEPROM command capturing process again and tried toggling that switch with everything else the same. I ended up with the following EEPROM settings which are still different from the other poster (the only change is the first register setting that was added):
This EEPROM configuration works and persists properly across reboots. So my immediate issue is solved - but I’m not exactly sure what is going on or why this worked.
As the dev who wrote the ARIES software, I can say that it’s a little “quirky”, to put it nicely.
There is some decent documentation in the Notion page below that goes into how data structure is represented both in the software and inside the actual EEPROM.
Unlike some more refined software, you have to read or write to the board every time you want to actually update something. That means there’s ample chance for the displayed values in the software to be different to what’s in the EEPROM, and the only way to rectify that is to manually read from the EEPROM.
In the case of “Clear VLAN Table” this clears the settings in the software, but until you actually “Write” this to the board, nothing has actually changed in the configuration of the board. Under this paradigm, the best way to think when using ARIES is…
Choose my settings in the GUI
Write these settings to SwitchBlox Industrial
Read these settings back from SwitchBlox Industrial to confirm
Nothing in the software will automatically update until you click read; nothing in the board’s settings will update until you click write.
Of course once you start using the EEPROM, with it’s non-volatility, it adds an extra layer of complexity, but the general idea is the same.
Longer term we’ll be upgrading the functionality to be more akin to a command line interface, which should be more familiar with how a typical data center switch is configured. This is a project that @aaron is keen to do as we want to improve this experience.
Short term, we’ll continue with ARIES and supporting any queries that come up.
I had read the documentation already and did appreciate it! I have appreciated that you have pretty good documentation and also good support!
To be more precise - my confusion is only around what specific registers represent (and a bit about what different buttons on the GUI are actually meant to do) and how I think I’m following the exact same setup as someone else and ending up with different EEPROM values - that seem to work for me.
It’s the kind of thing some time with manuals could solve for me - but I also figure you folks have more experience with this chipset and probably a better idea of what is going on.
For now things are working for me so I’m not going to spend more time thinking about it at the moment!
Thanks! Good support is key for us to build our reputation and quality.
You’re right to be a bit confused about the specific meanings of registers. Ultimately we will abstract this away from the customer so that you don’t need to know how/what each register does, rather you just send a single command and all this happens under the hood.
The “raw” nature of the software is a product of the speed at which it was developed, ultimately we will be refining this though
