- Community Home
- >
- Networking
- >
- Legacy
- >
- Switches, Hubs, Modems
- >
- Re: GBE2 switch configuration attached to single c...
Switches, Hubs, and Modems
1753511
Members
5209
Online
108795
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
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
тАО09-29-2005 01:20 PM
тАО09-29-2005 01:20 PM
GBE2 switch configuration attached to single cisco 6509
I am attempting to configure a blade chasis that has 2 GBE2 swithces similar to the straight through configuration depicted in the "Deploying the proliant BL-pClass GBE2 Interconnect Switch into a Cisco based Network" page 22. The only difference is we only have one Cisco switch.
What I have done so far is create 2 channels on the cisco switch with 3 ports each. These plug into ports 19,20,21 on the GBE2's. Those ports are configured as tagged, 100 full.
Basically both switches are configured identically. I also disabled ports 17 and 18 on both switches. Ports 1,2,5,7,9,11,13,15 belong to the same vlan, as do the trunked ports.
On testing, the configuration, I started with one switch and confirmed connectivity and trunking by disconnected different combinations of the uplink ports. All this seemed to work fine.
When I brought up the second switch problems arose where other subnets could ping the servers in the blade enclosure, but servers on the same subnet could not.
the servers have nic1(switch a) and nic3 (switch b) teamed. I have a feeling that the problem is one or some or all of the following...
1. Trunk ports need to be attached to seperate Cisco switchs as depicted in the document. ( I dont think this is it)
2. STP needs to be disabled on both GBE2's
(this may be true but not sure if this is the problem)
3. Additional software is needed to make this work. I.E. Proliant Essentials Intellignet Networking Pack. ( I think this is the main issue)
Obviously, my intention is to Team nic1 and nic3 for fault tolerance in the event that a blade on the cisco goes out or a GBE2 goes out or needs maintenance, there is no downtime.
So what I am looking for is confirmation or insight into this scenario.
Thanks for the help
What I have done so far is create 2 channels on the cisco switch with 3 ports each. These plug into ports 19,20,21 on the GBE2's. Those ports are configured as tagged, 100 full.
Basically both switches are configured identically. I also disabled ports 17 and 18 on both switches. Ports 1,2,5,7,9,11,13,15 belong to the same vlan, as do the trunked ports.
On testing, the configuration, I started with one switch and confirmed connectivity and trunking by disconnected different combinations of the uplink ports. All this seemed to work fine.
When I brought up the second switch problems arose where other subnets could ping the servers in the blade enclosure, but servers on the same subnet could not.
the servers have nic1(switch a) and nic3 (switch b) teamed. I have a feeling that the problem is one or some or all of the following...
1. Trunk ports need to be attached to seperate Cisco switchs as depicted in the document. ( I dont think this is it)
2. STP needs to be disabled on both GBE2's
(this may be true but not sure if this is the problem)
3. Additional software is needed to make this work. I.E. Proliant Essentials Intellignet Networking Pack. ( I think this is the main issue)
Obviously, my intention is to Team nic1 and nic3 for fault tolerance in the event that a blade on the cisco goes out or a GBE2 goes out or needs maintenance, there is no downtime.
So what I am looking for is confirmation or insight into this scenario.
Thanks for the help
2 REPLIES 2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-06-2006 09:56 PM
тАО03-06-2006 09:56 PM
Re: GBE2 switch configuration attached to single cisco 6509
Hello,
Did you get an answer to this posting? I have similar questions.
Thanks,
Did you get an answer to this posting? I have similar questions.
Thanks,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-07-2006 11:51 PM
тАО03-07-2006 11:51 PM
Re: GBE2 switch configuration attached to single cisco 6509
This sound mysterious to me, too.
I would sniff traffic off both GBE2s to see where your packets are going.
What kind of teaming are you using? Fault-tolerance, or load balancing?
When there are problems with one subnet, and not another, I usually find it's a VLAN or IP problem. Have you checked the VLAN-configuration for the second trunk/channel on the Cisco? But if you are using load balancing in the teaming, then a switch might choke on seeing the same MAC on different ports. How does the Cisco handle that?
As for your point #2:
"STP needs to be disabled on both GBE2's"
I wouldn't do this if I were you. In fact, I'd keep the crosslink as well.
The reason is because teaming might actually failover to a faulty link.
Say your server has the nic on GBE2 A active, and all is well. The active nic will send a heartbeat across the network, to the stand-by nic on GBE2 B.
Failover occurs if the heartbeat doesn't arrive.
Unfortunately, this means that if the link between your Cisco and GBE2 B fails (ie the passive/stand by link), failover will still occur. Now your server is trying to communicate through GBE2 B, which is off-line, and your healthy link on GBE2 A is unused.
Keeping the crosslink open, and running STP, will avoid this problem.
I would sniff traffic off both GBE2s to see where your packets are going.
What kind of teaming are you using? Fault-tolerance, or load balancing?
When there are problems with one subnet, and not another, I usually find it's a VLAN or IP problem. Have you checked the VLAN-configuration for the second trunk/channel on the Cisco? But if you are using load balancing in the teaming, then a switch might choke on seeing the same MAC on different ports. How does the Cisco handle that?
As for your point #2:
"STP needs to be disabled on both GBE2's"
I wouldn't do this if I were you. In fact, I'd keep the crosslink as well.
The reason is because teaming might actually failover to a faulty link.
Say your server has the nic on GBE2 A active, and all is well. The active nic will send a heartbeat across the network, to the stand-by nic on GBE2 B.
Failover occurs if the heartbeat doesn't arrive.
Unfortunately, this means that if the link between your Cisco and GBE2 B fails (ie the passive/stand by link), failover will still occur. Now your server is trying to communicate through GBE2 B, which is off-line, and your healthy link on GBE2 A is unused.
Keeping the crosslink open, and running STP, will avoid this problem.
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