Menu

Basic Example using mstpctl

Gary
2012-06-06
2013-05-30
1 2 > >> (Page 1 of 2)
  • Gary

    Gary - 2012-06-06

    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)
    
     
  • Vitalii Demianets

    Here is the list of commands for your topology:

    Common config, for all switches:

    # 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
    
     
  • Gary

    Gary - 2012-06-06

    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

     
    • Gary

      Gary - 2012-06-15

      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

       
      • Vitalii Demianets

        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!

         
  • Gary

    Gary - 2012-07-03

    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
  • Vitalii Demianets

    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 ;)

     
  • Gary

    Gary - 2012-07-04
    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
    • Vitalii Demianets

      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,

       
  • Gary

    Gary - 2012-07-04

    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.

     
    • Vitalii Demianets

      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.

       
  • Gary

    Gary - 2012-07-05
    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
    
     
    • Vitalii Demianets

      brctl addif fa1_6 fa1_0

      It shouldn't work. You are missing something here ;) It must be:

      brctl addif br0 fa1_0
      brctl addif br0 fa1_6
      

      Then, somewhen you should enable stp by issuing:

      brctl stp br0 on
      

      Also, you can see which interfaces are actually enslaved by issuing command:

      brctl show br0
      

      Also, to see which interfaces are known to the mstpd, issue command:

      mstpctl showport br0
      

      Then compare output of both commands.

       

      Last edit: Vitalii Demianets 2012-07-05
  • Gary

    Gary - 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  failing
    
     
  • Gary

    Gary - 2012-07-13

    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

     
    • Vitalii Demianets

      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 ;)

       
      • Gary

        Gary - 2012-07-13

        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??

         
        • Gary

          Gary - 2012-07-13

          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

           
          • Vitalii Demianets

            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.

             
        • Vitalii Demianets

          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.

           
          • Gary

            Gary - 2012-07-13

            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.

             
            • Vitalii Demianets

              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.

               
  • Gary

    Gary - 2012-07-13

    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

     
    • Vitalii Demianets

      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.

       
  • Francis

    Francis - 2012-07-25

    I have been testing proposed scenario. Should I expect to have it working?, Almost, the initial path setup, and MSTI switch designations?

     
1 2 > >> (Page 1 of 2)

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.