- Community Home
- >
- Servers and Operating Systems
- >
- HPE BladeSystem
- >
- BladeSystem - General
- >
- Internal chassis blade communications with Virtual...
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
02-14-2011 07:22 AM
02-14-2011 07:22 AM
Internal chassis blade communications with Virtual Connect
Stephen was looking for help on Virtual Connect for a customer situation:
*****************
> Hi - customer wants to create two separate SUSes on the FlexFabric
> modules in rear bays 1 and 2 so that they operate in active/active
> mode to give the full uplink bandwidth.
>
> If they do this they have asked the following 3 questions:-
>
> (1) If blades within the chassis need to communicate via the SAME port
> (e.g. port 1 or port 2) does traffic go out to the upstream switches
> or do the VC modules route traffic for the same chassis directly back
> down the relevant downlink? (I'm pretty confident that the answer is
> YES but I need confirmation).
>
> (2) if two blades within the chassis need to communicate via DIFFERENT
> NIC ports (e.g. Blade-X via sends traffic via port 1 to port-2 on
> Blade-Y in the same chassis) will this traffic be routed/bridged
> across the X7,X8 cross-links OR will it need to travel out of the VC
> uplinks to the external switches and then be sent back to BladeY. So
> they will have created, say, VLAN101-1 on SUS1 and VLAN101-2 on SUS2
> and ideally would prefer these two networks to communicate across the
> cross-links rather than be routed via the external switches. I suspect
> the answer to this is NO because there is no communication between
> different VLANs across the interconnect? Can anyone confirm or deny?
>
> (3) Today they use Cisco blade switches. For VMWare ESX, they tell me
> all network traffic from any individual VM can only be routed out
> through one port on the host blade (I guess because they cannot create
> an active-active trunk across two Cisco blade switches (unless they
> use the Cisco VBS feature which they don't, as it has other issues).
> They can manually load balance different VMs across the two blade
> ports but would prefer to create a single aggregated link from the two
> 10G ports on the BL460cG7 and give every VM access to the full 20G
> uplink bandwidth (or some Flex-10 fraction of that). I know that
> aggregation of the two NICs on the BL460cG7 can only be done by the
> operating system in the case of Windows and I assume that ESX 4.x can
> do the same but I need confirmation. Does ESX 4.x allow creation of a
> single aggregated 20G NIC on the BL460cG7? Again I think answer is YES
> but I need confirmation.
**************************
Andreas replied:
*********************
Stephen,
Here some rules how traffic is forwarded with VC:
- If traffic stays in the same SUS it will switched locally and use the cross links (in a 2 interconnect module design)
- Traffic between 2 different SUS need always be switched by the next uplink switch
- Load Balancing on ESX can have different flavors with VC
Route based on the originating vSwitch port ID <- recommended for most setups
Route based on source MAC hash
Route based on IP hash
VC does not support LACP on downlinks
VC does never route. It just forwards a packet. Just to avoid the wrong terms.
Hope this helps already.
**********************
Other comments or suggestions for Stephen?