- Community Home
- >
- Servers and Operating Systems
- >
- HPE BladeSystem
- >
- BladeSystem - General
- >
- Re: Virtual Connect Routing Question
BladeSystem - General
1753430
Members
4807
Online
108793
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
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
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
05-15-2008 01:53 AM
05-15-2008 01:53 AM
Virtual Connect Routing Question
Please can someone advise how the routing works within VC if you have multiple ports assigned to a server (see sample config below).
VC EXAMPLE CONFIG
Port 1 - DATA1 network (physically patched to bays 1 & 2)
Port 2 - DATA2 network (physically patched to bays 5 & 6)
Port 3 - DATA1 network (physically patched to bays 1 & 2)
Port 4 - DATA2 network (physically patched to bays 5 & 6)
- All these ports are trunked presenting the same set of multiple VLAN's and so full access is available whether using DATA1 or DATA2.
- Each port is mapped to a different physical NIC.
- This approach is taken to provide redundancy across networks (patched to different switches) and NIC's within each server.
So my question is what route would be taken first, port 1 because it is first in the list? Or is it random?
Is there a benefit if I get half the enclosure to use a different order (DATA2, DATA1, DATA2, DATA1)? The idea being to encourage the traffic to be split more evenly across the links and switches. I assume if all servers have the same profile they would all attempt to hit the first network first (?), so in the 'VC Config' example given above DATA1 would be hit hardest before DATA2. Or is VC more intelligent than this?
I am really trying to see if there is any benefit in having different profiles (with different orders), or the same profile across all? Obviously having the same profile keeps it simple, but it may not be the optimum approach?
Thanks
Kevin
VC EXAMPLE CONFIG
Port 1 - DATA1 network (physically patched to bays 1 & 2)
Port 2 - DATA2 network (physically patched to bays 5 & 6)
Port 3 - DATA1 network (physically patched to bays 1 & 2)
Port 4 - DATA2 network (physically patched to bays 5 & 6)
- All these ports are trunked presenting the same set of multiple VLAN's and so full access is available whether using DATA1 or DATA2.
- Each port is mapped to a different physical NIC.
- This approach is taken to provide redundancy across networks (patched to different switches) and NIC's within each server.
So my question is what route would be taken first, port 1 because it is first in the list? Or is it random?
Is there a benefit if I get half the enclosure to use a different order (DATA2, DATA1, DATA2, DATA1)? The idea being to encourage the traffic to be split more evenly across the links and switches. I assume if all servers have the same profile they would all attempt to hit the first network first (?), so in the 'VC Config' example given above DATA1 would be hit hardest before DATA2. Or is VC more intelligent than this?
I am really trying to see if there is any benefit in having different profiles (with different orders), or the same profile across all? Obviously having the same profile keeps it simple, but it may not be the optimum approach?
Thanks
Kevin
1 REPLY 1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-15-2008 08:54 AM
05-15-2008 08:54 AM
Re: Virtual Connect Routing Question
Kevin:
what really dictates which NIC will be used is the server configuration itself. Are you teaming/bonding these NICs together? If so, the teaming/bonding configuration will dictate which NIC is used.
If the server has NICs in different IP subnets than the servers internal IP routing table will determine the path.
Alternating the config on the server profiles will help to provide a better balance of traffic across the 2 networks. But this balance of traffic could instead be acheived by the NIC configuration on the servers. I.E. Bay 1 server has NIC 1 primary, Bay 2 server has NIC 3 primary... etc.
what really dictates which NIC will be used is the server configuration itself. Are you teaming/bonding these NICs together? If so, the teaming/bonding configuration will dictate which NIC is used.
If the server has NICs in different IP subnets than the servers internal IP routing table will determine the path.
Alternating the config on the server profiles will help to provide a better balance of traffic across the 2 networks. But this balance of traffic could instead be acheived by the NIC configuration on the servers. I.E. Bay 1 server has NIC 1 primary, Bay 2 server has NIC 3 primary... etc.
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