The basic logic behind VLANs is that ports are either trunk (carrying many/all VLANs tagged and optionally one - native - untagged) or access (carrying one VLAN untagged). It's clear that for the later some nanual config is necessary, somebody has to decide for a port of which VLANs (available) it's going to be a member. Not sure how MVRP could help here?
For trunk ports (interconnecting switches) MVRP is useful as it automatically adds any VLAN newly introduced on one of member switches.
So in your particular case: if you add another VLAN on one of switches (e.g. access port to VLAN 666), you don't have to configure trunk port explicitly ... on both switches. If you had a third switch, connected to one of existing switches with a trunk port with mvrp=yes, VLANs would "propagate" between all switches.
And that's the extent of "magic" you can expect to happen.
For trunk ports (interconnecting switches) MVRP is useful as it automatically adds any VLAN newly introduced on one of member switches.
So in your particular case: if you add another VLAN on one of switches (e.g. access port to VLAN 666), you don't have to configure trunk port explicitly ... on both switches. If you had a third switch, connected to one of existing switches with a trunk port with mvrp=yes, VLANs would "propagate" between all switches.
And that's the extent of "magic" you can expect to happen.
Statistics: Posted by mkx — Sun Jun 02, 2024 3:25 pm