Forum Discussion

raymond_18680's avatar
raymond_18680
Icon for Nimbostratus rankNimbostratus
Jul 28, 2014

F5 Config Sync / Failover Link Speed Considerations

F5 - can you tell me: In an HA Configuration where I have (2) 10 Gbps ports on each F5 along with the traditional (8) 1 Gbps ports -

 

Do I need to use "One" 10 Gbps link to connect from F5 1 to the network switch and "One" 10 Gbps link to connect from F5 1 to F5 2 for purposes of Config/Sync and failover

 

  • or -

Can I LACP both 10 Gbps links as trunks directly to the Network Switch and use 1 or two of the 1 Gbps links to create the config sync / failover link between the two F5's?

 

I ask because I'm not sure if the F5 will need to pass 10 Gbps of traffic between the two F5's to keep them both in sync so that if there is a failover event it goes as smoothly as its supposed too.

 

I I don't need to use a 10 Gbps link to keep the two devices sync'ed up it gives the option to create an LACP between the F5 and the Network Switch with those 10 Gbps trunks.

 

2 Replies

  • I would recommend to use LACP thus you'll have the better resiliency. you don't need dedicate interfaces for synchronization traffic between devices. Using production interfaces and a dedicated vlan for that will make sure that you can track network outage closest to reality.

     

  • shaggy's avatar
    shaggy
    Icon for Nimbostratus rankNimbostratus

    If I have ports available, I usually dedicate a 'peernet' link (1gbps has always been fine for me) for f5-to-f5 connectivity, solely for the purpose of config-sync, failover, and mirroring. I then use HA-groups to monitor my production links (NOT the peernet link) to provide network-aware failover in the event production links fail. I always want my F5's to see each other and be able to communicate failover information regardless of connectivity to the rest of the network. If I don't have spare ports, I would do as Arnaud mentioned - tag a peernet VLAN across the production LACP trunk.

     

    I haven't seen a situation where I ever needed excessive capacity for the peernet link, but I've also not actively monitored usage of that link. The F5s are only transferring state information (failover state, HA scores), config-sync data (at most a full copy of the current local UCS), and mirrored data (connection table). I think you would be having other device/capacity issues well before you saturate a link with peer-to-peer communication