Software-defined networking continues to be a hot topic for businesses looking to streamline their networks and data centers.  With single pane of glass management, SDN offerings ease management workload as well as offer powerful automation tasks to enable your team to work smarter. Cisco’s offering to this realm, ACI, follows suit.  Under the covers, ACI functions by bending the traditional understanding of routing and switching.  IP addresses, MAC addresses, VLAN tags, and other familiar networking components are treated more abstractly, with the fabric doing much of the heavy lifting for you.  But what if you’re looking to take your SDN network to the next level: for example, how would an ASA firewall, abiding by the strict rules of traditional networking, mix with an SDN environment?

 

Those familiar with ACI will recall the L4-L7 device insertion capabilities, whereby devices such as ASA’s can be pulled in as part of the fabric for integrated deployment, management, and monitoring.  None of this changes the fundamentals of how the ASA works internally.  It is still an ASA, using access-lists, object-groups, and routing tables.  To accompany this, Cisco’s ACI and ASA integration offering presents two options: Go-Through (switched) mode, and Go-To (routed) mode. These correspond directly to the ASA’s native transparent and routed modes, respectively.  However, each mode imposes certain limitations as well. Go-Through mode significantly restricts the ability to route inside the fabric while using the ASA.  Go-To mode requires either complex routing on the ASA or locating the default gateways on the ASA for all hosts intended to utilize it.  For many companies looking to leverage ACI in their existing datacenters, these options present significant compromise.

 

Cisco responded accordingly, and in mid-2016 the ACI software received an update introducing a new addition to the Go-To mode: policy-based redirect.  This feature allows you to maintain much of the advanced routing and switching capabilities of the ACI fabric while inserting the ASA. However, there is one caveat.  The new PBR mode may allow the fabric to insert an ASA into the complex architectures possible within ACI, but the ASA is still an ASA, with none of the advanced ACI networking capabilities.  For basic implementations, such as using the firewall for protection between the ACI fabric and the greater external network, this can be engineered around using static or dynamic routing on the ASA.  But what if your security requirements are even greater?  What if, for example, you contain the traditional database, app, and web server hosts within your datacenter and wish to utilize the ASA to firewall traffic between each of them?

 

An independent ASA could implement such a design, using separate interfaces for each class of host, accompanied by well-chosen security levels and appropriate access-groups.  However, as your datacenter grows, this approach will likely exceed the ASA’s interface count, relying on an even more complex configuration of subinterfaces on top of the necessary static or dynamic routing needed to enable the firewall to properly direct traffic.  But when incorporated into the ACI fabric, this approach no longer works.  To allow the ASA to firewall traffic both to and from a particular host, such as the app server in the example above, the host’s IP address can no longer be strictly bound to a single interface on the ASA.  We need to think of routing within the ASA framework differently.

 

A possible answer comes from a somewhat intuitive examination of the ASA’s routing capabilities, compared with the ACI fabric.  In this example, we are utilizing PBR in the fabric to enable more advanced routing topologies incorporating the ASA.  Adopting a similar approach on the ASA provides a viable solution. The ASA received PBR capabilities in 2015, making this solution a real possibility.  As expected, performing advanced routing functions on a firewall platform presents unique challenges.  For instance, the return traffic of stateful firewall entries within the ASA are passed without matching the interface’s inbound access-list; this key component of the ASA, creating much of the functionality of the base firewall, makes PBR for return traffic impossible.  So the solution becomes a hybrid of PBR and default routing, where PBR is used for the initial traffic to create the state table entry, and default routing is used for the return traffic.

                         

As you can see, integrating devices such as an ASA into an SDN environment like ACI presents a new set of challenges, compounded by the multi-faceted involvement of routing, security, and data center technologies.  But the reward is a dynamic data center environment where security can be seamlessly inserted in architectures previously thought too impractical and complex to build.  For further information about SDN and how it can transform your business contact ROVE at info@withrove.com.

 

Comment

Member Login
Welcome, (First Name)!

Forgot? Show
Log In
Enter Member Area
My Profile Not a member? Sign up. Log Out