Hello!

I have a question regarding the topic: Can I remotely change the IVL mode (turn it on) on a CRS switch (SwOS) without loosing connectivity to my network and necessity to go to my location assuming everything is working fine now?

I would assume a IVL/SVL change would result in a complete flush of the FDB.

... but that should not prevent management connection from resuming normally. The only effect should be some frame sent out to all ports (members of same VLAN) instead of only the correct one.

I would assume a IVL/SVL change would result in a complete flush of the FDB.

Yes, I am aware of this. The question is - how long will it take to rebuild separate databases (individual VLANs - 5s(?)) and if it eventually break my remote connectivity via VPN?

... but that should not prevent management connection from resuming normally. The only effect should be some frame sent out to all ports (members of same VLAN) instead of only the correct one.

If this disruption will take no more than a few seconds - it's fine. I want to do it remotely, during my VPN connection and don't want to cut out myself form switch management if something goes wrong and my network fails.

What is the reason for changing from SVL to IVL? In most normal cases, they behave the same.

What other switches are involved in the same "LAN". It seems to me that they should all be configured the same way

Normal case is no duplicate mac addresses, and symmetric vlans. If that's your case, then there shouldn't be a problem, but then why switch to IVL?

IVL will allow two different hosts using the same MAC address in different vlans from interfering with each other. For example two DECnet phase IV nodes with the same decnet address.

SVL will allow "asymmetric vlans", where untagged ethernet frames are transmitted on a different vlan than they are received on. Without SVL (i.e. if IVL is active), this causes problems for returning frames which haven't been learned in the vlan specific mac table, so those frames get flooded, and essentially turns the switch is to repeater for frames involved with asymmetric vlan hosts.

The point of the questions is that it is hard to guarantee how it will work in your environment. That's what lab testing is for.

For more info about the difference between IVL and SVL the following goole search will return useful links. ivl vs svl

... but that should not prevent management connection from resuming normally. The only effect should be some frame sent out to all ports (members of same VLAN) instead of only the correct one.

If this disruption will take no more than a few seconds - it's fine.

No guarantees ... but if my guess has any base in reality, then no interruption woukd occur. Only some flooding of ports until FDBs are populated again. If the switch is not switching at near full-capacity, this should not be a problem either.

What is the reason for changing from SVL to IVL? In most normal cases, they behave the same.
The point of the questions is that it is hard to guarantee how it will work in your environment. That's what lab testing is for.
For more info about the difference between IVL and SVL the following goole search will return useful links. ivl vs svl

I didn't expect the explanation of the technology and comparison of these two but practical approach based on someones personal experience. Anyway thanks and I will respond to your request as it may be helpful for other users.

My RB4011 (6.49.6) with SFP+ LAN interface connected directly to CRS326-24G-2S+ uses the same MAC addresses for all VLANs in a bridge. The practical meaning of such situation is obvious - in SVL you don't register VLAN-ID with the MAC address so the switch may be confused where to send packets. To eliminate such problem IVL must be used where you can have duplicated MAC addresses in separate databases.

The direct inspiration to my observation was the today's Mikrotik video with the same use example where the presenter ticks this setting. Please, have a look:
https://www.youtube.com/watch?v=38lR7UH51LY

No guarantees ... but if my guess has any base in reality, then no interruption woukd occur. Only some flooding of ports until FDBs are populated again. If the switch is not switching at near full-capacity, this should not be a problem either.

I think I will hold my horses as will be there in two days so will check changing this option on a live system (after hours) to see if it is possible and let you know. Of course I will have my backup and will be prepared to restore the system in case of failure but don't expect one.

My RB4011 (6.49.6) with SFP+ LAN interface connected directly to CRS326-24G-2S+ uses the same MAC addresses for all VLANs in a bridge. The practical meaning of such situation is obvious - in SVL you don't register VLAN-ID with the MAC address so the switch may be confused where to send packets. To eliminate such problem IVL must be used where you can have duplicated MAC addresses in separate databases.

I am not trying to cause an argument, I am just trying to learn. It isn't obvious to me that SVL would cause a problem with trunk links. If you don't have the same mac address duplicated on different interfaces, I don't see a problem. Can you please enlighten me with an explanation? How is your switch working now, if SVL would cause your switch to be confused?

The direct inspiration to my observation was the today's Mikrotik video with the same use example where the presenter ticks this setting. Please, have a look:
https://www.youtube.com/watch?v=38lR7UH51LY

Thanks for the link, I hadn't seen that yet. Unfortunately, Edgars gives no reason for setting IVL.

I am not claiming that IVL is bad, however it will usually not make any difference. Cisco switches use IVL (at least by default). My guess is that using IVL will use more mac table entries, although unless you have many hosts with multiple vlans, it probably won't be noticeable.

If you need IVL (due to having multiple interfaces with the same mac address), and you use a switch in SVL mode, it will cause issues that will be noticeable. Duplicate mac addresses on the same broadcast domain will cause problems.

Here are some other threads dealing with SVL vs IVL

Shared VLAN Learning (SVL) and Feature Request: Shared VLAN Learning (SVL)
moving bridge vlan to switch vlan to use hw offload specifically post #9 where MikroTik command line and WinBox defaults for IVL vs SVL mode being different is discussed.
"Independent Learning" on Switch VLAN but I can't explain post #3 I wonder if the mode was changed and the switch not rebooted. It is as if one port was in SVL mode (and using vlan id 0 as "global" setting) and the other in IVL with vlan 1. But that seems like abnormal behavior. Does anyone have an explanation?

For what it is worth, I have a CSS106-5G-1S with firmware 2.13 and when I unchecked IVL (which I had set specifically to allow duplicate mac addresses on separate vlans) but it is currently in use in a lab with no duplicate macs, I was able to uncheck and the only change I noticed was that it cleared the mac table (which quickly refilled) and the "Hosts" tab VLAN ID column changed from 1 to blanks. Switching back by clicking the Independent VLAN Lookup and clicking Apply All returned it to IVL and displaying vlan id 1 for all host mac addresses.

So if your switch behaves similarly and there are no asymmetric vlans, I would not expect any problems.

I can think of one case where IVL performs better than SVL ...

Usually all VLANs over single physical interface will use same MAC address. Now if one creates multiple paths for packets and some VLANs take one path, some the other one (e.g. by using redundant links and employing MSTP), then with SVL packets of some VLANs might take the wrong egress interface (because switch might have learned egress interface from packets with different VLAN ID). With IVL egress interface will be selected correctly because FDB contains multiple egress ports for same MAC address (one per VLAN learned).

Or something like this, I never tried if my explanation reflects reality

Now if one creates multiple paths for packets and some VLANs take one path, some the other one (e.g. by using redundant links and employing MSTP), then with SVL packets of some VLANs might take the wrong egress interface (because switch might have learned egress interface from packets with different VLAN ID). With IVL egress interface will be selected correctly because FDB contains multiple egress ports for same MAC address (one per VLAN learned).

I think that is what rule b (lines 28 and 29) of P802.1aq/D1.0+suggested changes is saying, i.e.

"b) A VID that is allocated to the CIST, or an MSTI, or an SPT Set, has to map to a different FID from
any VID allocate to another of those active topologies."

That's why I asked @Panbambaryla why he wanted to change from SVL to IVL. There could be good reasons.

A quote from George Pólya's book How To Solve It "It is foolish to answer a question that you do not understand. It is sad to work for an end that you do not desire." So be sure to give enough infomation so we understand the problem and your requirements.

Dear @Buckeye,

you've made a fork of this discussion. Please, get back to the OP and try to answer my question. I am not asking for technology explanation, comparison and other discussion regarding this only simple information if it is going to break my connectivity. Fortunately I will be able to test it onsite tomorrow and I will let you know.

IMO you got your answers in the first two replies. The rest of discussion is partially on you since you kept pushing for clarifications which possibly nobody around here is able to give you because of nature of the "problem" you're expecting (could be the problem is nonexistant and thus nobody observed anything weird to comment or warn you about or the problem is transitional with short time to auto-cure and again nobody observed anything worth mentioning about it).

Just to comment on your question asked in post #4: blank FDB doesn't mean service interruption, it may mean service degradation (if too much traffic gets flooded through switched ports). Time to "fix" it is in most cases very short (until a frame in opposite direction arrives, for intense duplex communication that means a fraction of a millisecond) and very likely nobody will ever notice that. Unless switch chip freezes during switch between SVL and IVL, which would depend on particular switch chip used in your switch device. My experience is that AR8327 switch chip does it really smooth, but can't say anything about other switch chips.

[...] The rest of discussion is partially on you since you kept pushing for clarifications which possibly nobody around here is able to give you because of nature of the "problem" you're expecting [...]

I am not pushing just clarifying what I need regarding network disruption but not technology itself. I understand the common lack of information but in the next part you give it to me:

[...] Just to comment on your question asked in post #4: blank FDB doesn't mean service interruption, it may mean service degradation (if too much traffic gets flooded through switched ports). Time to "fix" it is in most cases very short (until a frame in opposite direction arrives, for intense duplex communication that means a fraction of a millisecond) and very likely nobody will ever notice that. Unless switch chip freezes during switch between SVL and IVL, which would depend on particular switch chip used in your switch device. My experience is that AR8327 switch chip does it really smooth, but can't say anything about other switch chips. [...]

This is on-topic, thanks.

Confirmed - in my case I could do this without any service disruption. Thanks for all of your support.

is it possible to get this option on CSS610 ? I have a problem with automatic mac learning on that switch because same src mac is broadcast on multiple ports (which are on different vlans)

The CSS610 reportedly uses the same Marvell 88E6393X as is used in the RB5009.

The manual for the CSS610 explicitly says that IVL is not supported. Whether that is a chip limitation or a software/firmware limitation, I don't know. see CSS610 series Manual Summary
------
SwOS Lite is an operating system designed specifically for the administration of MikroTik CSS610 series switch products. CSS610 series switches support only SwOS Lite operating system.

The main differences compared to CSS3xx series switches are:

unsupported Independent VLAN Learning;
unsupported VLAN mode "enabled";
unsupported ACL Rate limiting;
supported Port Egress Rate limiting
-----
The ROS manual doesn't have any footnote warnings in the VLAN Table section specifically about IVL, all it has is that you can't use the /interface ethernet switch vlan related items from the menu.

Whether that applies to independent-learning (no | yes; Default: yes) Whether to use shared-VLAN-learning (SVL) or independent-VLAN-learning (IVL). I don't know. I have no devices with the 88E6393X switch chip.

Very strange especially since ROS devices cannot override the MAC address for created VLAN interfaces, they always use the parent interface's MAC, so the same MAC will appear on different VLANs (if you want to change MAC address of a VLAN, you have to make a new bridge and then put the vlan interface into it, which forces everything into software mode and slows it all down considerably)

Very strange especially since ROS devices cannot override the MAC address for created VLAN interfaces, they always use the parent interface's MAC, so the same MAC will appear on different VLANs (if you want to change MAC address of a VLAN, you have to make a new bridge and then put the vlan interface into it, which forces everything into software mode and slows it all down considerably)

Perhaps my description wasn't the best. What I meant is two devices with the same mac address. The case that I have experience with is DECnet Phase IV which has its own ethertype 6003 (hex). DECnet Phase IV over ethernet maps DECnet Area/node numbers into a MAC address, and reprograms the ethernet adapter during boot with the "spoofed" MAC address. This normally isn't a problem, because you can't have multiple nodes in a DECnet network with the same DECnet address. But if you have a "clone" of a set of nodes in a "test environment", and the only connection between the two is via IP, you can use NAT twice to allow overlapping networks where each side thinks the other side is using a different IP address. And everything works fine if you use separate switches for the test and prod "clusters", but if you try using separate vlans on a switch that only supports SVL, it will cause problems (switch will see the mac address changing ports frequently, and it will cause flooding). It doesn't break DECnet, it just turns the switch is to a non-filtering bridge for the vlans involved, i.e. if will be similar to using a hub from a traffic point of view.

That won't happen in the case of the bridge, even if it is using the same "management" mac address on multiple vlans. What would be a problem would be two RourterBoards spoofing the same MAC for the two individual bridges.

my problem was that i have a ISP router where different LAN ports bridge to different networks (Routed, IPTV, VOICE, PPPoE), yet the stupid thing has "loopback detection" which it does by broadcasting a packet with a 0xFFFA ethertype on all the ports every 5s... the problem is the source mac on all the ports for that is the same as the one it uses for its gateway for the Routed LAN, so without independent VLAN learning, that mac flip flops between the ports every 5s, leading to packet loss.
a mikrotik ROS with different VLANs with the same mac would probably be fine... but only if all those VLANs are on the same TRUNK PORT going to the CSS610

I don't have anything with the Marvell 88E6393X switch chip (neither CSS610 or RB5009). Since this is a relatively new chip, it seems odd it wouldn't have the capability to do IVL, but I suppose it is possible.

I think is is more likely that the SwOS lite software is too limited in what "features" it exposes, but that's only a guess. I wish Edgars was on the forum, as he should be able to answer that question (What is limiting the CSS610 to SVL and not allowing IVL to be chosen? Is it SwOS firmware of 88E6393X limitation?)