# If the bridge was not automagically added via bridge-stp kernel helper script
mstpctl addbridge br0
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
# Check that digest is correct
# The ouput of the following command should be:
#br0 MST Configuration Identifier:
# Format Selector: 0
# Configuration Name: CommonRegion
# Revision Level: 0
# Configuration Digest: E9DBF7A5EC631463B160238CA488E10C
mstpctl showmstconfid br0
# If you have another value for the digest, re-check
# VID-to-FID and FID-to-MSTI mappings.
# The output of the following 2 commands should be:
#br0 VID-to-FID allocation table:
# FID 0: 1-9,11-19,21-29,31-39,41-99,101-199,201-4094
# FID 777: 10,100,200
# FID 999: 20,30,40
#
# and:
#br0 FID-to-MSTID allocation table:
# MSTID 0: 0-776,778-998,1000-4095
# MSTID 1: 777
# MSTID 2: 999
mstpctl showvid2fid br0
mstpctl showfid2mstid br0
# Just to be sure, set the same internal path cost for all ports in all MSTIs
# Such a scheme with equal path costs will yield the desired topology.
mstpctl settreeportcost br0 eth1 0 10
mstpctl settreeportcost br0 eth2 0 10
mstpctl settreeportcost br0 eth1 1 10
mstpctl settreeportcost br0 eth2 1 10
mstpctl settreeportcost br0 eth1 2 10
mstpctl settreeportcost br0 eth2 2 10
Switch1:
# To ensure that Switch1 is Regional Root for the MSTI-1, lower its priority a bit in this tree.
mstpctl settreeprio br0 0 8
mstpctl settreeprio br0 1 7
mstpctl settreeprio br0 2 8
Switch2:
# To ensure that Switch2 is Regional Root for the MSTI-2, lower its priority a bit in this tree.
mstpctl settreeprio br0 0 8
mstpctl settreeprio br0 1 8
mstpctl settreeprio br0 2 7
Switch3:
# To ensure that Switch3 is Root and Regional Root for the MSTI-0, lower its priority a bit in this tree.
mstpctl settreeprio br0 0 7
mstpctl settreeprio br0 1 8
mstpctl settreeprio br0 2 8
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is great still have a bit of work todo in implementing the driver deps, as still getting my head around what needs to be done, before embarking on the code
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have implemented 95% of the driver code and driver deps just need to add the age time, MDIO riegister writes, and should be good to go. Have not had a chance to begin testing yet. I am away for the next two weeks but will let you know how the testing goes once I get back, thanks for your help till now
Gary
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello, Gary!
Please, do not expect from the code correct behaviour in all situations, as the most cases are mainly utested. I've assigned "alpha" status to this project for reason.
That's why I'm looking forward to get the test results from you. The more people utilize the code, the more bugs are fixed.
Have a nice time!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Does the command setfid2mstid map the 777 and the 999 to the FID entries in the STU
mstpctl setfid2mstid br0 1:777 2:999
In addition to the commands above when creating VLANS with a Marvel switch you will the add the appropriate FID to map to make switch aware of what VLANs belong to what tree instance.
VLANS 10,100,200 with FID 1
VLANS 20 30 40 with FID 2
Last edit: Vitalii Demianets 2012-07-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
mstpctl createtree commands will add two entries to the STU database on the Marvel switch. The FID ID for commands below will be 1 and 2.
mstpctl createtree br0 1
mstpctl createtree br0 2
Not quite. These commands create trees (aka MSTIs) with MSTID 1 and 2 inside mstpd. Also invocation of these commands will result in call to the driver_create_msti() function in driver_deps.c file. You can put code in that function which will instruct your driver to add new SID to the STU.
Note 1: SID in the Marvell hardware can differ from MSTID. After all, MSTIDs are 12-bit wide and SIDs are 6-bit wide. You just should keep the mapping table between SIDs and MSTIDs.
Note 2: You can completely ignore driver_create_msti() function and leave it empty. In that case you should add SIDs to the STU by other means.
-
The mstpctl option setvid2fid is used for what? What is the meaning of the values 777 and 999.
mstpctl setvid2fid br0 777:10,100,200 999:20,30,40
setvid2fid command maps VIDs (VLANs) to the FIDs (forwarding information databases). In other words it tells mstpd which VLANs belong to which FID. In the above example the command tells mstpd: "VLANs 10, 100 and 200 belong top the FID 777 and VLANs 20 30 and 40 belong to the FID 999. And all other VLANs keep their FID mapping as it was before the command invocation".
As for the particular numbers 777 and 999: I have chosen completely random numbers for the FIDs. These numbers have meaning only to the mstpd. They do not have meaning for the other network nodes as FIDs are local to the given network node.
Note 1: mstpd DO NOT communicate FIDs with driver. This command sets the VID-to-FID mapping ONLY inside mstpd. The corresponding mapping in VTU you should do by other means by yourself with no help from mstpd!
Note 2: FID numbers inside Marvell's VTU can differ from FID numbers inside mstpd as long as you keep translation map for that. But in this case I really see no reason to do that. It is logical to programm VTU with the same FIDs as you do with mstpd by the means of setvid2fid command.
-
Does the command setfid2mstid map the 777 and the 999 to the FID entries in the STU
mstpctl setfid2mstid br0 1:777 2:999
setfid2mstid command maps FIDs to the MSTIs (trees). In other words it tells mstpd which FIDs belong to which MSTI. In the above example the command tells mstpd: "FID 777 with all its VLANs belong to the MSTI with MSTID=1 and FID 999 with all its VLANs belong to the MSTI with MSTID=2. And all other FIDs kepp their MSTI mapping as it was before the command invocation". Taking in account that FID 777 contains VLANs 10, 100 and 200 (as set by previous setvid2fid command) we have mapped these VLANs 10, 100 and 200 to the MSTI with MSTID=1. In the same way VLANs 20,30 and 40 are now mapped to the MSTI with MSTID=2.
Note 1: mstpd DO NOT communicate this mapping with driver! This command sets the FID-to-MSTID mapping ONLY inside mstpd. The mapping of VIDs to SIDs inside VTU you should do by other means by yourself with no help from mstpd!
Note 2: Marvell directly maps VIDs to SIDs in VTU. It does not use FIDs for this purpose, unlike mstpd, which do this mapping as: VIDs->FIDs->\MSTIDs. Also note that VID-to-SID mapping is done in VTU, not STU!
-
In addition to the commands above when creating VLANS with a Marvel switch you will the add the appropriate FID to map to make switch aware of what VLANs belong to what tree instance.
VLANS 10,100,200 with FID 1
VLANS 20 30 40 with FID 2
First, you have messed up here FIDs with MSTIDs.
Second, as I noted earlier, mstpd will not help you in any way to set VLAN-to-MSTI (VLAN-to-SID) mapping inside driver. You should do it by other means.
The commands setvid2fid and setfid2mstid set that mapping only inside mstpd.
The best way to accomplish the task is to instruct your driver to set that mapping in the same script which calls "mstpctl setvid2fid" and "mstpctl setfid2mstid".
-
Hope, it all is a bit clearer now.
Don't hesitate to ask if something is not clear ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually meant to say SID and not FID on the post above. This is much clearer. I
should be in a position to test now. I have implemented the following functionality
let me know if I am missing something or have done something stupid. Will begin testing
1. Driver Deps:
i) driver_set_new_state: Function passees 3 parameters to the kernel.
port_name, mstid, new_state. This will modidy the appropriate
entry in the STU. The MSTID is the SID used to locate the entry in
the database
ii) driver_create_msti: Function passes 1 paramater the MSTID to the
kernel which will create and STU entry with this as the SID.
iii) driver_delete_msti: Function passes 1 paramater the MSTID to the
kernel which will delete this entry from the STU
iv) driver_set_aging_time: Function takes no Parameters:
Returns the ageing time from the driver which is gloabally set value
on the switch. This is configured externally from the MSTPD
v) driver_flush_all_fids: Function passes 1 parameter the FID which
is used to Flush all Addresses from the ATU for this database.
2. DSA Driver which exports each port on switch as a Linux Netdevice.
3. External Script\app. To create the VLANS and SID mappings for the VLANS
Last edit: Gary 2012-07-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1 :
I) Ok
II) Ok
III) Ok
IV) First, please download new code revision from SVN. The latest revision is 32. The change makes driver_set_aging_time() function to set ageing time per port. As long as Marvell does not support such functionality it is ok to ignore the prt parameter of the function and set ageing time for the whole bridge.
Also, I do not understand why you have written "no Parameter" here. This function must pass at least 1 parameter to the driver - new ageing time. Ideally it will pass two parameters - port and new ageing time, but in our case we can ignore port parameter as Marvell does not support setting per-port ageing times.
And this MAY NOT be configured externally to the mstpd. mstpd must know which ageing time you have configured.
I think this function needs more explanation. Its purpose is to do the "rapid ageing" which is the STP-specific way of purging MAC entries. When mstpd is in STP mode, it uses "rapid ageing" - temporarily sets ageing time to some low value to age out MAC entries from the learning table. When mstpd is in {R|M}STP mode, it uses driver_flush_all_fids() for the same purpose. That is required by standard to keep backward compatibility with old STP-only implementations.
V) I suppose that function "passes 1 parameter - the FID" but does it multiply times - one for each FID in given MSTI.
-
2 Ok
3 Ok
And general remark: MSTID = SID is Ok for testing, but unacceptable in production, because you can not control which MSTIDs are set on other switches in network. So, in future you should develop some kind of mapping 12-bit MSTIDs into 6-bit SIDs,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Got confused with the driver_set_ageing_time. My first thoughts were correct in that it used to set the ageing time on the switch. The confusion came from the the fact the "ageing time is returned from the the STUB, presumed it was retrieved from the driver to set the ageing time on the MSTPD" which is incorrect.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, it is used to set ageing time in hardware. The returned value shows which actual ageing time is set. For example, LinkStreet (at least my part) can not set ageing time with 1 sec granularity. If mstpd requested it to set 20 seconds, the best it could do is 15 seconds. So, the return value informs what actual ageing time was set in hardware.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Issue with configuration when trying to set the tree port cost.
error, CTL_set_msti_port_config: br0 Couldn't find port with index
CTL_set_msti_port_config: Got return code 0, -1
br0 Couldn't find port with index 6
Here is the command sequence I follow.
OK brctl addbr br0
OK brctl addif fa1_6 fa1_0
OK ./mstpctl setmstconfid br0 0 CommonRegion
OK ./mstpctl createtree br0 1
OK ./mstpctl createtree br0 2
OK ./mstpctl setvid2fid br0 777:10,100,200 999:20,30,40
OK ./mstpctl setfid2mstid br0 1:777 2:999
FAIL./mstpctl settreeportcost br0 fa1_6 0 10
FAIL../mstpctl settreeportcost br0 fa1_0 0 10
FAIL../mstpctl settreeportcost br0 fa1_6 1 10
FAIL../mstpctl settreeportcost br0 fa1_0 1 10
FAIL../mstpctl settreeportcost br0 fa1_6 2 10
FAIL../mstpctl settreeportcost br0 fa1_0 2 10
Note: fa1_6 and fa1_0 are DSA Netdevice representing two ports
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Its working now. You can add multiple interfaces from a single brctl addif.
however your assumption was correct in that the interfaces were not added to the
bridge correctly and that why it was failing
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some debugging tips or set up tips for anyone else who wishes to use MSTPD. If you see the following error message
Error in bridge_bpdu_rcv at bridge_track.c:380 verifying ifc->sysdeps.up.
2000-03-04 21:58:17 Error in bridge_bpdu_rcv at bridge_track.c:380 verifying ifc->sysdeps.up.
Just ensure each interface and bridge is up with ifconfig. All interface of the bridge are in a Running State
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To begin with, interface shouldn't be receiving a frame when it is not UP or not Running. The fact that you did receive the frame while interface is not UP shows that your hardware driver haven't done its job - it was to shut PHY down ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A case off adding the commands manually on three different switches and forgetting to insmod the mstpd module. But still I have problem with my driver. Say if you bring down the bridge using
ifconfig br0 down should this in turn cause and event in the mstpd to tell the HW to shutdown via the driver deps??
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have problem caused from this. Sequence [root@switch userscripts]# ifconfig br0 down
br0: port 2(fa1_6) entering disabled state
br0: port 1(fa1_0) entering disabled state
br0: topology change detected, propagating
22: br0 Down mtu 1500
2000-03-05 00:10:35 set_br_up: br0 was up
2000-03-05 00:10:35 set_br_up: Set bridge br0 down
[root@switch userscripts]# 2000-03-05 00:10:36 MSTP_IN_rx_bpdu: br0:fa1_0 Received BPDU while bridge is disabled
2000-03-05 00:10:38 MSTP_IN_rx_bpdu: br0:fa1_0 Received BPDU while bridge is disabled
2000-03-05 00:10:40 MSTP_IN_rx_bpdu: br0:fa1_0 Received BPDU while bridge is disabled
If I then bring the bridge back up. The state change is detected the following happens [root@switch userscripts]# ifconfig br0
2000-03-05 00:13:41 MSTP_OUT_set_state: br0:fa1_6:0 entering learning state
2000-03-05 00:13:41 MSTP_OUT_set_state: br0:fa1_6:1 entering learning state
2000-03-05 00:13:42 MSTP_OUT_set_state: br0:fa1_6:1 entering forwarding state
2000-03-05 00:13:42 MSTP_OUT_set_state: br0:fa1_6:2 entering forwarding state
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Don't see any problem here, except that your driver did not put hardware ports into disabled state - and that's why all those warnings "Received BPDU while bridge is disabled". Is this the problem which bothers you? Then, as I stated in previous post (which is located below) - simply do not put br0 down ;) What for do you want to put it down? There must be another way of accomplishing your task.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
if you bring down the bridge using
ifconfig br0 down should this in turn cause and event in the mstpd to tell the HW to shutdown via the driver deps??
-
1. Why do you want to bring that bridge down? Remember, that br0 is not a real bridge - it does not frame switching, real switching is in hardware. We create it for the technical purposes ONLY - it does not represent something t all, It is just an auxiliary tool. It is supposed to be UP all the time. Here is a list of useful thing you can do with it:
* Enslave interface to it - if you want to mstpd work with that interface. It is a way to say "Enable MSTP on the interface";
* Remove interface from it = "Disable MSTP on the interface"
* Disable stp on it = "Disable MSTP on the whole bridge".
That's all you should ever do with it.
2. You obviously wanted to accomplish some task by bringing br0 down, Let's find another way of accomplishing that task. For example, if you want to shut down hardware switch, you could send the special command to your driver.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Im just been a dumb user playing around with the tools to become familiar with the whole setup. The MSTPD is listening to ifconfig br0 up. When this event occurs it calls the change driver state. When doing the opposite i.e. ifconfig br0 down, an event is not triggered to bring the ports states down.
Going to look at my other driver deps issue with netlink resources been busy. Will Iron out all these issues first. This is possibly causing problems you have not seen before with it been un-chattered waters.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Im just been a dumb user playing around with the tools to become familiar with the whole setup
Ok. Playing with things sounds like a good way to learn ;) So, the bottom line - the linux bridge (br0) simply is not supposed to be brought down. There is no special support in driver_deps for that, because it serves no purpose; at least I can't imagine any useful purpose.
Going to look at my other driver deps issue with netlink resources been busy
I'm looking forward for the results. Feel free to ask for any assistance you need.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What is your concern: why it prints on the console or why it prints it at all?
The answer to the second question (why it prints it at all) can be found in the log. I hope, in the context of other messages it would be clear why Topolgy Change Machine wants to flush learned MACs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to start testing your code. It looks excellent, and thanks for sharing it with the community.
What Commands would I need to enter to configure the MSTP Network below
Multiple Spanning Tree Instance Mapping MSTI1 +++++ Has VLANS 10 100 200 to MSTI2 ***** Has VLANS 20 30 40 to |-------------| |--------------| | Switch1 |+++++++++++++++++++++ | Switch2 | | root MSTI1 |********************* | root MSTI2 | |-------------| |--------------| + * + * + * + |--------------| * ++++++++++++| Switch 3 |************* | MIST0 | |--------------| IST (Internal Spanning Tree aka MSTI0)Here is the list of commands for your topology:
Common config, for all switches:
Switch1:
Switch2:
Switch3:
This is great still have a bit of work todo in implementing the driver deps, as still getting my head around what needs to be done, before embarking on the code
Hi Vitali
I have implemented 95% of the driver code and driver deps just need to add the age time, MDIO riegister writes, and should be good to go. Have not had a chance to begin testing yet. I am away for the next two weeks but will let you know how the testing goes once I get back, thanks for your help till now
Gary
Hello, Gary!
Please, do not expect from the code correct behaviour in all situations, as the most cases are mainly utested. I've assigned "alpha" status to this project for reason.
That's why I'm looking forward to get the test results from you. The more people utilize the code, the more bugs are fixed.
Have a nice time!
Some basic questions below but the posts on the forum should also help anyone else who wishes to use MSTPD in a Marvel environment.
mstpctl createtree commands will add two entries to the STU database on the Marvel switch. The FID ID for commands below will be 1 and 2.
mstpctl createtree br0 1
mstpctl createtree br0 2
The mstpctl option setvid2fid is used for what? What is the meaning of the values 777 and 999.
mstpctl setvid2fid br0 777:10,100,200 999:20,30,40
Does the command setfid2mstid map the 777 and the 999 to the FID entries in the STU
mstpctl setfid2mstid br0 1:777 2:999
In addition to the commands above when creating VLANS with a Marvel switch you will the add the appropriate FID to map to make switch aware of what VLANs belong to what tree instance.
VLANS 10,100,200 with FID 1
VLANS 20 30 40 with FID 2
Last edit: Vitalii Demianets 2012-07-04
Not quite. These commands create trees (aka MSTIs) with MSTID 1 and 2 inside mstpd. Also invocation of these commands will result in call to the driver_create_msti() function in driver_deps.c file. You can put code in that function which will instruct your driver to add new SID to the STU.
Note 1: SID in the Marvell hardware can differ from MSTID. After all, MSTIDs are 12-bit wide and SIDs are 6-bit wide. You just should keep the mapping table between SIDs and MSTIDs.
Note 2: You can completely ignore driver_create_msti() function and leave it empty. In that case you should add SIDs to the STU by other means.
-
setvid2fid command maps VIDs (VLANs) to the FIDs (forwarding information databases). In other words it tells mstpd which VLANs belong to which FID. In the above example the command tells mstpd: "VLANs 10, 100 and 200 belong top the FID 777 and VLANs 20 30 and 40 belong to the FID 999. And all other VLANs keep their FID mapping as it was before the command invocation".
As for the particular numbers 777 and 999: I have chosen completely random numbers for the FIDs. These numbers have meaning only to the mstpd. They do not have meaning for the other network nodes as FIDs are local to the given network node.
Note 1: mstpd DO NOT communicate FIDs with driver. This command sets the VID-to-FID mapping ONLY inside mstpd. The corresponding mapping in VTU you should do by other means by yourself with no help from mstpd!
Note 2: FID numbers inside Marvell's VTU can differ from FID numbers inside mstpd as long as you keep translation map for that. But in this case I really see no reason to do that. It is logical to programm VTU with the same FIDs as you do with mstpd by the means of setvid2fid command.
-
setfid2mstid command maps FIDs to the MSTIs (trees). In other words it tells mstpd which FIDs belong to which MSTI. In the above example the command tells mstpd: "FID 777 with all its VLANs belong to the MSTI with MSTID=1 and FID 999 with all its VLANs belong to the MSTI with MSTID=2. And all other FIDs kepp their MSTI mapping as it was before the command invocation". Taking in account that FID 777 contains VLANs 10, 100 and 200 (as set by previous setvid2fid command) we have mapped these VLANs 10, 100 and 200 to the MSTI with MSTID=1. In the same way VLANs 20,30 and 40 are now mapped to the MSTI with MSTID=2.
Note 1: mstpd DO NOT communicate this mapping with driver! This command sets the FID-to-MSTID mapping ONLY inside mstpd. The mapping of VIDs to SIDs inside VTU you should do by other means by yourself with no help from mstpd!
Note 2: Marvell directly maps VIDs to SIDs in VTU. It does not use FIDs for this purpose, unlike mstpd, which do this mapping as: VIDs->FIDs->\MSTIDs. Also note that VID-to-SID mapping is done in VTU, not STU!
-
First, you have messed up here FIDs with MSTIDs.
Second, as I noted earlier, mstpd will not help you in any way to set VLAN-to-MSTI (VLAN-to-SID) mapping inside driver. You should do it by other means.
The commands setvid2fid and setfid2mstid set that mapping only inside mstpd.
The best way to accomplish the task is to instruct your driver to set that mapping in the same script which calls "mstpctl setvid2fid" and "mstpctl setfid2mstid".
-
Hope, it all is a bit clearer now.
Don't hesitate to ask if something is not clear ;)
Actually meant to say SID and not FID on the post above. This is much clearer. I should be in a position to test now. I have implemented the following functionality let me know if I am missing something or have done something stupid. Will begin testing 1. Driver Deps: i) driver_set_new_state: Function passees 3 parameters to the kernel. port_name, mstid, new_state. This will modidy the appropriate entry in the STU. The MSTID is the SID used to locate the entry in the database ii) driver_create_msti: Function passes 1 paramater the MSTID to the kernel which will create and STU entry with this as the SID. iii) driver_delete_msti: Function passes 1 paramater the MSTID to the kernel which will delete this entry from the STU iv) driver_set_aging_time: Function takes no Parameters: Returns the ageing time from the driver which is gloabally set value on the switch. This is configured externally from the MSTPD v) driver_flush_all_fids: Function passes 1 parameter the FID which is used to Flush all Addresses from the ATU for this database. 2. DSA Driver which exports each port on switch as a Linux Netdevice. 3. External Script\app. To create the VLANS and SID mappings for the VLANSLast edit: Gary 2012-07-04
1 :
I) Ok
II) Ok
III) Ok
IV) First, please download new code revision from SVN. The latest revision is 32. The change makes driver_set_aging_time() function to set ageing time per port. As long as Marvell does not support such functionality it is ok to ignore the prt parameter of the function and set ageing time for the whole bridge.
Also, I do not understand why you have written "no Parameter" here. This function must pass at least 1 parameter to the driver - new ageing time. Ideally it will pass two parameters - port and new ageing time, but in our case we can ignore port parameter as Marvell does not support setting per-port ageing times.
And this MAY NOT be configured externally to the mstpd. mstpd must know which ageing time you have configured.
I think this function needs more explanation. Its purpose is to do the "rapid ageing" which is the STP-specific way of purging MAC entries. When mstpd is in STP mode, it uses "rapid ageing" - temporarily sets ageing time to some low value to age out MAC entries from the learning table. When mstpd is in {R|M}STP mode, it uses driver_flush_all_fids() for the same purpose. That is required by standard to keep backward compatibility with old STP-only implementations.
V) I suppose that function "passes 1 parameter - the FID" but does it multiply times - one for each FID in given MSTI.
-
2 Ok
3 Ok
And general remark: MSTID = SID is Ok for testing, but unacceptable in production, because you can not control which MSTIDs are set on other switches in network. So, in future you should develop some kind of mapping 12-bit MSTIDs into 6-bit SIDs,
Got confused with the driver_set_ageing_time. My first thoughts were correct in that it used to set the ageing time on the switch. The confusion came from the the fact the "ageing time is returned from the the STUB, presumed it was retrieved from the driver to set the ageing time on the MSTPD" which is incorrect.
Yes, it is used to set ageing time in hardware. The returned value shows which actual ageing time is set. For example, LinkStreet (at least my part) can not set ageing time with 1 sec granularity. If mstpd requested it to set 20 seconds, the best it could do is 15 seconds. So, the return value informs what actual ageing time was set in hardware.
Issue with configuration when trying to set the tree port cost. error, CTL_set_msti_port_config: br0 Couldn't find port with index CTL_set_msti_port_config: Got return code 0, -1 br0 Couldn't find port with index 6 Here is the command sequence I follow. OK brctl addbr br0 OK brctl addif fa1_6 fa1_0 OK ./mstpctl setmstconfid br0 0 CommonRegion OK ./mstpctl createtree br0 1 OK ./mstpctl createtree br0 2 OK ./mstpctl setvid2fid br0 777:10,100,200 999:20,30,40 OK ./mstpctl setfid2mstid br0 1:777 2:999 FAIL./mstpctl settreeportcost br0 fa1_6 0 10 FAIL../mstpctl settreeportcost br0 fa1_0 0 10 FAIL../mstpctl settreeportcost br0 fa1_6 1 10 FAIL../mstpctl settreeportcost br0 fa1_0 1 10 FAIL../mstpctl settreeportcost br0 fa1_6 2 10 FAIL../mstpctl settreeportcost br0 fa1_0 2 10 Note: fa1_6 and fa1_0 are DSA Netdevice representing two portsIt shouldn't work. You are missing something here ;) It must be:
Then, somewhen you should enable stp by issuing:
Also, you can see which interfaces are actually enslaved by issuing command:
Also, to see which interfaces are known to the mstpd, issue command:
Then compare output of both commands.
Last edit: Vitalii Demianets 2012-07-05
Its working now. You can add multiple interfaces from a single brctl addif. however your assumption was correct in that the interfaces were not added to the bridge correctly and that why it was failingSome debugging tips or set up tips for anyone else who wishes to use MSTPD. If you see the following error message
Error in bridge_bpdu_rcv at bridge_track.c:380 verifying ifc->sysdeps.up.
2000-03-04 21:58:17 Error in bridge_bpdu_rcv at bridge_track.c:380 verifying ifc->sysdeps.up.
Just ensure each interface and bridge is up with ifconfig. All interface of the bridge are in a Running State
To begin with, interface shouldn't be receiving a frame when it is not UP or not Running. The fact that you did receive the frame while interface is not UP shows that your hardware driver haven't done its job - it was to shut PHY down ;)
A case off adding the commands manually on three different switches and forgetting to insmod the mstpd module. But still I have problem with my driver. Say if you bring down the bridge using
ifconfig br0 down should this in turn cause and event in the mstpd to tell the HW to shutdown via the driver deps??
I have problem caused from this. Sequence
[root@switch userscripts]# ifconfig br0 down
br0: port 2(fa1_6) entering disabled state
br0: port 1(fa1_0) entering disabled state
br0: topology change detected, propagating
22: br0 Down mtu 1500
2000-03-05 00:10:35 set_br_up: br0 was up
2000-03-05 00:10:35 set_br_up: Set bridge br0 down
[root@switch userscripts]# 2000-03-05 00:10:36 MSTP_IN_rx_bpdu: br0:fa1_0 Received BPDU while bridge is disabled
2000-03-05 00:10:38 MSTP_IN_rx_bpdu: br0:fa1_0 Received BPDU while bridge is disabled
2000-03-05 00:10:40 MSTP_IN_rx_bpdu: br0:fa1_0 Received BPDU while bridge is disabled
If I then bring the bridge back up. The state change is detected the following happens
[root@switch userscripts]# ifconfig br0
2000-03-05 00:13:41 MSTP_OUT_set_state: br0:fa1_6:0 entering learning state
2000-03-05 00:13:41 MSTP_OUT_set_state: br0:fa1_6:1 entering learning state
2000-03-05 00:13:42 MSTP_OUT_set_state: br0:fa1_6:1 entering forwarding state
2000-03-05 00:13:42 MSTP_OUT_set_state: br0:fa1_6:2 entering forwarding state
Don't see any problem here, except that your driver did not put hardware ports into disabled state - and that's why all those warnings "Received BPDU while bridge is disabled". Is this the problem which bothers you? Then, as I stated in previous post (which is located below) - simply do not put br0 down ;) What for do you want to put it down? There must be another way of accomplishing your task.
-
1. Why do you want to bring that bridge down? Remember, that br0 is not a real bridge - it does not frame switching, real switching is in hardware. We create it for the technical purposes ONLY - it does not represent something t all, It is just an auxiliary tool. It is supposed to be UP all the time. Here is a list of useful thing you can do with it:
* Enslave interface to it - if you want to mstpd work with that interface. It is a way to say "Enable MSTP on the interface";
* Remove interface from it = "Disable MSTP on the interface"
* Disable stp on it = "Disable MSTP on the whole bridge".
That's all you should ever do with it.
2. You obviously wanted to accomplish some task by bringing br0 down, Let's find another way of accomplishing that task. For example, if you want to shut down hardware switch, you could send the special command to your driver.
Im just been a dumb user playing around with the tools to become familiar with the whole setup. The MSTPD is listening to ifconfig br0 up. When this event occurs it calls the change driver state. When doing the opposite i.e. ifconfig br0 down, an event is not triggered to bring the ports states down.
Going to look at my other driver deps issue with netlink resources been busy. Will Iron out all these issues first. This is possibly causing problems you have not seen before with it been un-chattered waters.
Ok. Playing with things sounds like a good way to learn ;) So, the bottom line - the linux bridge (br0) simply is not supposed to be brought down. There is no special support in driver_deps for that, because it serves no purpose; at least I can't imagine any useful purpose.
I'm looking forward for the results. Feel free to ask for any assistance you need.
Not sure why this occurring, message spitted onto the console at regular intervals on Switch3.
000-03-04 22:09:32 MSTP_OUT_flush_all_fids: br0:fa1_0:0 Flushing forwarding database
2000-03-04 22:09:32 MSTP_OUT_flush_all_fids: br0:fa1_0:1 Flushing forwarding database
2000-03-04 22:09:32 MSTP_OUT_flush_all_fids: br0:fa1_0:2 Flushing forwarding database
2000-03-04 22:09:32 MSTP_OUT_flush_all_fids: br0:fa1_6:0 Flushing forwarding database
2000-03-04 22:09:32 MSTP_OUT_flush_all_fids: br0:fa1_6:1 Flushing forwarding database
2000-03-04 22:09:32 MSTP_OUT_flush_all_fids: br0:fa1_6:2 Flushing forwarding database
2000-03-04 22:09:33 MSTP_OUT_flush_all_fids: br0:fa1_6:0 Flushing forwarding database
2000-03-04 22:09:33 MSTP_OUT_flush_all_fids: br0:fa1_6:1 Flushing forwarding database
2000-03-04 22:09:33 MSTP_OUT_flush_all_fids: br0:fa1_6:2 Flushing forwarding database
What is your concern: why it prints on the console or why it prints it at all?
The answer to the second question (why it prints it at all) can be found in the log. I hope, in the context of other messages it would be clear why Topolgy Change Machine wants to flush learned MACs.
I have been testing proposed scenario. Should I expect to have it working?, Almost, the initial path setup, and MSTI switch designations?