Switching

 View Only
last person joined: 9 hours ago 

Ask questions and share experiences about EX and QFX portfolios and all switching solutions across your data center, campus, and branch locations.
  • 1.  Setting Root Bridge

    Posted 01-10-2017 11:34

    I have several questions in regards to setting the root bridge priority properly.  We have a our corp HQ office that is running a ex4200VC at the core.  We have 15 addition IDF switches in our building. My topology for each IDF is 2GB LACP fiber LAG's connecting all IDF switches from all floors in all buildings back to our core switch. All switches are Juniper either EX2200 or EX4200. No routers or firewalls between any of them. i noticed when looking at our switches that when i ran the command below on the core my root ID was not for the core switch.

     

    root@MDF1-SW1-EB1F> show spanning-tree bridge

     

    STP bridge parameters

    Context ID                          : 0

    Enabled protocol                    : RSTP

      Root ID                           : 28672.b8:e9:37:04:5a:84

      Root cost                         : 210000

      Root port                         : ae5.0

      Hello time                        : 2 seconds

      Maximum age                       : 6 seconds

      Forward delay                     : 4 seconds

      Message age                       : 2

      Number of topology changes        : 10645

      Time since last topology change   : 592 seconds

      Topology change initiator         : ae5.0

      Topology change last recvd. from  : 84:18:88:a8:cb:83

      Local parameters

        Bridge ID                       : 32768.5c:5e:ab:66:a2:01

        Extended system ID              : 0

        Internal instance ID            : 0

     

    upon further investigating it was determined that a sonos boost wireless extender on our network is acting as the root bridge.  We have the sonos speakers and boost on our network for different design studios.  currently i have about 20 speakers total spread throughout three buildngs.  That number is going to grow some more here.  We were having a slow speed issue in one area of our LAN.  after months of troubleshooting, testing computers, network, network cabling, speakers, printing, phones, switches, it was deteremined that we had some significan signal loss with our 1gb fiber trunks.  in that area we had 4 sonos speakers, but removed them during the troubleshooting phase. one thing we noticed when they were connecting using the ethernet wire was that you could only connect 2 speakers. if you tried to connect three it would cause the music to be glitchy and not work.

     

    So i am trying to setup all of my switches to play nice with the sonos and vice versa to make the network work properly. 

     

    1. By setting the bridge priority to 0 on the core will that be disruptive at all to the network? will that also require a reboot to take affect, or does the negotiation notice the change after commit and adjust accordingly?
    2. Is it best practice to leave all other remaining IDF switches at their default value 32,768 or should i also set maybe one additional one at 4096 so if the core goes down that one will be elected as root bridge in the interim?
    3. Because i have multiple VLANS (21 currently) on the network i saw there are several ways to set the bridge-priority based on the Juniper KB article below and what protocol to assign it on. Unless i am not seeing, thinking, or understandingsomething, i would want my core switch for all vlans to always be the root bridge, or is there some reason not to? My topology has 2GB LACP LAG's connecting all IDF switches from all floors in all buildings back to our core switch. All switches are Juniper either EX2200 or EX4200. No routers or firewalls between any of them.
    4. will set the sonos boost bridge id to a higher value as well.
    5. Has anyone else had to configure Sonos speakers on their network. Are there any other changes that need to be made at the core/MDF, IDF, or interface level to make them all work besides the root bridge

     

    Since i have RSTP enabled based on the output above would i navigate to

    #edit protocols rstp

    [edit protocols rstp]#set bridge-priority 0

     

    or would i do it a the STP protocol?

     

     

    Juniper KB article

    https://www.juniper.net/documentation/en_US/junos12.3/topics/reference/configuration-statement/bridge-priority-spanning-trees-ex-series.html

     

    bridge-priority (Spanning Trees)

    Syntax

    bridge-priority priority;

    Hierarchy Level

    [edit protocols mstp],

    [edit protocols mstp msti msti-id],

    [edit protocols rstp],

    [edit protocols stp],

    [edit protocols vstp vlan vlan-id]

    Release Information

     

    Statement introduced in Junos OS Release 9.0 for EX Series switches.

     

    Statement updated in Junos OS Release 9.4 for EX Series switches to add VSTP support.

    Description

     

    Configure the bridge priority. The bridge priority determines which bridge is elected as the root bridge. If two bridges have the same path cost to the root bridge, the bridge priority determines which bridge becomes the designated bridge for a LAN segment.

     

    Default

     

    32,768

    Options

     

    priority—Bridge priority. It can be set only in increments of 4096.

     

    Range: 0 through 61,440

     

    Default: 32,768

    Required Privilege Level

     

    routing—To view this statement in the configuration.

    routing-control—To add this statement to the configuration.

     

     



  • 2.  RE: Setting Root Bridge

    Posted 01-10-2017 13:15

    so right now i have permanently disabled on 4 sonos play 1 speakers the wifi interface for each. I only want to use the wired connection.   i came across this on the Sonos website in regards to STP and BPDU being discarded.  How can make sure bpdu are being passed to allow the wired speakers to work properly without creating any sort of loops or network issues?

     

    SONOS ZonePlayers use 802.1D Spanning Tree (STP) for loop prevention between wired ZonePlayers and the wireless SonosNet Mesh Network. The Spanning Tree running on ZonePlayers is compliant with IEEE 802.1D and can inter-operate with other IEEE 802.1D and IEEE 802.1w compliant devices. Note: IEEE 802.1w is an updated version of the Spanning Tree protocol called Rapid Spanning Tree. The two types of STP protocols are compatible and 802.1w should revert to inter-operate with 802.1D devices (such as Sonos). Therefore, 802.1w Ethernet switches will work with Sonos ZonePlayers.

    SONOS ZonePlayers CAN be connected to Ethernet switches that do NOT support Spanning Tree as long as the Ethernet switches do not interfere with the STP BPDU packets transmitted between ZonePlayers. This is typically never the case and these switches pass the BPDU packets like any other packet.

    If the Ethernet switches that Sonos ZonePlayers are wired to DOES support Spanning Tree, the Spanning Tree on those switches must be configured properly. Ethernet switches that support Spanning Tree typically have their STP settings disabled. This also typically means that these switches will block/discard the BPDUs coming from the ZonePlayers. When the ZonePlayers are not able to see BPDUs, they cannot detect there is a shared transmission medium between the Zones and this will typically result in loops in the network. The solution to allow the use of these switches with Sonos is to enable and configure the Spanning Tree on the Ethernet switches. The configuration settings on each switch are different and the appropriate documentation for those products should be consulted. Note: Some switches have a setting that is called Pass BPDUs or equivalent. This setting when present allows the BPDUs between the ZonePlayers to pass freely through the switch without actually enabling STP on the the switch. Typically, setting this function also works, but again please review the switches product documentation.

    A good guideline for Ethernet switches is if the switch says it supports Spanning Tree, either 802.1D or 802.1w, then its configuration settings and user documentation should be examined before wiring multiple ZonePlayers to the switch. If the switch does not state it supports Spanning Tree, 802.1D, or 802.1w, it will probably work fine with Sonos.

    SONOS ZonePlayers do NOT require a connection to the same Ethernet switch. Different ZonePlayers can be connected to different Ethernet switches which are in turn connected to each other. The only requirement is that Sonos ZonePlayers must be able to actively participate in 802.1D Spanning Tree and not have BPDU transmission blocked between them. There is no Sonos limitation that prevents wiring multiple ZonePlayers to multiple Ethernet switches.

    IEEE 802.1D has a recommended bridge span limitation of 7 bridges. This means that the total number of connected bridges from one end of the network to the other should not exceed 7 bridges. This typically only comes into play when daisy chaining Sonos ZonePlayers together by wiring one ZonePlayer to the next. In this case, the guidelines is when daisy chaining ZonePlayers, do not exceed 7 ZonePlayers wired together. If wiring multiple ZonePlayer to a single Ethernet switch, typically the number of spans will only be 3 or 4 (I.e. much less than 7). Except in the daisy-chain configuration, this limit of 7 bridges/7 ZonePlayers, is rarely ever hit.

    A number of comments have used the term router and switch interchangeably in regards to this topic. Sonos ZonePlayers in the same HouseHold MUST be connected to the same routed network. A Spanning Tree cannot span two or more routed networks. In addition all Sonos ZonePlayers and Controllers must be on the same routed IP network in order to properly communicate and function. Typically, two or more routed networks are not seen in the household environment except by accident (Example. A carrier provides a new router in a network that already had a router and the original router was not removed).

    Hopefully this information has clarified a number of items and not added additional confusion.

    Regards, Todd

     

    here is the protocol config on my core switch. Believe the interface listed 0/0/15 was put there during testing on something else i wasn't apart of.

     

    root@MDF1-SW1-EB1F# show protocols
    igmp {
        interface all;
    }
    pim {
        dense-groups {
            239.0.0.0/8;
        }
        interface all {
            mode dense;
        }
    }
    igmp-snooping {
        vlan all {
            interface ae9.0 {
                multicast-router-interface;
            }
            interface ae5.0 {
                multicast-router-interface;
            }
            interface ae7.0 {
                multicast-router-interface;
            }
            interface ae8.0 {
                multicast-router-interface;
            }
            interface ae3.0 {
                multicast-router-interface;
            }
            interface ae6.0 {
                multicast-router-interface;
            }
            interface ae2.0 {
                multicast-router-interface;
            }
            interface ge-2/0/0.0 {
                multicast-router-interface;
            }
        }
    }
    rstp {
        interface ge-0/0/15.0 {
            disable;
            edge;
        }
    }
    lldp {
        interface all;
    }
    lldp-med {
        interface all;
    }

    {master:0}[edit]