- Community Home
- >
- Networking
- >
- Switching and Routing
- >
- HPE Aruba Networking & ProVision-based
- >
- Questions about distributed trunking
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
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
Community
Resources
Forums
Blogs
- 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
03-29-2012 12:30 PM
03-29-2012 12:30 PM
Questions about distributed trunking
I'm looking at introducing switch-to-switch distributed trunking in my environment, to eliminate the need for spanning tree and take advantage of those uplinks that are currently sitting idle. I've read the DT whitepaper, and the relevant sections of the configuration guide, and still have a few questions:
1. Is the ISC interconnect dedicated for distributed trunking, or can it be used for all traffic passing through the switches? (i.e. if I have single-homed server1 connected to switch1, and single-homed server2 connected to switch2, will traffic flow across the ISC link, or is there an additional link required?)
2. Are there any remaining issues with DT and IP routing being enabled on the switches? The documentation says no, but I've seen references on this forum and others that this may or may not be the case.
3. I, unfortunately, do not have any lab equipment, and HP doesn't provide a procurve simulator. Does anybody have any recommendations for introducing this into a production network? Obviously, this will happen during a scheduled maintenance window, but a list of DOs and DON'Ts from someone who has already implemented this would definitely be appreciated.
Thanks,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-13-2012 08:38 AM
04-13-2012 08:38 AM
Re: Questions about distributed trunking
First off, I still have spanning tree enabled even though my core uses distributed trunking-- curious what you mean? Just that you could eliminate the need to have a failover link which STP keeps blocked unless the main link fails?
I have a rather new dual 5406 core using distributed trunking and VRRP which an HP partner set up, so I am no expert on it. We had significant difficulty getting everything to work-- whenever both switches were on, everything went to hell. It all turned out to be an issue with the initial configuration and a hardware issue on one 5406. Now it works great. Be sure to use "DT-LACP", not "DT-Trunk" on the core end and LACP Trunk on the connecting switches devices, which was one of the fixes that made a difference.
As for #1, the ISC is used for all traffic passing between switches, as I understand it. The route data takes is still based on a hashing algorithm which might send it across the iSC and out another distributed trunk vs. just going out its own trunk link. It seems unnecessary, but I understand the concept of the hashing algorithm as a means to load-balance. In the example you give of the server communication, yes, it can all go through the ISC (which is why you want that to be a fat pipe). The DT-trunking does seem to accomplish the equivalent of stacking, in that you can connect a host to just one of the switches or DT trunk it to both.
For hosts which do not have two NICs, I am currently debating whether it makes more sense to connect them to one of the cores and risk losing that service if that core switch goes down or connect it to a reliable access switch which is DT trunked to the core and risk that the access switch will go down. Right now I am tending toward the latter method.
2. We now have a bunch of ACLs and routes on the two cores, so IP routing is enabled, VRRP is configured, and it all seems to be working fine. I don't know whether there are still any latent issues, though. I can only report my experience.
3. I'm in a school, so we had a similar problem with no test lab. When our issues arose, I could test network connectivity by sending a command to all the Macs in the school on various subnets to ping the gateway three times via dns lookup and report results (using Apple Remote Desktop, send unix command: ping -c3 gateway.ourdomain.org | grep "packet") and that works really well to quickly ascertain the state of the network in 5 seconds (tests access to dns server and gateway, and easy to spot any results which are not "0% packet loss"). I don't know whether there's a method to get Windows PCs to do the same thing or something which achieves the same results.
In any case, take it slow, start out with just your heartbeat and ISC configured and add segments one at a time. If you're testing as you go, you'll know very quickly if stuff starts to get wonky, and all you have to do is pull the second switch DT trunk(s), and all returns to normal in a few seconds. The two switches' heartbeat and ISC can remain connected with no adverse effects. I don't think you'll have the same problems I did, though, in any case.
Good luck