5406R switch redundancy

[Bijukiv]

hi

Yes i am trying with 2 units of HP 5406. 

If a unit (no matter which one) will fail the other one will continue to serve its hosts and only its hosts, no more and no less.

this is the feature i am looking. if one of the switch fails or the links fails. its should take the other link or the other switch

At that point there will not be any "redundancy of operation" from the point of view of connected hosts because both units operate exactly as two standalone units not as a single virtual device.

Even i am trying to make the 2 units and single virtual device

Regards

Biju

[parnassus]

---

@Bijukiv wrote:

hi

Yes i am trying with 2 units of HP 5406. 

If a unit (no matter which one) will fail the other one will continue to serve its hosts and only its hosts, no more and no less.

this is the feature i am looking. if one of the switch fails or the links fails. its should take the other link or the other switch

You're writing what you want: you're looking full redundancy at (any) Hosts level. Right?

To clear up this very long thread, try to answer to this question:

How can a Host single linked to just one Switch to continue to work flawlessly when the Switch which is connected to fails (or just the single link fails)?

It can't! ...that's clear.

One possible caveat to that "NO-Exit" situation could be:

Any Host needs to be trunked (with LACP and at least two links) to a "Virtual Switch" (so in your case you need to form a VSF Stack) and each link of its Trunk needs then to be terminated to each member of the VSF Stack SO the Host's connectivity will survive against the total failure of one member of the VSF Stack AND will survive to a single link failure, no matters what happens. That's it.

5406R zl2 ===== VSF Stack ===== 5406R zl2
     |                             |
     |____________    _____________|
                  |  |
                  |  |
      any Host (mostly for Servers)

Each Host should have 2 physical links trunked together with LACP:

- 1st link of the LACP Trunk will terminate to the 1st 5406R zl2
- 2nd link of the LACP Trunk will terminate to the 2nd 5405R zl2

In this way:

Up to one Switch failure OR up to one Host-VSF Stack link failure can be
managed and the Host will not lose its connectivity to the VSF Stack (that, in
one case, splits itself).

It's important to understand that failures, if happen concurrently,
can't involve opposite "sides" of the connectivity (1st Member AND 2nd Link):

In this unfortunate case there is nothing more you can do in this scenario to grant
Host-VSF Stack connectivity.

Otherwise there is a manual brutal way: if you have just a single patch cord from your Host to your Switch/VSF Stack you can MANUALLY move that patch cord to the remainig survivor Switch or VSF Stack Member. But this is not elegant.

Both solutions will have a sense IF the routing rules/default gateway and all processing - from the point of view of the offended Host - don't change with the fault of any considered Switch/Link AND if routing/default gateway is redundant too!

This to say that redundancy of "connectivity" is somewhat helpful (single connectivity is necessary) but it's not sufficient di-per-sè.

At that point there will not be any "redundancy of operation" from the point of view of connected hosts because both units operate exactly as two standalone units not as a single virtual device.

Even i am trying to make the 2 units and single virtual device

Regards

Biju

---

To let those two units to form the VSF Stack (so they can act as a single virtual device) you need to fullfill/to grant the VSF requirements and understand the VSF restrictions.

[Stephen A Swain]

To employ full redundancy, the 5400R series can do either 1. VSF, 2. Dt-Trunk and 3. Meshed Switching/Routing, or 4. Basic NFT (network fault tolerance on hosts and gateways, using generic layer2/layer3 IP techniques).

1. As you don't have correct modules for VSF, not an option. You need the v3 modules with 10/40Gb.

2. For Dt-Trunk (distributed trunking), you can use LACP on hosts and terminate connections on different 5406R's, and use dt-trunk design to enable redundancy. But this also means you need to lacp to any "upstream" devices (e.g. core switches or routers). All connections to a dt-trunk pair should be with LACP across that pair to another LACP device, including whereever the default gateway resides. You wouldn't be putting a default gateway for any vlans on the dt-trunk switch pair. If you have vlan routing on these switches, then dt-trunk would not be an option. Have a look at the dt-trunk guide in the manual set for your model and version.

3. HP switch meshing should be an option and with those modules it should be possible to do concurrent meshing and routing. I've never done meshing myself, but maybe go and have a read of the meshing guide in the manual too.

4. If you are using your switches as intervlan routing and also want redundancy, then you won't be able to use VSF or Dt-Trunk, and instead go back to basics of layer2/layer3 redundancy using NFT (Network fault tolerance) on the hosts, and VRRP on the switches, and then setup OSPF routing between the switches. Then you consider how to provide upstream redundancy via something other than lacp, but this depends upon your network design and equipment on the upstream side.

Btw, it would be beneficial to produce correct network diagrams, including layer1, layer2, and layer3, including the upstream connections and equipment, otherwise there will always be some restriction on your options, that none of us can envisage beforehand.

[Vince-Whirlwind]

I think what does come through here is that network design is not something that can be taught to somebody with no relevant knowledge via an internet forum.

The OP is unable to document what he has, nor what it is he is trying to achieve, because he does not understand the fundamental principles of networking. He needs a mentor who can guide him through matching technologies with requirements.

[parnassus]

I agree 100% with @Vince-Whirlwind: it's believed that the presence of more/less experienced Networking Tutors and/or the presence of more/less experienced Community Users both ready to help in different ways and with different attitudes...fundmentally requires that a Community user shows a sort of learning attitude (forget about "I want/I need" imperative formulas very common as of today); in other words...a Tutuor without a Student which has/shows a real learning attitude is basically useless.

I don't want to be too harsh or polemic here (remember that I speak as an unexperienced user among very experienced users and professionals) but, IMHO, the paradox (other than a paradox is becoming an usual scenario) is that *sometime* who controls/owns (especially) expensive networking equipments seems then unable to exactly understand what he/she really owns, what to do with and how to deploy/mantain (like: "I have a 10500 and I want to do a Firmware update..." What? Are you joking? If you have a 10500 you shall know how to do that mate!).

Maybe I'm wrong and this OP is seriously trying to understand what he can/can't do with his particular networking device by studying manuals that he/she was able to find and/or doing testing using his/her personal procedures...but I'm a pessimist and I frankly doubt.