10-24-2018 11:26 PM - edited 03-01-2019 05:41 AM
Hi there,
I just need some clarity in understanding the deployment option of F5 load balancer ( or any 3rd party devices) in ACI.
Say for example, if I have F5 in 2 arm-mode(routed) and both the interfaces are in 2 different subnets and I need all the traffic coming from L3-out EPG going to Web EPG to be load balanced by F5.
Considering unmanaged device integration with F5, why do I need to create service graph instead Can't I just play with routing.
L3-out EPG ---- F5-out EPG ---- F5-in EPG ---- Web Server EPG
so when user sends traffic (dst ip=Virtual IP hosted in F5) , it would always hit the virtual IP of F5 device hence it would be sent to F5-out EPG looking at the routing table and then once F5 resolves it to the original web server , it directly sends traffic to Web Server looking at the routing details from F5-in EPG.
This is similar to legacy network.
I just wanted to know can this be achieved ? If not, then what are the reasons? How is it different from L4-L7 service insertion for unmanaged device ?
Appreciate your views.
Solved! Go to Solution.
10-26-2018 05:44 AM
If the F5 is performing the routing between the External and Internal EPGs then a contract is not needed. If you configure a contract between the Internal and External EPGs, the traffic could potentially go straight between EPGs and not through the F5. A service graph is not needed in this case.
10-25-2018 12:49 PM
Hi Raoul,
Theoretically speaking, I don't think there is any challenge in F5 to ACI routed connectivity approach and should function just like we have in traditional network.
For better insights on F5-ACI integration please refer below article, it also contains video link for F5-ACI configuration steps in unmanaged mode:
https://devcentral.f5.com/articles/unmanaged-mode-what-it-means-for-aci-and-big-ip-integration
Regards,
Jayesh
Rate all helpful posts!
10-26-2018 04:49 AM
Hi Jayesh,
Thanks for sharing the above link (very useful).
The above result can still be achieved by placing F5-out interface in External EPG/BD and F5-in interface in Internal EPG/BD. and create contracts between them.
So my question is why do i need service graph for this? How different is it from static mapping of interfaces to their respective EPGs? Is there any advantage of deploying this via Service graph ?
10-26-2018 05:44 AM
If the F5 is performing the routing between the External and Internal EPGs then a contract is not needed. If you configure a contract between the Internal and External EPGs, the traffic could potentially go straight between EPGs and not through the F5. A service graph is not needed in this case.
10-26-2018 06:06 AM
So in this case, when F5 is in 2 arm mode, connected to 2 different subnets, I can just add the respective interfaces in their EPGs and I would still work right?
Then what is the use of service graph and since it is not required in the above scenario then in what scenarios I need to consider using it?
10-26-2018 06:18 AM
As long as the routing between the different subnets is being performed by the F5, you can just add the interfaces into the respective EPGs.
Service graphs could be used to redirect traffic through the F5, firewall, etc... when these devices are not the default gateway for those EPGs...when the gateways reside on the fabric or other devices.
10-26-2018 06:36 AM
Thanks for the clarification.
One last question:
What if I have multiple applications residing in different EPGs that needs to be load balanced? For example, I would need to load balance web traffic for clients coming from outside then I can create a service graph where clients will be the consumer and web will be the provider. In addition, say I have 2 exchange servers which also has to be load balanced and are placed in different EPG (Service EPG) so in this case I would need to deploy another service graph where clients will be the consumer and Service EPG will be the provide ?
Or can I use the same service graph with 2 or more different provider EPGs and the same consumer EPGs ?
Or is there any other way which I am not aware off at this point?
10-26-2018 07:02 AM
You can reuse the service graph with different EPGs as long as it's the same device being used (same physical or virtual F5).
L4-L7 Parameters Best Practices
The flexibility of being able to keep L4-L7 parameters inside various managed objects allows the administrator to configure a single service graph and then reuse the graph for different tenants or EPGs with a different configuration. This section describes where you can place L4-L7 parameters.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide