Does this line indicate a problem.
2012-07-09 10:32:34 MSTP_IN_create_msti: br0 MSTID(11) is already in the list
The sequence followed is
mstpctl creatree br0 1
mstpctl creatree br0 2 # Debug output only show on this tree
Yes, there is some problem. It seems that mstpd actually receives command for creating tree with ID 11 for the both of your commands. Please, do the following:
and check the output of the last command. It should show you the tree with MSTID = 1, and not 11. If it shows the tree with MSTID = 11 then something weird is going on and we will need further debug.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is it possible to use mstpd without the custom driver_deps code. Does the algorithm work without this. I have written allot of code lately for configuring the VLANs STU, ATU, user space scripts and tools. This is largely untested and taking some time to debug. It would nice to be able to unit test each individual component to help with the debugging the system. It would be nice to see the algorithm work minus configuring port states on the physical switch etc. I have read somewhere on this forum that this is possible, and was wondering how it works in practice.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, the algorithm does not rely on the actual state of ports. If you don't set the port states in hardware, algorithm won't notice.
There is still a danger, though: broadcast storms. If you have a physical loop in your topology and did not prevent it by setting "blocking" state on some ports with the help of mstpd - you'll get a broadcast storm in that loop. And this storm can block transition of the MSTP BPDUs - there might be no bandwidth left for them.
Last edit: Vitalii Demianets 2012-07-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for you help. Have been experiencing broadcast storms when playing about with different configurations, even with my driver deps enabled. Obviously driver deps has few bugs to be ironed out. Also difficult to debug with a broadcast storm in progress. Think it best to create a test app to hammer, the changing port states.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My driver seems to be working correctly now. Fixed a couple of issues with the STU port state setting.
Possible Logical Issue on Setup
mstpctl addbridge br0
This command attempts to set the state of the ports that are members of the bridge before a createtree command has added the Entry to the STU.
012-07-13 10:34:49 create_if: Add iface fa1_0 as port#1 to bridge br0
2012-07-13 10:34:49 MSTP_OUT_set_state: br0:fa1_0:0 entering blocking state
2012-07-13 10:34:49 MSTP_OUT_flush_all_fids: br0:fa1_0:0 Flushing forwarding database
2012-07-13 10:34:49 MSTP_OUT_set_state: br0:fa1_0:0 entering blocking state
br0:fa1_0:0 means Bridge = "br0", Interface = "fa1_0", MSTI tree ID (MSTID) = 0.
Tree with MSTID=0 is a special case - it even has its own name: CIST. This tree always exists, can not be created and deleted manually; it is created automatically when the bridge is created inside mstpd.
-
I think it must be in documentation (when it will be created ;) That's what I've forgotten to tell you - the tree with MSTID=0 must be pre-created in your driver before it starts working with mstpd.
-
Not sure what the expected behaviour is here.
mstpctl setmstconfid br0 0 CommonRegion
mstpctl createtree br0 1
mstpctl createtree br0 2
mstpctl setvid2fid br0 777:10,100,200 999:20,30,40
mstpctl setfid2mstid br0 1:777 2:99
I am equally not sure what do you want to know ) Please, elaborate your question.
mstpctl setmstconfid br0 0 CommonRegion
The command above tells mstpd to which MSTP Region the bridge belongs. All bridges in the same MSTP Region must have the same configuration. In the command above we tell mstpd that Region name is "CommonRegion" and configuration revision is 0. All other bridges that want to be in the same Region should use exactly the same name, revision number and VLAN-to-MSTI map.
Set VLAN-to-FID mapping: VLANs 10, 100 and 200 belongs to the FID 777 while VLANs 20, 30 and 40 belongs to the FID 999. All other VLANs keep their VLAN-to-FID mapping intact. If you haven't changed the mapping it will remain in default state, namely all the other VLANs belongs to the FID 0.
mstpctl setfid2mstid br0 1:777 2:99
Set FID-to-MSTI mapping: FID 777 with all its VLANs (10,100,200) belongs to the MSTI with MSTID 1 while FID 99 with all its VLANs (20,30,40) belongs to the MSTI with MSTID 2. All other FIDs keep their FID-to-MSTI mapping intact. If you haven't changed the mapping it will remain in default state, namely all the other FIDs belongs to the CIST (MSTI with MSTID = 0)
Both setvid2fid and setfid2mstid commands create VLAN-to-MSTI mapping which must be the same for all bridges across one MSTP Region, In the example above two commands have created the following mapping:
* VLANs 10, 100 and 200 belong to the MSTI with MSTID 1
* VLANs 20, 30 and 40 belong to the MSTI with MSTID 2
* All the other VLANs belong to the default MSTI = CIST (MSTID = 0).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Vitali
When creating a tree. Usually with the creation of the second unique tree use see the following output
2012-07-09 10:32:34 CTL_create_msti: CREATE MSTI
2012-07-09 10:32:34 CTL_create_msti: CREATE MSTI
2012-07-09 10:32:34 CTL_create_msti: CREATE MSTI
2012-07-09 10:32:34 CTL_create_msti: CREATE MSTI
the return value is 100
2012-07-09 10:32:34 MSTP_IN_create_msti: br0 MSTID(11) is already in the list
Server Socket rcv message
2012-07-09 10:32:34 CTL_create_msti: CREATE MSTI
2012-07-09 10:32:34 CTL_create_msti: CREATE MSTI
2012-07-09 10:32:34 CTL_create_msti: CREATE MSTI
2012-07-09 10:32:34 CTL_create_msti: CREATE MSTI
Does this line indicate a problem.
2012-07-09 10:32:34 MSTP_IN_create_msti: br0 MSTID(11) is already in the list
The sequence followed is
mstpctl creatree br0 1
mstpctl creatree br0 2 # Debug output only show on this tree
Yes, there is some problem. It seems that mstpd actually receives command for creating tree with ID 11 for the both of your commands. Please, do the following:
and check the output of the last command. It should show you the tree with MSTID = 1, and not 11. If it shows the tree with MSTID = 11 then something weird is going on and we will need further debug.
Issue resolved not a bug in your code, down to my configuration scripts
Last edit: Gary 2012-07-10
Is it possible to use mstpd without the custom driver_deps code. Does the algorithm work without this. I have written allot of code lately for configuring the VLANs STU, ATU, user space scripts and tools. This is largely untested and taking some time to debug. It would nice to be able to unit test each individual component to help with the debugging the system. It would be nice to see the algorithm work minus configuring port states on the physical switch etc. I have read somewhere on this forum that this is possible, and was wondering how it works in practice.
Yes, the algorithm does not rely on the actual state of ports. If you don't set the port states in hardware, algorithm won't notice.
There is still a danger, though: broadcast storms. If you have a physical loop in your topology and did not prevent it by setting "blocking" state on some ports with the help of mstpd - you'll get a broadcast storm in that loop. And this storm can block transition of the MSTP BPDUs - there might be no bandwidth left for them.
Last edit: Vitalii Demianets 2012-07-11
Thanks for you help. Have been experiencing broadcast storms when playing about with different configurations, even with my driver deps enabled. Obviously driver deps has few bugs to be ironed out. Also difficult to debug with a broadcast storm in progress. Think it best to create a test app to hammer, the changing port states.
My driver seems to be working correctly now. Fixed a couple of issues with the STU port state setting.
Possible Logical Issue on Setup
mstpctl addbridge br0
This command attempts to set the state of the ports that are members of the bridge before a createtree command has added the Entry to the STU.
012-07-13 10:34:49 create_if: Add iface fa1_0 as port#1 to bridge br0
2012-07-13 10:34:49 MSTP_OUT_set_state: br0:fa1_0:0 entering blocking state
2012-07-13 10:34:49 MSTP_OUT_flush_all_fids: br0:fa1_0:0 Flushing forwarding database
Not sure what the expected behaviour is here.
mstpctl setmstconfid br0 0 CommonRegion
mstpctl createtree br0 1
mstpctl createtree br0 2
mstpctl setvid2fid br0 777:10,100,200 999:20,30,40
mstpctl setfid2mstid br0 1:777 2:999
br0:fa1_0:0 means Bridge = "br0", Interface = "fa1_0", MSTI tree ID (MSTID) = 0.
Tree with MSTID=0 is a special case - it even has its own name: CIST. This tree always exists, can not be created and deleted manually; it is created automatically when the bridge is created inside mstpd.
-
I think it must be in documentation (when it will be created ;) That's what I've forgotten to tell you - the tree with MSTID=0 must be pre-created in your driver before it starts working with mstpd.
-
I am equally not sure what do you want to know ) Please, elaborate your question.
The command above tells mstpd to which MSTP Region the bridge belongs. All bridges in the same MSTP Region must have the same configuration. In the command above we tell mstpd that Region name is "CommonRegion" and configuration revision is 0. All other bridges that want to be in the same Region should use exactly the same name, revision number and VLAN-to-MSTI map.
Create MSTIs with MSTID 1 and 2.
Set VLAN-to-FID mapping: VLANs 10, 100 and 200 belongs to the FID 777 while VLANs 20, 30 and 40 belongs to the FID 999. All other VLANs keep their VLAN-to-FID mapping intact. If you haven't changed the mapping it will remain in default state, namely all the other VLANs belongs to the FID 0.
Set FID-to-MSTI mapping: FID 777 with all its VLANs (10,100,200) belongs to the MSTI with MSTID 1 while FID 99 with all its VLANs (20,30,40) belongs to the MSTI with MSTID 2. All other FIDs keep their FID-to-MSTI mapping intact. If you haven't changed the mapping it will remain in default state, namely all the other FIDs belongs to the CIST (MSTI with MSTID = 0)
Both setvid2fid and setfid2mstid commands create VLAN-to-MSTI mapping which must be the same for all bridges across one MSTP Region, In the example above two commands have created the following mapping:
* VLANs 10, 100 and 200 belong to the MSTI with MSTID 1
* VLANs 20, 30 and 40 belong to the MSTI with MSTID 2
* All the other VLANs belong to the default MSTI = CIST (MSTID = 0).