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.
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?
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
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 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
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.
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?
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 
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.
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:
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)