Deploying F5 load balancer in an existing ACI setup

[Raoul07]

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.

[Jayesh Singh]

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!

[Raoul07]

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 ?

[jachbr · Accepted solution]

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.

[Raoul07]

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?

[jachbr]

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.

https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-734298.html

[Raoul07]

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?

[jachbr]

You can reuse the service graph with different EPGs as long as it's the same device being used (same physical or virtual F5).

https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-734298.html

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.