Forum Discussion
AubreyKingF5
Moderator
ModeratorHow do you handle Route Domains?
Through time, I've solved a million unique issues with route domains, as they allow you to lock down portions of your network, but more importantly, they allow you to overlap IP addresses. Some people find them scary. To me, I find that a simple organization plan at the beginning helps me to get things situated. I'm looking to see how other people approach design here.
Firstly, Route Domain 0 is special. I try to reserve that for 'on-box' communication, or critical data plane communication for services like DNS or upstream / downstream routes, depending on your use for the box, in general. I avoid putting any VIPs (besides SelfIPs or maybe a forwarding VS, if the need were there) on RD0 at all, as it is shared. If you think of your other route domains as 'tennants' of 0's 'host' services, you should succeed.
Community, if you've got a second, I'd love to hear your thoughts on this. How do you feel about route domains? Do you use IP overlap? Why or why not?
wlopezCirrocumulus
I've been using route domains (with strict isolation) paired with a dedicated partition since they first got supported.
Find them extremely useful, powerful and flexible.
As you said, main thing is to make sure you're organized on what things you want to keep under the default partition (Common) and route domain (0).
My main complaint with route domains for years has been that FQDN nodes are not compatible with them. If you create an FQDN node on a partition which already has a non-default route domain (Ex. 1) assigned to it, the dynamic IP FQDN nodes get assigned to default route domain '0'. I've opened several support cases over the years asking about it, but all responses ended up as a feature request for year 3274. Tried to accomplish the same result with iRules a few years ago, but never got anywhere.
- Kai_Wilke
MVP
When I started with F5-LTM i basically always used Route-Domains in every single setup. Nowaday I try to avoid them unsless there is a very good reason to use them. They add in most cases just unnecessary overhead...
For APM based deployments I'm more or less completly rejecting to use Route-Domain based scenarios. Its just annoying to explain the customers the even and odds of using Route-Domains and excuse slightly broken functionalities... 😉
Cheers, Kai
- Juergen_Mang
> A rough edge I can recall are certain limitations with APM
Thats why I try to avoid route domains as much as possible.
They're a great tool, but they have a few "rough edges" it can be helpful to be aware of.
When we were running big multi-tenant systems I coupled them with partitions so we could have per-partition subnets with their own default routes pointed out to the customer's firewall. This required per-customer VLANs, self-IPs. A plus for this was that it allowed us to move customers' services around between prod and DR without disturbing any other clients.
A more recent need was to ease a migration where multiple F5 LTMs were being merged and consolidated. An IP overlap of sorts occurred where I needed to use the virtual servers from one group of systems as the pool members for another group of virtual servers. Using the route domain to create a clone of my subnet allowed this, otherwise trying to use a virtual server as a pool member on the same box will not work.
A rough edge I can recall are certain limitations with APM, as well as certain advanced health monitors (Oracle DB is one) would fail due to compatibility problems.
That said, I don't use them if I don't need them, but when I do need them, they are a life saver.
