ACI L4L7 Service Insertion Pt. 1

Service Graphs are one of the most important features in ACI. The idea behind these service graphs is that you can create an application chain within ACI. Even better, you can configure the L4 to L7 devices directly from within ACI in an automated manner.

Many of my customers have several questions about service insertion. The question I get asked the most is “should I use service graphs?”. The answer to this question, as usual, is: “It depends”.

So, when should I use service graphs and when shouldn’t I?

Cisco provides a nice decision tree to determine whether you should use a service graph and what kind of graph to use. I’ve linked it below.

Service Graph decision tree

The problem with this tree is that if you follow it you’ll find the choice “Do you want to use service redirect? or Do you want the L4-L7 device to appear in the object model?”. I’ve asked many customers these questions. Nobody knows how to answer these questions.

For most customers, when they can’t answer the above questions with ‘yes’ on their own (without me directing them to an answer), they usually don’t need this. This is one of the reasons I haven’t implemented service graphs in any production environment. I know other people have, but so far the customers I visit have no requirement for this. Most companies that implement ACI have an existing network they want to migrate. These existing networks are often built in comparable manners. What I encounter most are two main scenarios:

  • A network with a single VRF in the datacenter which is not segmented further except for some (minor) ACLs. (They might have a DMZ VRF which they are not migrating to ACI)
  • A network with several VRFs that are used to create segments in the network, but without filtering (or again, maybe some ACLs) within the VRF.

Both these cases do not require service graphs, or at least, no firewall service graphs. In the second case the network is often built in ACI using VRFs in ACI. These match the VRFs in the classic network and use an L3out to connect the ACI VRF to the classic VRF. Sometimes these L3outs connect directly to a firewall if the classic network will be phased out.

Something else I encounter are companies that have very strict verticals in which the network team isn’t responsible for firewalls or loadbalancers. These are managed by separate teams that do not want to relinquish control of their devices to the network team. In those situations the managed services graphs are out of the question, but they might still want some other form of service graphs.

When you ask a customer whether they want more segmentation in their network they nearly always answer ‘yes’. However, most of the customers I visit have very limited insight in the applications and traffic flows on the network. This limited visibility hinders the implementation of any form of segmentation. (I actually encounter customers with one large ‘server’ vlan on a regular basis).

Without knowledge of the traffic flows it is difficult to create (firewall) service graphs. Insight in traffic flows is required for any kind of contract between EPG’s, more so for contracts with service redirection as a wrong configuration could potentially overload the L4 - L7 services.

In my personal experience, you shouldn’t use a service graph when you are building a network centric design. It doesn’t appear to be very useful in this type of setup. It is still possible to do so however.

So, when do you use service graphs? I generally use the following rules to determine whether a firewall service graph is the best solution:

  • Are the traffic flows known? Do we know what to allow, what to redirect and what to block?
  • Is the traffic between a limited set of EPG’s?
  • Can we work with an inside and outside interface on the firewall?

The last point is a direct recommendation from Cisco. They recommend to use regular L3outs to connect firewalls with many interfaces as it creates a lot of complexity to attach firewalls with many interfaces.

For loadbalancer service graphs, in my personal experience there are only two reasons to use them at all:

  • You want ACI to automatically configure the loadbalancer (which is relevant in rapidly changing environments)
  • You have a corner case design in which you are not using source NAT, but need to place the loadbalancer on another L3 segment in your network and need to PBR the replies from the real servers back through the loadbalancer.

In a next post I will discuss the various types of service graphs and how to configure them.