Forum Discussion
Disaster Recovery (DR) for F5 Devices in Bypass Restoration
This is a difficult answer, as it may vary a lot depending on your setup. Can you give a better context?
So, you have a cluster of 2 appliances.
What are you using them for? Do they host business critical applications that resolve to F5 IPs? In this case, when both units are down applications will be unavailable, and there's no way to bypass F5 easily since you'll need to route all traffic in another way.
There's external appliances that can act like a "bypass" and monitor links to F5 devices, and when they see links down they forward traffic downstream on another link, but in this case destination will still be F5 IP's so you need to plan for a disaster plan that might involve updating DNS entries.
A workaround to this problem might as well be configuring F5 virtual servers with the same IP's of BE servers, so that with a bypass device there will still be something that respond to those IP's, but again with so little context it's difficult to consider.
Another thing that comes to my mind, which is the most straightforward, will be upgrading your cluster to three devices. If application availability is so critical to you that you need to plan for a double fault, this might as well justify the budget to improve redundancy.
Hello, and thanks for your feedback.
What external appliances that can act like a "bypass" and monitor links to F5 devices are you referring to? (i.e. switches, routers, firewalls)
Can an F5 L3 switch or router be used to replace both of the damaged F5 devices?
Or could you suggest any other way to solve the issue aside from RMA?
Thanks.
- CA_ValliApr 10, 2023MVP
I'm referring to TAP bypass appliances, for example like Garland.
https://www.garlandtechnology.com/network-tap
This will work pretty good when there is no NAT and your F5 is proxying something using the same IP address of the service, for example if you run a WAF. In this case when F5 is down TAP will forward traffic downlink and your routing processes will forward it to destination without packet loss.
Again, I think we need better context, for example if you rely on NAT and if virtual address IP's only exist on F5 TAP won't really do much and you still need to plan where to send this traffic when a disaster manifests.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com