Dear forum,
I since long use RB as my preferred device, and thus far was able to figure everything out without actually posting questions here myself. I could either work it out, or it was already mentioned at the MT wiki, forum or elsewhere “googleable”.
Thank you all for this!
But recently MT introduced the changed switchconfig, in which masterport-configs are converted to bridges (mostly with HW-assist).
Although this may work in most general cases, it certainly doesn’t in all cases.
Unfortunately, it doesn’t seem to bother most people, as it is hardly mentioned anywhere. And don’t get me wrong, I definitely understand that it certainly has it’s merits.
After all, MT is moving away from the more manageable switch chips towards more general switching HW. And having two methods of configuring (via switching or via bridging) isn’t actually beneficial to making it better understandable for newcomers. Or maintaining documentation.
But… and that is exactly my point: bridging just is not better for all… (bridging might very well be made to work, but is sub-optimal in some cases)
Personally, I have had to already downgrade 3 machines back to Ros6.39.2, because the new config was incompatible with the carefully designed and crafted switchport/vlan configs using (hybrid) trunks.
Furthermore, lower end devices (eg rb750gl) that actually DO work after the automatic master-2-bridge conversion (without further manual alterations), suffer from lower performance and ping drops after upgrade. Even on the higher powered RB3011 this is visible up and until 6.41rc11!
Therefore, since it doesn’t seem to be thoroughly discussed here (pls correct me if I’m wrong, just couldn’t find it), I would like to ask if in future releases it would somehow be possible to “block” this auto-conversion if the user asks for that block. It may be a hidden or cli-only option for die-hards, I don’t mind… Just give me the option to leave “my” bespoke switch masterport configs alone.
I would certainly hate to be locked out of new features and, even more important, security improvements. As I would have to stick to the old versions of Ros to make it work as designed.
So dear RB-users: Please comment if you also feel that this un-circumventible change is not really beneficial to your particular RB config, and if you feel this is something that limit’s the great flexibility on RB devices equipped with properly manageable switchchips.
(it’s not because some RB devices aren’t equipped with those chips, that owners of RB’s that DO have these chips have to suffer. Certainly not in situations where they didn’t suffer before)
Therefore I plea to have some kind of bypass in future revisions of Ros so that I can start updating ROS again!
(ps: Just to be clear, I’m not looking for assistance converting my old configs to new bridging configs. My point is that a certain design strategy implemented in 6.39.2 or before should remain working. These are often very carefully crafted and designed to work optimally with a given RB device and the networking situation. Converting it to bridging is so fundamentally changing the fabric of the design that it simply destroys the principles of it. Even if it also works)
Kind regards,
Rob