<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Ethernet Virtual Connect question in BladeSystem - General</title>
    <link>https://community.hpe.com/t5/bladesystem-general/ethernet-virtual-connect-question/m-p/795#M33988</link>
    <description>Dave  Appreciate the long response, I think you cleared some things up for me.  The problem I was having hearing that if I have VC_Ents in slot 1/2 which I do, I didnt was a little frustrated in thinking that it was purely going to be a standby switch.  From what I am gathering from what you said, it still acts a part of a team if you will.</description>
    <pubDate>Fri, 08 Feb 2008 16:31:00 GMT</pubDate>
    <dc:creator>duhaas</dc:creator>
    <dc:date>2008-02-08T16:31:00Z</dc:date>
    <item>
      <title>Ethernet Virtual Connect question</title>
      <link>https://community.hpe.com/t5/bladesystem-general/ethernet-virtual-connect-question/m-p/792#M33985</link>
      <description>Just got our first blade 7000 Blade Enclosure in, we purchased two Virtual Connect Switches, and have them in slots 1&amp;amp;2, from what I am reading, the one in slot two will only provide redundancy for the one in slot one is that correct???</description>
      <pubDate>Thu, 07 Feb 2008 20:38:00 GMT</pubDate>
      <guid>https://community.hpe.com/t5/bladesystem-general/ethernet-virtual-connect-question/m-p/792#M33985</guid>
      <dc:creator>duhaas</dc:creator>
      <dc:date>2008-02-07T20:38:00Z</dc:date>
    </item>
    <item>
      <title>Ethernet Virtual Connect question</title>
      <link>https://community.hpe.com/t5/bladesystem-general/ethernet-virtual-connect-question/m-p/793#M33986</link>
      <description>If you are looking for redunancy on a switch failure then yes that is my understanding - however if you are not after redundancy based on a connect switch failure you can place the ports in seperate network groups.</description>
      <pubDate>Thu, 07 Feb 2008 23:57:00 GMT</pubDate>
      <guid>https://community.hpe.com/t5/bladesystem-general/ethernet-virtual-connect-question/m-p/793#M33986</guid>
      <dc:creator>davidboulton</dc:creator>
      <dc:date>2008-02-07T23:57:00Z</dc:date>
    </item>
    <item>
      <title>Ethernet Virtual Connect question</title>
      <link>https://community.hpe.com/t5/bladesystem-general/ethernet-virtual-connect-question/m-p/794#M33987</link>
      <description>Not quite sure I understand the question.  You only have 2 VC-Enet modules.  Based on that configuration, there is no other VC-Enet module for the one in bay 2 to provide redundancy for other than the one that is in bay 1 - and yes, bay 2 will provide redundancy for bay 1 and vice versa.    However, if you are wondering whether or not the VC-Enet module in bay 2 can also provide redundancy for other modules that you might install later (i.e., installed in any of the other bays), then the answer is yes to any and all.  A Virtual Connect network can span any or all of the VC-Enet modules and thus can provided redundancy so long as you have the uplinks to your infrastructure configured appropriately.    Finally, what some people get confused about is the Virtual Connect Manager and how that works with regard to redundancy.   Each VC-Enet module contains a VC Manager.  However, only one module in a VC Domain will ever have an Active VC Manager.  The other module's VC Manager will either be dormant or in standby mode depending on where they are installed.  Only the VC-Enet modules that are installed into bays 1 and 2 can have an active VC Manager.  Any other modules installed in 3 thru 8 will have a dormant VC manager.    So, in a configuration where you have 4 VC-Enet modules installed in bays 1,2,3 and 4, you will only have the VC Manager running on bays 1 or 2.  On those two bays, the VC Manager will run in an Active/Standby mode.  Thus, bay 1 will typically have the Active VC manager running, while bay 2 would have a standby VC manager running.      Also, don't confuse the VC manager Active/Standby mode with network flow.  A module with a VC manager in Standby mode is still actively passing network traffic.    Hope that helps.  Dave</description>
      <pubDate>Fri, 08 Feb 2008 05:00:00 GMT</pubDate>
      <guid>https://community.hpe.com/t5/bladesystem-general/ethernet-virtual-connect-question/m-p/794#M33987</guid>
      <dc:creator>David Billot</dc:creator>
      <dc:date>2008-02-08T05:00:00Z</dc:date>
    </item>
    <item>
      <title>Ethernet Virtual Connect question</title>
      <link>https://community.hpe.com/t5/bladesystem-general/ethernet-virtual-connect-question/m-p/795#M33988</link>
      <description>Dave  Appreciate the long response, I think you cleared some things up for me.  The problem I was having hearing that if I have VC_Ents in slot 1/2 which I do, I didnt was a little frustrated in thinking that it was purely going to be a standby switch.  From what I am gathering from what you said, it still acts a part of a team if you will.</description>
      <pubDate>Fri, 08 Feb 2008 16:31:00 GMT</pubDate>
      <guid>https://community.hpe.com/t5/bladesystem-general/ethernet-virtual-connect-question/m-p/795#M33988</guid>
      <dc:creator>duhaas</dc:creator>
      <dc:date>2008-02-08T16:31:00Z</dc:date>
    </item>
    <item>
      <title>Ethernet Virtual Connect question</title>
      <link>https://community.hpe.com/t5/bladesystem-general/ethernet-virtual-connect-question/m-p/796#M33989</link>
      <description>That's correct.  Only the management element itself has a standby mode. The modules themselves are always fully active for network traffic.</description>
      <pubDate>Fri, 08 Feb 2008 17:15:00 GMT</pubDate>
      <guid>https://community.hpe.com/t5/bladesystem-general/ethernet-virtual-connect-question/m-p/796#M33989</guid>
      <dc:creator>David Billot</dc:creator>
      <dc:date>2008-02-08T17:15:00Z</dc:date>
    </item>
  </channel>
</rss>

