Integrating the Cisco ASA with Cisco Nexus 9000 Series ... · accommodate the emerging virtualized...

Solution Guide

© 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. of 29

Integrating the Cisco ASA with Cisco Nexus 9000 Series Switches and the Cisco Application Centric Infrastructure

Data Center Design Opportunities

Modern designs for the highly secure data center concentrate on overcoming the constraints of traditional physical

hardware network infrastructures. Network designers strive to optimize physical device insertion points and

accommodate the emerging virtualized environments and applications. Although virtual computing promotes

topological abstraction and supports dynamic logical designs, the underlying network technology must

accommodate the computing layer within the limits of physical connections, VLANs, routing protocols, and

traditionally fragmented management models. Several features can be viewed as clear opportunities in future data

center architectures.

● Agile provisioning: Although application flows change dynamically along with business needs, physical

network topologies do not. For instance, all transit traffic may be directed through a security device simply

because that particular path cannot be easily avoided. Implementing VLAN segregation and dynamic

routing protocols for service insertion becomes a complex task, and it often results in suboptimal paths for

time-sensitive application traffic. The virtualized provisioning of computation resources has become a nearly

instantaneous requirement, and the associated network service devices must be instantiated just as quickly

and smoothly anywhere within the topology.

● Elastic scalability: As new computing resources and network service devices are added to the network,

the availability of switch port and power becomes a constraint around the critical application farms. Direct

physical connections are typically required to insert firewalls, traffic analysis tools, and other network

services as close to the application hosts as possible. The network should decouple the placement of

hardware devices from their functions and provide native load-distribution capabilities in order to scale with

business needs.

● Service virtualization: Traditional network services are still relevant within a virtualized environment, and

the physical-insertion model must be complemented with easy-to-deploy virtual appliances. A colocated

virtual device can effectively extend firewall, load balancing, and similar services to application flows

contained in the same computing hardware without the need to traverse a physical network. Such

virtualized services can be rapidly deployed and retired on demand, increasing the overall scalability and

versatility of the architecture.

● Unified configuration and visibility: Every network device typically uses its own configuration syntax and

interface. Virtualized environments are managed separately from the network infrastructure with minimal

shared control of common elements. A single point of network management, service provisioning, flow

policy control, and monitoring provides a unified view of the infrastructure and allows the contextual reuse of

common elements in an end-to-end design.

● Policy set simplification: Even when unified management applications are used to define the common

policy rule set, the administrator must either manually select the policy for each network service device or

push the same extensive rule set to all of them. As new rules are added to this set, obsolete rules are rarely


retired because the operational decoupling between service devices and application flows results in

obsolete rules remaining in place. In the end, the configured policy set no longer matches the desired

topology. The network must be intelligent enough to apply or retire rules on service devices based on the

current application and policy needs. A layered model should be used to classify and filter traffic as close to

the point of entry as possible. Each service device should be contextually programmed with only those rules

that are relevant to the specific transit flows, creating a truly distributed and simplified policy set.

Although recent developments in the area of software-defined networking (SDN) have produced solutions that

mask some of the challenges, none of these products solve the underlying problem with the traditional physical

network. A typical shortcut is to preconfigure network devices with basic terminal scripts and overlay a complex

mesh of virtual tunnels to assist with the traffic engineering tasks. Full Layer 2 and 3 connectivity is still required

within the underlying data center network, so the complications of VLAN segregation and IP routing continue to

apply. As a result, the network administrator must now manage two networks, the physical and virtual. Many such

models remain central to virtual computing, and none of them attempt to break away from the traditional network

limitations or concepts. The simple conclusion is that the network itself must gain the speed and intelligence to

adapt itself to its applications and the associated services.

Next-Generation Data Center Fabric Architecture

The Cisco Nexus® 9000 Application Centric Infrastructure (ACI) framework revolutionizes the traditional data center

model by separating logical and physical network topologies and supporting centralized control, automation, and

service orchestration. The next-generation data center fabric becomes an ultra-high-speed physical network itself,

so it can dynamically configure and interconnect heterogeneous external devices based on application policy

needs. The Cisco® Application Policy Infrastructure Controller (APIC) represents a single point of orchestration,

distributed policy provisioning, and network intelligence. This new model abstracts the network into the following

components:

● Fabric nodes are powered by the Cisco Nexus 9000 switch platform. Spine nodes create the core of the

intelligent fabric, and they interconnect leaf nodes, which provide connections for external physical

endpoints into the fabric. The longest path between two leaf interfaces anywhere in the fabric is always

through a single spine node. The overhead of such point-to-point connections through the fabric measures

in nanoseconds, which is negligible as far as the hosted applications and network services are concerned.

This light-speed connectivity almost eliminates the need for hardware colocation and directly addresses the

elastic scalability goal.

● Service consumers are simply the endpoints that rely on network services. They can be physical devices

of virtual machines. Typical service consumers are the data center application servers or their clients, but

they can also include external network connections. Both physical consumer devices and the computing

server hosts connect to the fabric through leaf nodes.

● Service producers are the typical network service devices, such as firewalls, intrusion detection and

prevention systems, network analyzers, SSL accelerators, and other in-line traffic processing systems.

Physical service producers connect to the fabric directly through leaf nodes. Virtual service producers

logically link into the fabric through port groups that are extended to the leaf node through the underlying

physical server hardware; this capability directly supports service virtualization.

● Endpoint groups (EPGs) define similar service consumers in terms of application services and usage. For

instance, all web servers on the same network segment may be grouped into a single EPG. Each physical

or logical fabric leaf port belongs to a particular EPG, and you can group any such ports into any number of


EPGs. Networks that are external to the fabric are represented as EPGs as well. The fabric controls the

communication between different EPGs according to a configured policy set, and the default behavior is to

drop all inter-EPG traffic.

● Application profiles describe network parameters, such as subnets and default IP gateways, for service

consumers in each EPG. The fabric acts as the default gateway for each subnet, and it can assign IP

addresses automatically or rely on the pre-existing addressing scheme. For consumers within the same

subnet, the fabric transparently bridges them regardless of the physical location. In addition to supporting

agile provisioning and elastic scalability, application profiles help enable unified configuration management.

● Contracts describe the traffic-filter rules and service requirements for network communication between

EPGs. Because EPGs are defined at the fabric port level, the contracts allow fine-grained hardware-

accelerated policies at the individual application level. Contracts define what flows should be allowed from a

given EPG, what network services should apply to these flows, and whether any fabric prioritization is

required. For instance, a contract between Web and Database EPGs may allow only backend database

connections and force such traffic through external firewall and intrusion prevention system (IPS) services.

This layered filtering approach paves the way for simplification of the overall policy set.

● Service graphs (SGs) or service chains are ordered processing sequences of inter-EPG traffic through

service nodes based on the established contracts. For each allowed flow in a contract, the associated

service graph defines the packet path through the network producers. For instance, the administrator may

direct all HTTP traffic on TCP port 80 to traverse a stateful firewall policy, then an IPS and a network

analysis device. Service graphs allow for a greater level of device-level rule abstraction and reuse that also

supports policy set simplification.

Figure 1 illustrates a fabric view of the network and its physical and virtual devices. Any device attaches to the

fabric at any available port at any physical location. The desired topology is created completely by the fabric itself,

so scaling can be extremely elastic. All spine nodes connect directly to every leaf node, which brings inherent

reliability and network path optimization. Service consumers in a single EPG or subnet can be located anywhere

within the topology and still communicate in a completely transparent fashion. Virtual and physical consumers

grouped in a single EPG can use both physical and virtualized services from the producers. Additional virtual

service producers can be instantiated and retired by the fabric based on immediate network needs, helping to

enable the agile provisioning of services. The fabric can intelligently balance flows across multiple service

producers even within a single contract and maintain symmetry for stateful devices.


Figure 1. Fabric Network Setup and Device Attachment

Figure 2 depicts Web and Database EPGs, which receive network settings from their respective application profiles

within the fabric. All communication from Web EPG to Database EPG must go through the associated policy

contract. Based on this contract, the fabric port ASIC (application-specific integrated circuit) immediately denies all

Telnet traffic from Web service consumers to any Database consumer and allows all TCP connections from Web

consumers to Database consumers on ports 1400 and 1401. All permitted traffic from any Web consumer to any

Database consumer is redirected through the service graph. The service graph contains a firewall device that

statefully inspects all traffic based on more specific policies. Once the firewall permits a packet, it will be delivered

by the fabric to the appropriate consumer in the Database EPG. All other traffic from Web to Database is dropped

by the fabric. This approach to flow forwarding perfectly illustrates the policy set simplification aspect of the fabric.

Some basic IP and transport-port-based rules are applied directly at the port level, so the blocked traffic does not

consume network resources. The firewall in the service graph can apply more detailed rules, including application

inspection where the secondary connections are permitted automatically; in that case, the fabric filter must be more

permissive.

Figure 2. EPG Flow Abstraction with Application Profiles, Contracts, and Service Graphs


In addition to controlling the network itself, the Cisco APIC is also capable of pushing device-specific policies to the

service producers through standard APIs. Network service administrators can define such policies on the APIC and

expose associated service instances for insertion into the inter-EPG contracts. For instance, a security

administrator can create firewall configuration templates that follow the general organizational security policy for

each tier of traffic. These templates will be exposed to application and network administrators who simply need to

define the EPGs, create the contracts for flows between these EPGs, and instantiate firewall services using the

predefined templates for the service graphs. This level of abstraction allows contract creation at the application

level without knowledge of the specifics of the firewall configuration.

Once all of the elements of a service graph are defined, the fabric instantiates the appropriate services on physical

or virtual devices and programs the hardware port rules. Figure 3 illustrates service graphs between multiple EPGs

within the fabric. Notice that application traffic from the Users EPG can traverse to either the Web EPG or the Files

EPG with both shared and unique service producers in the path. The fabric creates a loop-free path through the

service nodes to assure single-pass processing within each service, such as the SSL accelerator and firewall in

this example. This approach optimizes the use of processing resources on the service producers and of the shared

device-specific policy templates. As another example of agile provisioning capability, the new fabric model simply

removes any ties to the underlying physical hardware from the logical application flow design. This service

producer sharing capability across multiple service graphs depicts a future functionality of Cisco ACI.

Figure 3. Optimal Service Graphs

Even though application, network, and service administrators have different roles, all their tasks can be

accomplished using REST API through the Cisco APIC. This makes possible a unified point of orchestration where

all policies are deployed or retired based on the most current application and network configuration that the fabric

maintains. All administrators can also monitor and troubleshoot the network from a single interface. Role-based

access control (RBAC), change control, and audit capabilities are inherently provided at the network level, because

all devices are controlled in a centralized fashion from the APIC.

Transition Path to a Fabric Environment with ASA

The Cisco ASA 5585-X appliances as well as the new virtualized ASA (ASAv) platform integrate transparently into

the intelligent fabric model as service nodes, supporting the full range of stateful security capabilities in the next-

generation data center. Depending on the type of deployment and state of readiness for the data center

transformation, multiple paths are available for implementing a highly secure data center with Cisco Adaptive

Security Appliances, the Cisco Nexus 9000 Series Switches, and the Cisco APIC.


Standalone Mode

If an immediate migration to the fabric model is not feasible, Cisco Nexus 9000 Series Switches still provide higher

interface density at lower per-port costs. The fully interoperable ASA clustering solution supports flexible scaling of

firewall forwarding capacity with Cisco ASA 5585-X appliances for north-south flows. Hypervisor-agnostic ASAv

instances can effectively protect east-west traffic.

The Cisco ASAv can perform the same functions as any ASA appliance that now simply resides on a hypervisor.

An ASAv instance can be colocated with the protected virtual machines to use the traditional bridging and routing

capabilities and contain the interapplication flows to the same hardware host. Unlike the Cisco ASA 1000V Cloud

Firewall, the ASAv can maintain its own data path with no dependency on vPath or the Cisco Nexus 1000V. Similar

to any service VM in the Cisco ACI environment, Cisco ASAv works also with a Cisco Application Virtual Switch

(AVS).

This approach prepares the network for a fabric migration at a later point, and the Cisco Security Manager can be

used for centralized ASA management and monitoring in the interim.

Traditional Mode

Building on the previous case for a gradual migration into the fabric environment, this model adds intelligent service

and policy provisioning capabilities while maintaining traditional bridging and routing configuration on the Cisco

ASA instances. The applications are abstracted into EPGs, and contracts are used to define application flow

policies between different EPGs. The security administrator creates ASA-specific configuration templates, so

firewall services can be instantiated within the service graphs for inter-EPG traffic. This approach adds policy set

simplification to the list of benefits.

Within the physical domain, the ASA data plane typically connects to leaf fabric nodes in a “firewall on a stick”

fashion. When operating in a virtual domain, ASAv instances are hosted on physical server hardware that connects

to the fabric in a similar manner. This interface is used to carry network application data across service graphs

between the fabric and the Cisco ASA, so it is called a carrier interface. Transit packets destined for security

inspection in a service graph arrive to the ASA on this interface and leave from the same interface back into the

fabric. In addition to this data plane interface, ASA consumers typically have management and utility interfaces as

well. The management interface is used to configure and monitor the ASA from the APIC, and the utility interface is

used to reach Domain Name System (DNS), authentication, authorization, and accounting (AAA), Network Time

Protocol (NTP), and other services that ASA requires in normal operation. These additional interfaces connect to

the fabric as service consumers, so they never carry any transit application traffic.

Figure 4 presents a logical diagram of the carrier interface connection for both an appliance and an ASAv instance.

Multiple physical carrier interfaces are supported, but a single instance is typically configured for simplicity and

scalability. A fabric-enabled ASA still supports full high availability and scalability functionality with failover and

clustering. Both regular and spanned EtherChannels can be used as carrier interfaces when additional bandwidth

aggregation is necessary.


Figure 4. Cisco ASA Fabric Attachment

The traditional insertion mode is based on configuring the carrier interface as a VLAN trunk. The fabric extends the

ingress and egress VLAN pair to each ASA and applies a desired policy on traffic that traverses this pair in either

routed or transparent mode. The same approach can be used with multiple physical interfaces. Figure 5 illustrates

the VLAN-based insertion process for an ASA running in transparent mode. In this example, each bridge virtual

interface (BVI) represents a firewall instance in the corresponding service graph. The associated security policy is

defined by the template that is referenced by the inter-EPG contract. All these decisions are made at the fabric

level, and the ASA needs no awareness of the surrounding topology or the traffic flow.

Figure 5. Transparent Mode ASA Insertion in Traditional Mode

Ingress packets for each graph arrive on the trunk carrier interface with an appropriate VLAN tag. After

decapsulation, these packets are pushed through a corresponding bridge group, where the associated security

policy is applied. Using the regular MAC bridging table, the Cisco ASA sends the packets back to the fabric using

the other VLAN in the bridge group. The fabric will deliver these packets to another device in a service graph or

direct to the destination consumer. It should be noted that the ASA continues to use regular MAC bridging tables in

transparent and routing tables in routed mode for next-hop discovery in this transitional insertion mode. The APIC

is still capable of intelligently stitching the ASA into the traffic path using these methods through a unified

orchestration channel.


Multiple Cisco ASA appliances can be connected to different leaf nodes to create distributed firewall service farms

with ASA clustering. This functionally allows the reuse of existing ASA hardware and extends the usable life of

previous network infrastructure investments. Since the fabric abstracts network connections through service

graphs, the physical positioning of the firewall farm members does not have to change when the new application

flows are instantiated. This logical abstraction and topological decoupling removes the requirements to supply

firewalls with switch ports and power capacities near the application server farms.

The fabric supports stateless load-sharing between the participating firewall instances while supporting flow

symmetry through the service graph. The service graphs also help to open the best possible path through the

associated network resources, so all firewalled traffic for a given flow is inspected in a single pass. ASA clustering

internally compensates for the external load-balancing asymmetry to provide true stateful scalability with up to 16

ASA5585-X appliances in a single logical firewall service farm.

Deployment of the Cisco ASA becomes a streamlined process in a next-generation data center that relies on

Cisco ACI:

● ASA appliances are cabled up, connected to the fabric leaf nodes, configured with basic management

information, and registered with the fabric. From that point on, all configuration tasks are automatically

performed by the fabric itself. On-demand ASAv provisioning can be automatically instantiated by the Cisco

APIC through an API.

● Using the APIC, the network administrator configures device-level ASA parameters, such as failover,

clustering, and carrier interfaces. The standards-based REST API is used to abstract fabric-driven

management tasks from the traditional ASA configuration syntax and interface.

● Using the APIC, the security administrator defines standard templates for firewall rules based on the

organizational security policies. The configuration is held within an abstract service graph that is not tied to

any particular physical device. This configuration is imposed on an available and compatible firewall

instance when the service graph is attached to a specific policy contract. These templates are used to

instantiate firewall services from within the contracts without the need to understand ASA operational and

configuration models.

● Using the APIC, application administrators define EPGs and associate them with policy contracts for

interapplication traffic. Standard firewall policy templates are used to attach ASA services to the application

flows. The associated policies are transparently instantiated on the available ASA and other service

producers that are to be inserted into the optimized service graphs. When the application flows change or

expire, all the related policy sets and service instances are automatically decommissioned.


ASA Service Insertion Workflow in APIC

Using the Cisco APIC northbound API, the insertion of Cisco ASA firewall services in Cisco ACI tenants can be

fully programmed. The same API objects are equally accessible in the APIC GUI, so administrators can review and

refine any configurations through the GUI after initial script deployment. Figure 6 shows a logical workflow

composed of five basic steps needed to add an ASA service and graph it into EPGs. Upon completion, this

workflow creates a tenant and renders a service graph in the fabric. Cisco ASA devices are set up to allow

registration, and the APIC can then orchestrate the ASA data plane for a given tenant.

Figure 6. Cisco ASA Service Insertion

To address the workload, a tenant can define additional ASA service devices and consume those into new service

graphs. Further, any service graph can easily be upgraded or downgraded in order to make use of any registered

ASA devices of different performance levels.

Here are the five general steps in creating a tenant with Cisco ASA services:

1. Create the tenant: The tenant must be created along with its application profiles, EPGs, bridge domains

(BDs), and contracts before any Layer 4 through Layer 7 (L4-L7) services can be added. Please refer to Cisco

APIC documentation for more details on this step.

2. Define the Cisco ASA L4-L7 service device cluster: Allow for virtual (VMM) or physical domain clusters of

concrete Cisco ASAv or ASA 5585 devices.

3. Create the service graph: Create Cisco ASA security policies for provisioning to any registered ASA device.

4. Define the logical device context: Establish mappings between ASA terminals and BDs, and to their

underlying ASA logical clusters.

5. Apply the graph to the contract subject: Verify the Cisco APIC configurations and provision the graph and

services in the fabric.

In Step 5, the firewall service is provisioned for the tenant. The Cisco APIC renders the graph in the Cisco ACI

fabric and orchestrates the ASA data plane to connect the ASA into communication between EPGs. The ASA can

serve as a routing or bridging device.


Product Version Compatibility

This integration guide is based on the ASA device package and versions of the APIC and fabric switch software

specified in Table 1. As the Cisco ACI solution evolves, the Cisco APIC GUI will naturally change, prompting

relevant changes in the Cisco ASA device package.

Table 1. Cisco ASA in Cisco ACI: Product Versions

Product Software Version

Cisco APIC 1.0.1e

Cisco Nexus 9000 Series Switches 11.0.1b

Cisco ASA device package 1.0.1

Cisco ASA 5585-X 8.4 or later

Cisco ASAv 9.2.1 or later

Implementing Traditional Mode Insertion with ASA Services

The following discussion covers the GUI aspects of adding a Cisco ASA firewall to a tenant’s L4-L7 services. The

ASA device package imports firewall features into the Cisco APIC and exposes ASA configurations through the

GUI or API. The ASA integrates into the Cisco ACI as a service producer in these modes:

● Go-To: The routed firewall maintains static or dynamic routing and Address Resolution Protocol (ARP)

tables.

● Go-Through: A transparent firewall bridges VLANs and tracks MAC address tables.

These two modes are selected in the APIC and must be matched with adequate ASA firewall mode configuration.

Importing the ASA Device Package

For the Cisco APIC to understand Cisco ASA capabilities, the ASA device package must be imported. Multiple

versions of the package can be installed in the APIC. The steps are as follows:

1. Navigate to L4-L7 SERVICES > PACKAGES.

2. Right-click on L4-L7 Service Device Types and choose Import Device Package.


3. Import and review the latest ASA device package, previously downloaded from Cisco.com.

ASA configuration parameters can now be expanded in the APIC, exposing the features supported by the imported

version of the device package.

Preconfiguring the ASA Device

Registering a Cisco ASA device requires a basic configuration on the ASA to support highly secure network

connectivity and match the corresponding credentials provided to the Cisco APIC. Before applying the

preconfiguration, the ASA device should be placed in the appropriate firewall, then in the clustering mode. The

ASA spanned interface mode can be used in Cisco ACI to achieve the best level of redundancy, where existing

connections are synced throughout the cluster and continue even on ASA node failure. Further, the appropriate

ASA firewall mode must be entered, transparent for Go-Through or routed for Go-To, as an option under the APIC

device cluster (ASA by default comes up in routed mode):

!For Go-To mode

no firewall transparent

!For Go-Through mode

firewall transparent

!For ASA Spanned Cluster Interface mode

cluster interface-mode spanned

Optionally, Cisco ASA running code 9.2.1 or later has a restricted debug-only command-line interface (CLI),

commonly used by the Cisco Technical Assistance Center (TAC). This CLI allows a strict fabric management

mode, where only the Cisco APIC is allowed to apply a new configuration to the ASA device. When enabled, the

ASA configuration is cleared and preconfiguration is allowed by means of the CLI in order to register this device in

the APIC. From this point forward, the configuration can be built on that ASA only through the APIC GUI or API. To

bring the ASA out of this mode, one must negate this management-mode CLI and recover full configuration ability

in the CLI. To use the ASA clustering, administrators must configure it using CLI or the Cisco Adaptive Security

Device Manager (ASDM) before registering the primary with the APIC. Consequently, the clustering feature does

not support the fabric management mode.

!Enable advanced settings

service internal

!Enable fabric-controller management-mode

management-mode fabric-controller


The following ASA preconfiguration allows the Cisco APIC to register the ASA device under L4-L7 services. The

ASA M0/0 interface is connected to a separate switch, outside the fabric, and is reachable from the APIC.

!Management interface (OOB)

interface Management0/0

nameif management

security-level 100

ip address 10.1.1.36 255.255.0.0

!Credentials for ssl session

aaa authentication http console LOCAL

http server enable

http 0.0.0.0 0.0.0.0 management

username admin password <device_password> encrypted privilege 15

!Route needed to reach APIC

route management 0.0.0.0 0.0.0.0 10.1.0.1 1

!Ensure Crypto key is present on ASA

!aci-asa1# sh crypto key mypubkey rsa

Key pair was generated at: 13:45:59 UTC Jul 16 2014

Key name: <Default-RSA-Key>

Usage: General Purpose Key

<snip>

The Go-To ASA Routed Firewall

The routed firewall mode on the Cisco ASA matches the Go-To mode in L4-L7 services. The fabric routes traffic to

a Layer 3 ASA device, the security policy is applied, and the ASA then forwards packets back to the fabric on the

second interface.

Before adding L4-L7 services, a tenant must be created with its basic EPG, BD, and contract constructs.

ASA L4-L7 Service Device Clusters

Service devices in the Cisco APIC are consumed in clusters, associated to either a physical or a virtual (VMM)

domain. Each device cluster may contain multiple concrete ASA devices, provided they fit into the appropriate

domain. That is, the Cisco ASA 5585 belongs in the physical domain, and the ASAv must be in the VMM domain.

Note that the APIC cluster is a generic construct which allows multiple concrete devices to share the application

load with out tracking state information. An ASA cluster can be a concrete device under an APIC cluster and

extend state sharing and greater resiliency in the Cisco ACI fabric


To create a device cluster, you must select an appropriate tenant and follow these steps:

1. Navigate to the tenant and expand the L4-L7 Services folder.

2. Right-click on Device Clusters and choose Create Device Cluster.

3. For a physical ASA, indicate PHYSICAL under Device Type and add connectivity details. The ASA must be

preconfigured as indicated in the screen below to allow the Cisco APIC to open an SSL connection to the ASA

and gain administrator rights.


4. For ASAv device clusters, the Device Type is VIRTUAL, and the appropriate VMM domain ASAv instance is

filled in, along with the connectivity and interface mapping parameters.

5. Next we create L4-L7 Concrete Devices under the cluster. Examples for physical and virtual devices are given

below.

The Cisco ASA 5585 concrete device requires selecting path information from a pull-down menu of known leaf

switch ports. The Interfaces section shows the mappings of ASA 10 Gigabit Ethernet ports to leaf ports and the

logical connectors.


The virtual ASA example includes information on the VM and vCenter names. These names help the Cisco APIC

identify the VM and assign vNICs to the given service graph port profiles it created on the Cisco AVS or distributed

virtual switch (dvSwitch). When mapping vNIC interfaces, Network adapter1 matches the Management0/0 interface

on the ASAv, and the remaining data plane interfaces are started from Network adapter2.

High-availability and port bundle device parameters are shown in the next window. IP address parameters are

added later under Security Group settings.


You can define the Cisco ASA device under the cluster.

Next you can define the ASA parameters to be applied to this device.

Finish creating the device cluster and then verify that the ASA device is registered with the Cisco APIC and is in a

stable state. Navigate and select the new cluster created under L4-L7 Services > Device Clusters folder.


Creating a Service Graph

Navigate to the Service Graphs folder under L4-L7 Services and choose Create L4-L7 Service Graph.

Drag the Firewall service node to the graph and connect the internal and external terminals to the Provider EPG

and Consumer EPG, respectively. Each ASA connection should be L2 adjacent to the EPG. Select “config function

parameters” in the service node to define the data plane and security policy parameters.


The Cisco ASA IP and security policy configuration can now be added under Firewall configuration function

parameters. These parameters can later be updated under the Service Graphs folder.

For example, let’s take the IP topology shown in Figure 7, where ASAv is the Go-To device between two EPGs.

Figure 7. Tenant1 Diagram with ASAv as a Default Gateway


You can update the ASA parameters to define two ASA interfaces and associate them to external and internal

connectors under the Function Config folder.

The interface names (i1 and i2) translate to the ASA interface names defined under the nameif CLI.


Next you can create a second interface with a name, an IP address, and security-level settings.

In the Function Config folder, external and internal interface mapping is established to the newly defined interfaces.

Now the data plane portion is defined and all the ASA features that are exposed in the device package, like access

lists, NAT, and inspection capabilities, can be configured under the security group. Multiple security groups can

expose different levels of security policy.


Creating a Logical Device Context

Navigate to Device Cluster Selection Policies, under L4-L7 Services, and right-click to Create Logical Device

Context.

Select the cluster to be used with all the service graphs, or specific service graphs, as shown in the next screen.

You can also bind logical connectors to the appropriate bridge domains.

Now we are ready to apply the service graph to a contract.


Applying a Service Graph to a Contract Subject

Navigate to Security Policies > Contracts > Contract, and select the subject.

Under the Service Graph pull-down menu, select the graph created earlier and click Submit.


The APIC now renders the graph in the fabric and orchestrates the data plane on the ASA leaf and virtual switches.

To verify that the device cluster and service graph have been deployed, make sure they are shown under their

respective Deployed folders.

Following are Go-To examples of Cisco ASA 5585 and ASAv data plane interface configurations added by the

Cisco APIC. For the ASA 5585, 10 Gigabit Ethernet (TenGig0/6 and 0/7) ports are used as trunks, where VLANs

are dynamically selected from the VLAN pool and configured on the ASA.

! ASA5585

interface TenGigabitEthernet0/6.771

vlan 771

nameif i1

security-level 100

ip address 10.1.1.2 255.255.255.0

!

interface TenGigabitEthernet0/7.738

vlan 738

nameif i2

security-level 0

ip address 10.2.2.2 255.255.255.0


ASAv GigabitEthernet0/0 and 0/1 ports are placed in the appropriate virtual switch port profiles and updated with

the given parameters.

! ASAv10

interface GigabitEthernet0/0

nameif outside

security-level 0

ip address 10.1.1.2 255.255.255.0

!


nameif inside

security-level 100

ip address 10.2.2.2 255.255.255.0

!

The Go-Through ASA Transparent Firewall

The Cisco ASA transparent firewall matches the Go-Through mode in Cisco APIC L4-L7 services. In this mode, it

is recommended that flooding be enabled in BDs that connect to the ASA. Flooding allows the ASA to learn the

MAC addresses and to apply security policy to the bridged interfaces

The Go-Through mode setup is similar to that of the Go-To workflow, except that endpoints are on the same

subnet. In this mode, an ASA bridge group is defined with internal and external interface members and the

appropriate security levels. A single IP address in the same subnet is assigned to the BVI, which can be used to

verify connectivity issues to the endpoints. Cisco ASA security policy access control lists (ACLs) and inspections

are applied in the same fashion but reflect the given endpoint IP information. Consider the topology in Figure 8,

where the ASA bridges two connectors into one broadcast domain.


Figure 8. Example of Tenant1 with ASA 5585 Transparent Firewall

When the Go-Through option is selected under Device Cluster, you can configure the Cisco ASA configuration

transparent firewall under the service graph.

1. Navigate to the BridgeGroupIntf folder and define a bridge group ID, from 1 to 100. Then add a BVI IP address

and mask as shown below.

2. Next add a first interface configuration (i1), and place it in the created bridge group.


3. A second interface is added and assigned to the same bridge group.

4. The Function folder is updated in the same way as in the Go-To mode.


This completes the data plane configuration needed for the Cisco ASA to bridge the two terminals in the service

graph in a Go-Through service device mode. The rest of the steps given in Go-To section apply here in the same

fashion. The parameters defined in the Cisco APIC translate to the following ASA configuration:


nameif i1

bridge-group 2

security-level 100

!


nameif i2

bridge-group 2

security-level 0

!

interface BVI2

ip address 10.1.1.100 255.255.255.0

Workarounds for Unsupported ASA Features

The Cisco ASA device package for integration with the Cisco ACI fabric keeps improving. Before full support for

new product features is available, a hybrid approach can be used. One feature in high demand is support for

multiple contexts in the device package for the Cisco ASA 5585-X physical appliance.

To configure virtual ASA contexts in the Cisco ACI without their support in an existing device package involves

additional ASA preconfiguration before the Cisco APIC takes over the rest of the policy control. To do this, take the

following steps to allow the APIC to register each context as a separate ASA service producer in the ACI fabric.

1. Inside the ASA system context, preconfigure a port-channel VLAN trunk interface with two leaf switches,

forming a one-arm logical interface on the Cisco ASA 5585-X appliance(s). Note that this hybrid approach is

more difficult to implement without a one-arm port channel. Further, if clustering or failover is used, those

settings must be configured in the system context.

2. Using a range of VLANs defined in a VLAN pool in the ASA 5585-X physical domain, preconfigure all VLAN

subinterfaces in the system context. Note that this VLAN range must hold an even number of VLANs, since all

APIC assignments are in pairs.

3. Define all user contexts from the system context with the allocated management interface, and assign all port-

channel subinterfaces to each user context.

4. Inside each user context, define the firewall mode and a unique management IP. At a later point, the Cisco

APIC will dynamically allocate VLANs from a pool and configure them appropriately inside a user context.

5. Add the remaining preconfiguration to each context so that the APIC can properly register the ASA contexts.

At this point, the Cisco APIC can be instructed to contact and register each ASA context as a separate service

producer to the ACI fabric. The APIC still needs to use a port-channel ID (Port-channel2) for each user context. As

a result of the hybrid approach, certain configuration commands issued by the APIC fail gracefully, and the rest of

the ASA policy and data plane is configured as expected.


The following highlighted configuration commands are not allowed in user context and do generate APIC warnings:

New Model and Future Horizons

The new fabric-based model brings many unique architectural and operational advantages that solve rather than

hide problems with traditional data center networks. Hardware-accelerated point-to-point connections within the

fabric eliminate the need to colocate and dedicate computing and network service devices. A flexible set of flow

parameters is used by the ingress fabric ports to block, mark, or redirect traffic toward rapidly provisioned service

instances on physical and virtual device farms.

You can use additional Cisco ASA 5585-X appliances or ASAv instances to elastically scale a highly secure

network as necessary without worrying about specific insertion points, localized port availability, or the classic

limitations of VLANs and dynamic IP routing. When Cisco ASA services are applied, every packet of the flow

receives the full set of stateful security checks in a single pass. The multiple layers of filtering with generic service

contracts and ASA-specific rules allow a high degree of policy set simplification. As application needs evolve, the

appropriate policy sets and firewall instances can be retired or repurposed automatically.

The Cisco APIC creates a unified orchestration and visibility point for the fabric, service nodes, and individual

consumers with built-in RBAC support, distributed policy deployment, health visibility, and inherent change-control

capabilities. Even though the entire network is orchestrated from a single interface, this model creates a high

degree of abstraction among application, network, security, and other network services. A firewall administrator

configures generic templates that describe the Cisco ASA policy for each application flow group, and the

application and network administrators instantiate these templates for specific flows without having to learn

ASA functionality.

The interoperability of all interconnected fabric devices is validated by Cisco and backed by award-winning Cisco

TAC support. Problems are bound to happen with any product or service, and having a team of experts available

around the clock to resolve any problems makes all the difference when every second of downtime counts. There

is no need to be bounced between different vendors when everything can be solved by one phone call.

In addition to its multitude of immediate benefits, the fabric architecture paves a way for many future features and

opportunities to create more intelligent networks. Because every network device integrates into the fabric, you can

use bidirectional feedback loops to create adaptable and contextual application policies based on flow behavior

and endpoint reputation. Various metadata can be transparently attached to transit packets within the fabric to

carry and expand this additional intelligence between service devices without complex out-of-band overlays. These

functionalities could be effectively used to create an entirely new approach to path optimization and traffic

engineering. The possibilities are nearly endless, and this is the true power of a network that is smart by design.


Printed in USA C11-733540-00 12/14

Integrating the Cisco ASA with Cisco Nexus 9000 Series ... · accommodate the emerging virtualized...

Documents

Transcript of Integrating the Cisco ASA with Cisco Nexus 9000 Series ... · accommodate the emerging virtualized...