- Community Home
- >
- Networking
- >
- Legacy
- >
- Switches, Hubs, Modems
- >
- STP and Stacking
Switches, Hubs, and Modems
1748150
Members
3671
Online
108758
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-14-2005 05:05 PM
тАО07-14-2005 05:05 PM
hi,
are there any implications if i configure Spanning Tree Protocol on stacked switches? are there any issues regarding the implementation of these two features of HP Procurve Switches?
Thanks a lot!
are there any implications if i configure Spanning Tree Protocol on stacked switches? are there any issues regarding the implementation of these two features of HP Procurve Switches?
Thanks a lot!
Solved! Go to Solution.
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-14-2005 05:44 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-16-2005 04:18 PM
тАО07-16-2005 04:18 PM
Re: STP and Stacking
Hi
HP Procurve Support Stacking as following:
single IP address management for a virtual stack of up to 16 switches, including the ProCurve 2500 series, 2600 series, 2800 series, 3400cl series, 4000m, 6108, 8000m, and 4100gl series
Stacked Switchs appears in the topology as one huge switch with huge amount of ports, It has one IP Address, so I dont see any problem of enabling STP on HP Procurve stacked switchs, and it DOSE Support both of them
Regards
HP Procurve Support Stacking as following:
single IP address management for a virtual stack of up to 16 switches, including the ProCurve 2500 series, 2600 series, 2800 series, 3400cl series, 4000m, 6108, 8000m, and 4100gl series
Stacked Switchs appears in the topology as one huge switch with huge amount of ports, It has one IP Address, so I dont see any problem of enabling STP on HP Procurve stacked switchs, and it DOSE Support both of them
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-16-2005 08:50 PM
тАО07-16-2005 08:50 PM
Re: STP and Stacking
Mohammed,
> single IP address management for a virtual
> stack of up to 16 switches
Yep, that's what they call "stacking" - and AFAIK that's it. A managementwise clustering of a bunch of switches to make them available with a single address and - as this causes loss of individuality in SNMP queries - a way to access SNMP information on individual switches using modified communities, or by merging the MIB views. If I'm wrong here and HP stacking does something fundamentally different from Cisco clustering, please correct me. The basic thing is that it is no stacking in the actual sense of the word - there is no unification of the switches into a greater single 802.1D bridge entity. Real stacking feels exacty like a modular chassis switch that gets further blades plugged into it - just with cables instead of a chassis. See the old Accton design OEMed by half the vendors in the world, see Cisco 3750 stackwise. A real stack is one single bridge hop, as the stack merges *backplanes*, it is no interswitch link.
> Stacked Switchs appears in the topology as
> one huge switch with huge amount of ports,
In which topology? In the real topology it doesn't change a bit, there is still a number of individual 802.1D bridges with all the accompanying effects. It might appear as a compound in some management frontend, but it doesn't create a compound in the actual topology. Meshing on the other hand does indeed create a compound that interfaces to the outside only with STP and should be considered a single 802.1D entity for non-meshers (however it still involves multiple hops), but AFAIK stacking is simply a way to organize management with less IP addresses. It doesn't gain you anything beyond that. It has no effect on L2 or L1.
> It has one IP Address, so I dont see any
> problem of enabling STP on HP Procurve
> stacked switchs, and it DOSE Support both
> of them
Yep, clearly. You still got a bunch of individual 802.1D bridges, so you will need to make sure loops in the physical topology are worked around. As soon as you use L1/L2 redundancy, you *must* combine stacking with (R)STP, else you go cyclotron frame accelerator blinkenlights promptly.
Correct me if I'm wrong,
Andre.
> single IP address management for a virtual
> stack of up to 16 switches
Yep, that's what they call "stacking" - and AFAIK that's it. A managementwise clustering of a bunch of switches to make them available with a single address and - as this causes loss of individuality in SNMP queries - a way to access SNMP information on individual switches using modified communities, or by merging the MIB views. If I'm wrong here and HP stacking does something fundamentally different from Cisco clustering, please correct me. The basic thing is that it is no stacking in the actual sense of the word - there is no unification of the switches into a greater single 802.1D bridge entity. Real stacking feels exacty like a modular chassis switch that gets further blades plugged into it - just with cables instead of a chassis. See the old Accton design OEMed by half the vendors in the world, see Cisco 3750 stackwise. A real stack is one single bridge hop, as the stack merges *backplanes*, it is no interswitch link.
> Stacked Switchs appears in the topology as
> one huge switch with huge amount of ports,
In which topology? In the real topology it doesn't change a bit, there is still a number of individual 802.1D bridges with all the accompanying effects. It might appear as a compound in some management frontend, but it doesn't create a compound in the actual topology. Meshing on the other hand does indeed create a compound that interfaces to the outside only with STP and should be considered a single 802.1D entity for non-meshers (however it still involves multiple hops), but AFAIK stacking is simply a way to organize management with less IP addresses. It doesn't gain you anything beyond that. It has no effect on L2 or L1.
> It has one IP Address, so I dont see any
> problem of enabling STP on HP Procurve
> stacked switchs, and it DOSE Support both
> of them
Yep, clearly. You still got a bunch of individual 802.1D bridges, so you will need to make sure loops in the physical topology are worked around. As soon as you use L1/L2 redundancy, you *must* combine stacking with (R)STP, else you go cyclotron frame accelerator blinkenlights promptly.
Correct me if I'm wrong,
Andre.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP