Yes, the scenario in the second post in this topic should work for you if you change the setvid2fid and setfid2mstid commands. As long as you have one-to-one VLAN-to-FID limitation in your hardware, these two commands should be as follows:
These commands will result in the same VLAN-to-MSTI mapping as the original setup. You can check it by comparing Configuration Digest - it must have the same value:
So,in that case, I am afraid I am doing something wrong, but I dont know what. I have simplified things, and I have set MSTI 1- to vlan 2 and MSTI 2 to vlan 3.
Now my driver_deps code is empty, , so I only expect to have proper designations of each MSTI, however I dont get expected results in terms of port state for each MSTI.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello, Francis!
I've received your results. You have sent me the same data for the Switch 2 and Switch 3. Other than that I can't see anything suspicious - the resulting state of the switches with MAC xx:xx:xx:xx:01:02 and xx:xx:xx:xx:12:02 is OK for me. The state of the switch with MAC xx:xx:xx:xx:2F:44 is missing, though.
What is exactly your problem with that resulting state?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes. I am sorry, Switch 3 data is not correct. Anyway, by the moment things are not going as I expected, but I need more testing just to check if I am doing things the right way, just to avoiding precipitate conclusions.
Last edit: Vitalii Demianets 2012-07-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello!
The new result set is strange. Please, check the following:
1) you are using the latest mstpd revision (the latest revision in SVN is 33). In the revision 31 a crucial bug was fixed;
2) kernel bridge is in user-stp mode on all switches. To check it, issue the command "cat /sys/class/net/br0/bridge/stp_state" - the output must be "2". More on the topic see here: https://sourceforge.net/p/mstpd/discussion/general/thread/68c5f4c2/#7a3c/b3af
3) Switch2 is in the same MSTP Region as Swutch1 and Switch3. To check it, issue the command "# mstpctl showmstconfid br0" - the output must match exactly on all three switches. If some switch (switch2) is in the other MSTP Region - it could explain the observed results;
4) MSTP BPDUs from Switch2 are being observed on Switch1 and Switch3.If the STP BPUDs are not coming out or into Switch2 - it can explain the observed results. To accomplish this, enable debugging output in mstpd, for example: "mstpd -v3".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, that solves the mystery - Switch1 & Switch3 are in a different MSTP Region than Switch2.
Different configuration digest means VLAN-to-MSTI map in Switch2 differs from that map in other switches. mstpd do not have direct VLAN-to-MSTI map, instead it is derived from VLAN-to-FID map and FID-to-MSTI. To see those mappings, please issue the following commands on Switch2 and Switch1 and note the difference in outputs:
mstpctl showvid2fid br0
mstpctl showfid2mstid br0
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Gary!
Glad to know that mstpd works for you!
Regarding test: in general, any feedback from the real-world use is priceless.
The STP/RSTP part is reported to work reliably. The most untested part is 'M' in the MSTP, where multiple trees come in play. Ideally I would like to achieve UNH tests compliance (see "MSTP Operations Test Suite" and "MSTP Multi-System Interoperability Test Suite" on this page). But our world is not ideal; so, again, any feedback regarding real-world use is highly appreciated.
Also, there is one unsolved theoretical issue: should mstpd drop looped-back BPDUs or not? See this thread
It seems that IXIA ANVL test suite wants these BPDUs being dropped, but I don't like it for two reasons:
1) 802.1Q-2005 says that loopback test is not required (clause 14.4, NOTE 3)
2) If we drop looped-back BPDUs the port would remain in Forwarding state and bad things would happen. On the other hand, if we don't drop looped-back BPDUs, the port would go into Blocking (Backup/Discarding) state thus preventing the loop - and I like that.
What do you think of this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, the scenario in the second post in this topic should work for you if you change the setvid2fid and setfid2mstid commands. As long as you have one-to-one VLAN-to-FID limitation in your hardware, these two commands should be as follows:
These commands will result in the same VLAN-to-MSTI mapping as the original setup. You can check it by comparing Configuration Digest - it must have the same value:
So,in that case, I am afraid I am doing something wrong, but I dont know what. I have simplified things, and I have set MSTI 1- to vlan 2 and MSTI 2 to vlan 3.
mstpctl addbridge br0
mstpctl setmstconfid br0 0 CommonRegion
mstpctl createtree br0 1
mstpctl createtree br0 2
mstpctl setvid2fid br0 2:2
mstpctl setvid2fid br0 3:3
mstpctl setfid2mstid br0 1:2
mstpctl setfid2mstid br0 2:3
I expect switch 1, to be root of MST1 , switch 2, root of MST2, and switch 3, MST0. by setting
switch 1
mstpctl settreeprio br0 0 8
mstpctl settreeprio br0 1 7
mstpctl settreeprio br0 2 8
switch 2
mstpctl settreeprio br0 0 8
mstpctl settreeprio br0 1 8
mstpctl settreeprio br0 2 7
switch 3
mstpctl settreeprio br0 0 7
mstpctl settreeprio br0 1 8
mstpctl settreeprio br0 2 8
Now my driver_deps code is empty, , so I only expect to have proper designations of each MSTI, however I dont get expected results in terms of port state for each MSTI.
Your mstpctl command set looks OK.
Please, show me the output of the following commands for all three switches:
(Replace eth0 and eth1 with the actual names of the interfaces on your bridge)
You can send the requested output in private mail, I don't think it is appropriate for the forum
I think I need to do some test, Rechecking...
Last edit: Vitalii Demianets 2012-07-26
Hello, Francis!
I've received your results. You have sent me the same data for the Switch 2 and Switch 3. Other than that I can't see anything suspicious - the resulting state of the switches with MAC xx:xx:xx:xx:01:02 and xx:xx:xx:xx:12:02 is OK for me. The state of the switch with MAC xx:xx:xx:xx:2F:44 is missing, though.
What is exactly your problem with that resulting state?
Yes. I am sorry, Switch 3 data is not correct. Anyway, by the moment things are not going as I expected, but I need more testing just to check if I am doing things the right way, just to avoiding precipitate conclusions.
Last edit: Vitalii Demianets 2012-07-27
Hello!
The new result set is strange. Please, check the following:
1) you are using the latest mstpd revision (the latest revision in SVN is 33). In the revision 31 a crucial bug was fixed;
2) kernel bridge is in user-stp mode on all switches. To check it, issue the command "cat /sys/class/net/br0/bridge/stp_state" - the output must be "2". More on the topic see here: https://sourceforge.net/p/mstpd/discussion/general/thread/68c5f4c2/#7a3c/b3af
3) Switch2 is in the same MSTP Region as Swutch1 and Switch3. To check it, issue the command "# mstpctl showmstconfid br0" - the output must match exactly on all three switches. If some switch (switch2) is in the other MSTP Region - it could explain the observed results;
4) MSTP BPDUs from Switch2 are being observed on Switch1 and Switch3.If the STP BPUDs are not coming out or into Switch2 - it can explain the observed results. To accomplish this, enable debugging output in mstpd, for example: "mstpd -v3".
Configuration digest from switch 2 differs from the others, but I dont know the reason.
Ok, that solves the mystery - Switch1 & Switch3 are in a different MSTP Region than Switch2.
Different configuration digest means VLAN-to-MSTI map in Switch2 differs from that map in other switches. mstpd do not have direct VLAN-to-MSTI map, instead it is derived from VLAN-to-FID map and FID-to-MSTI. To see those mappings, please issue the following commands on Switch2 and Switch1 and note the difference in outputs:
I am afraid that I am getting identic results for vid2mid fid2mstid mapping in all (3) switches:
mstpctl showfid2mstid br0
br0 FID-to-MSTID allocation table:
MSTID 0: 0-1,4-4095
MSTID 1: 2
MSTID 2: 3
mstpctl showvid2fid br0
br0 VID-to-FID allocation table:
FID 0: 1,4-4094
FID 2: 2
FID 3: 3
So switch 2 must be in the same region, but for some other reason it is not.
Last edit: Francis 2012-07-30
Hi Vitalli
Have not posted for quite a while regarding MSTPD, as have been working on different things for past year.
The proposed scenario above works really well. No significant bugs. Is there any areas regarding test, you think possible bugs could be found.
Gary
Hello Gary!
Glad to know that mstpd works for you!
Regarding test: in general, any feedback from the real-world use is priceless.
The STP/RSTP part is reported to work reliably. The most untested part is 'M' in the MSTP, where multiple trees come in play. Ideally I would like to achieve UNH tests compliance (see "MSTP Operations Test Suite" and "MSTP Multi-System Interoperability Test Suite" on this page). But our world is not ideal; so, again, any feedback regarding real-world use is highly appreciated.
Also, there is one unsolved theoretical issue: should mstpd drop looped-back BPDUs or not? See this thread
It seems that IXIA ANVL test suite wants these BPDUs being dropped, but I don't like it for two reasons:
1) 802.1Q-2005 says that loopback test is not required (clause 14.4, NOTE 3)
2) If we drop looped-back BPDUs the port would remain in Forwarding state and bad things would happen. On the other hand, if we don't drop looped-back BPDUs, the port would go into Blocking (Backup/Discarding) state thus preventing the loop - and I like that.
What do you think of this?