Comware-Based
cancel
Showing results for 
Search instead for 
Did you mean: 

HPE FlexFabric 5700 IRF LACP Traffic Redirect to ESX Servers

SOLVED
Go to solution
Eskimoe
Occasional Contributor

HPE FlexFabric 5700 IRF LACP Traffic Redirect to ESX Servers

I'm trying to figure out what the best practice is when configuring LACP in a IRF stack of two 5700 switches.
My goal is to be able to have all servers run LACP and if a switch happens to crash or fail, the network keeps on going.

Reading through the manual I see the command for edge-port is "lacp edge-port" on a bridge-aggregation interface. Having found this I thought I was done thinking about it, but then I found a section about something called "Link aggregation traffic redirection".

This section explains how the switch redirects traffic from one switch to the other.
For example it mentions this, "When you restart an IRF member device that contains Selected ports, this feature redirects traffic to other IRF member devices.".

I'm not sure if I even need this to achieve redundancy, but if I do need this in order to be able to have one switch crash/fail and keep the traffic flowing, how would I configure this and edge-port at the same time?

The section about restrictions and guidelines says this: "Link-aggregation traffic redirection does not operate correctly on an edge aggregate interface.".

Am I overthinking this or does HPE FlexFabric 5700 have something special in mind for redundant links?

Thanks!

 

4 REPLIES
parnassus
Honored Contributor

Re: HPE FlexFabric 5700 IRF LACP Traffic Redirect to ESX Servers

You aren't overlooking, indeed these BAGG related features are interesting...a first thing one should be aware of is that the feature link-aggregation lacp traffic-redirect-notification (that should be enabled/disabled Globally or per BAGG on latest Comware) should also be supported by the downlinked Host's NIC (it works for sure if downlinked device is another similar Comware based Switch, if instead downlink Host's NIC doesn't support it that can be cause of trouble more than benefits, read here)...instead the lacp edge-port feature enabled on a specific BAGG (read here) doesn't require to be specifically supported by your downlinked Host's NIC...so both are important but the former requires a little bit of fine-tuning than the latter.

Eskimoe
Occasional Contributor

Re: HPE FlexFabric 5700 IRF LACP Traffic Redirect to ESX Servers

Thanks for your answer Parnassus, it clears a few things up for me.

Although there is still one more question, with LACP and lacp edge-port configured, can a switch crash/fail and leave the other link connected to the server unchanged? As a normal LACP link should do, avoiding downtime in case one of the links fail.

Thanks!

parnassus
Honored Contributor
Solution

Re: HPE FlexFabric 5700 IRF LACP Traffic Redirect to ESX Servers

Eskimoe wrote: with LACP and lacp edge-port configured, can a switch crash/fail and leave the other link connected to the server unchanged? As a normal LACP link should do, avoiding downtime in case one of the links fail.

Yes, it's the LACP purpose to manage BAGG remaining links in order to keep the traffic flowing on BAGG member links that are/remain in Up (and Selected) state...my take: if a BAGG member link goes suddenly down and the link-aggregation lacp traffic-redirect-notification is not enabled on both (Switch/Server) ends (or it doesn't work due to downlinked Host's NIC not supporting it) a traffic disruption will happen on the specific physical link that has gone down (and so re-transmission should happens too, if data traffic targets are still reacheable by means of other paths, through remaining working BAGG member links connected to other uplinked working IRF Members).

Highlighted
Eskimoe
Occasional Contributor

Re: HPE FlexFabric 5700 IRF LACP Traffic Redirect to ESX Servers

Great, thank you very much Parnassus.

I've got this figured out now.

Have a nice day!