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?I would assume a IVL/SVL change would result in a complete flush of the FDB.
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.... 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.... 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 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.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 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.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 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?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.
Thanks for the link, I hadn't seen that yet. Unfortunately, Edgars gives no reason for setting IVL.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:
I think that is what rule b (lines 28 and 29) of P802.1aq/D1.0+suggested changes is saying, i.e.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 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:[...] 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 [...]
This is on-topic, thanks.[...] 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. [...]
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.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)