- Community Home
- >
- Servers and Operating Systems
- >
- HPE BladeSystem
- >
- BladeSystem - General
- >
- Virtual Connect Behaviour
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
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
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
05-28-2010 07:10 AM
05-28-2010 07:10 AM
Virtual Connect Behaviour
Some good discussion in Virtual Connect behaviour with DCC and other items. Nick started the discussion:
******************************************************************************************************************
Hi all,
I am onsite performing some Virtual Connect Flex10 failover testing, and have had a couple of issues that have led to some questions.
- Q1: I have 2 NICs that have multiple networks attached (1 to each LOM). Once of these networks (network 1) is an external network with uplinks, the other (network 2) is a Virtual Connect internal only network (no external uplinks).
The issue is that if we lose the externally connected uplinks the on network 1 the NIC is not dropped via SmartLink as the internal only network is still showing as ok.
Is there any way to force a DCC to set the NIC to down if ANY of the mapped networks go down, or is it only when they ALL go down?
- Q2: Looking at the VC-ENET cookbook scenario 1:6 seems to match what we are doing (i.e. active/active with A and B instances of all VLANS). This says that we should have the same LAG ID on both the “A” and “B” Shared Uplink sets, even though they are on different modules with uplinks going to different switches. I have been discussing this with a networks guy and he is saying that this is not the case as we are connecting to different switches, so the LAG ID would be different.
Is this correct, should I have the same LAG ID even though they are different Shared Uplink Sets in different modules connected to different switches in the core?
And yes, I am on the very edge of my networking knowledge with the LAG ID stuff!!
********************************************************************************************************************
Response from Dave:
*****************************************************************************************************************
Nick,
You mentioned DCC, so can we assume the OS is VMWare? There has been a lot of discussions on the Broadcom Fw level and what is supported with Flex-10/Smartlink. I had to turn ‘Beacon Probing’ on at one site to get it to work.
On question # 2, I got bit by that scenario also. I don’t know if that scenario has two modules connected to the same core switch. Different external cable/port groups will have different LAG #s. Ports in one module going to the same Core/Edge switch should have the same LAG #s to be trunked for Active/Active, else it will be an Active/Standby config.
It would be nice if we corrected or explained the LAG ID info in this document.
*****************************************************************************************************************
Nick's reply:
****************************************************************************************************************
Hi Dave,
Many thanks for the reply.
Re: DCC.
My customer has decided to stay with 1.52 with the latest firmware as they are in the testing phase at the moment, and not heading into production for a bit. We have proved that for the NICs with only external networks mapped DCC works correctly, as the NIC is taken down when all uplinks are lost, causing traffic to be routed over the other active NIC in the team.
The issue we were seeing is that on one pair of NICs where we have 2 networks mapped, one with uplinks, the other with none (internal traffic only), DCC does not take the NIC down if the external network loses connectivity as the internal network status is still green. This causes a loss of connectivity as VMware does not know the external link is dead. We have fixed this by moving the internal only network to a network in the Same Shared Uplink set as the other network.
We may have been able to solve this with beacon probing but I am trying to avoid using that as you should really have 3 NICs in a team for it to work reliably.
Re: LAG ID
Thanks, that makes sense to me now. As you say, it would be nice if an extra line was added to the document to state that.
************************************************************************************************************
Then Chris joined the conversation:
*************************************************************************************************************
And this is by design. The thing you need to be aware of (and I honestly have not seen this discussion happen at all on this PDL) is all of the assigned/mapped networks must be in a failed state for SmartLink to work. So, you will need to separate out the networks to different NICs. Or, add this network to the SUS like you have done.
*****************************************************************************************************************
Any input from the gallery? Your advice or comments?