© 2015 Cisco | F5. All rights reserved. Page 1

F5 BIG-IP: Workload Migration from Traditional Networks to Cisco

Application Centric Infrastructure Building Architectures to Solve Business Problems

Design Guide

© 2015 Cisco | F5. All rights reserved. Page 2

Contents

Solution Overview ....................................................................................................................................... 3

Migration Using F5 BIG-IP Local Traffic Manager ................................................................................... 4

Prerequisites and Network Design ............................................................................................................ 5

Configuring the Networks for Migration ................................................................................................... 6 Setting Up an External Layer 2 Endpoint Group in Cisco ACI ................................................................. 7 Configuring a Pair of F5 BIG-IP Systems in Cisco ACI ............................................................................ 8 Choosing the Level of Integration ............................................................................................................. 8

Application Migration Using the Device Package for Full Integration of Cisco ACI ............................ 8 Integrating the Device Package ................................................................................................................ 9 Steps for Full Application Migration ........................................................................................................ 13

Application Migration: BIG-IP with EPGs Only ...................................................................................... 17

Pointing Clients Directly to the Cisco ACI Virtual IP Address ............................................................. 17

Conclusion ................................................................................................................................................. 18

For More Information ................................................................................................................................ 18

© 2015 Cisco | F5. All rights reserved. Page 3

Solution Overview

Most businesses depend on their applications, and application availability has become mission critical. As various

parts of the network and data center evolve, organizations may need to replace the underlying infrastructure to

take advantage of technology shifts and advancements.

The traditional network typically is designed with multiple layers: as either a three-tier network or a two-tier

network with collapsed access and aggregation layers or collapsed core and aggregation layers. Network

services like firewalls, load balancers, and Domain Name Service (DNS) typically are placed either on the network

core or aggregation layer or in a service chassis on the aggregation layer. Figures 1 and 2 illustrate these two

designs. This document refers generically to both designs simply as a traditional network.

Figure 1: Two-Tier Traditional Network

Figure 2: Two-Tier Traditional Network with Service Chassis

© 2015 Cisco | F5. All rights reserved. Page 4

The latest evolution of the network is to a spine-and-leaf architecture to better support the increasing east-west

traffic flow in the data center. Cisco® Application Centric Infrastructure (ACI) was developed to help provide

centralized automation and policy-based application profiles. Multiple challenges exist when refreshing the

network infrastructure and moving from one network infrastructure to another. These challenges often include

technical, business, cost, time, resource, and organizational requirements. A few common requirements include:

Transparent migration of applications from traditional network designs to Cisco ACI fabric

Continued access to Layer 4 through 7 services during migration

High availability with very few and very small maintenance windows

Little need for application and server changes (ideally, no changes)

Instant rollback capability for risk mitigation

This document focuses on the use of F5 BIG-IP Local Traffic Manager (LTM) to migrate traffic at the application

level and configuration details from the viewpoint of F5 BIG-IP. Networking configuration, architecture, router

configuration, and Cisco ACI details are mentioned but are covered in depth in other documents.

Migration Using F5 BIG-IP Local Traffic Manager

The use of F5 BIG-IP LTM for migration involves treating the older traditional network and the new ACI fabric as

parts of one large network. These two different networks can be linked together using Layer 3 routing, or they can

be connected using a Layer 2 link. A Layer 2 link allows the connected devices to remain unchanged during the

migration and has the added benefit of requiring no routing changes, updates, or convergence time. To remain

focused on the migration of applications while the network infrastructure is switched (from traditional to ACI), this

document focuses on use of a Layer 2 link.

The migration procedure is as follows:

Link the traditional network to ACI with a Layer 2 external bridge domain and stretch the required VLANs

for migration to the ACI leaf switch.

Bring up a parallel set of F5 BIG-IP LTM instances in the ACI fabric. This step includes configuration of

the F5 self IP address, device package, and VIP address, and a pool of members.

Take the VIP of the BIG-IP instance in the ACI fabric and add it as a pool member to the BIG-IP instance

in the traditional network.

Physically or virtually migrate the servers for the application from the traditional network to the ACI fabric.

Add the migrated server to the ACI virtual IP address pool.

To better understand why this migration method is well suited for the task, consider how F5 BIG-IP operates. F5

BIG-IP LTM virtualizes the physical application server to an IP address backed by a pool of addresses. The pool

of addresses is then used to load-balance client requests to multiple real servers. You can take advantage of this

virtualization and embed the F5 BIG-IP virtual server address (virtual IP address) that is in the ACI fabric in the

preexisting application virtual server pool or server farm that is in the traditional tiered network. The result is that

some client requests are sent to the VIP in the ACI fabric. Figure 3 shows the relationship between the two virtual

servers and the linkage between the two networks during the migration.

© 2015 Cisco | F5. All rights reserved. Page 5

Figure 3: Virtual Server Relationship between Three- and Two-Tier Traditional Network and Cisco ACI Fabric

This guide outlines the process and steps necessary to move applications and services from a traditional tiered

network design to the new ACI fabric infrastructure. By using this technique for application migration, you can

maintain application availability, reduce unnecessary interactions between IT teams, gain instant rollback

capabilities, and perform the work without any downtime. This migration method is also valid for migration to F5

BIG-IP devices from other load-balancing products such as the aging Cisco Application Control Engine (ACE).

Prerequisites and Network Design

To use the solution, the system must meet a few requirements and be prestaged as described here:

The existing network must be functional and have a load balancer in place. The load balancer in the

existing traditional network can be a F5 BIG-IP, or it can be some other solution such as the end-of-sale

Cisco ACE.

The ACI fabric must be configured and operational.

A Layer 2 link must be established between the two networks and the relevant VLANs stretched across

them. This requirement includes establishment of communication between devices in the same subnets

and also between the traditional and ACI networks.

A pair of F5 BIG-IP systems must be configured and ready for creation of the corresponding virtual IP

address and pool.

At least one real application server must be in the ACI fabric ready to server requests. This server can be

an existing server from the traditional network that has been moved to the ACI network.

© 2015 Cisco | F5. All rights reserved. Page 6

Table 1 lists the product versions used during validation of the solution.

Table 1: Product Versions Used for Validation

Product Version

Cisco Application Policy Infrastructure Controller (APIC) 1.0(2j)

F5 BIG-IP 5050 11.4 or later

F5 Device Package 1.1.0

Configuring the Networks for Migration

Now look at a typical traffic flow for clients accessing a set of web servers load-balanced by F5 BIG-IP.

Figure 4 depicts the original traffic communication flow in the traditional network.

Figure 4: Logical Client-Request Traffic Flow in Traditional Network

1. A client resolves the application fully qualified name (FQN) with DNS for an IP address.

2. The client sends the request to the address provided, which is the VIP in the traditional network.

3. The VIP sends the request to the server pool, and the respective server responds to the request.

After the traditional network is connected to the ACI fabric, the logical traffic flow remains the same except that

the added pool member that is the ACI virtual IP address sends traffic to the pool in ACI. Figure 5 shows this

process.

© 2015 Cisco | F5. All rights reserved. Page 7

Figure 5: Logical Client-Request Traffic Flow with Cisco ACI Network

1. A client resolves the application FQN with DNS for an IP address.

2. The client sends the request to the address provided, which is the virtual IP address in the traditional

network.

3. The VIP sends the request to the server pool, and the respective server responds to the request.

4. Any requests going to the server entry LTM#2 VIP are sent across the ACI fabric to the ACI VIP.

5. The ACI VIP sends the request to the ACI VIP pool, where a respective server then responds to the

request.

With this technique, you can gain the following benefits:

You preserve the IP addressing scheme of the servers (for example, 192.168.18.x/24).

You preserve the IP addressing scheme for public-facing network used for the virtual IP addresses (for

example, 10.168.18.x/24).

You can relocate and reuse the real application servers without any changes. Simply unplug the

traditional network link and plug into the ACI network link.

You maintain application high availability because the application is never shut down.

Setting Up an External Layer 2 Endpoint Group in Cisco ACI

Refer to the following documents for information about how to set up an external Layer 2 endpoint group (EPG)

for ACI:

Cisco ACI design guide: http://www.cisco.com/c/en/us/solutions/collateral/data-center-

virtualization/application-centric-infrastructure/white-paper-c11-731960.html

Connecting ACI to outside Layer 2 and 3 networks:

http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-

infrastructure/white-paper-c07-732033.html

The goal here is to create the network topology shown earlier in Figure 5.

© 2015 Cisco | F5. All rights reserved. Page 8

Configuring a Pair of F5 BIG-IP Systems in Cisco ACI

Refer to the following documents for information about how to set up a pair of F5 BIG-IP systems:

Introduction to BIG-IP initial configuration: https://support.f5.com/kb/en-us/products/big-

ip_ltm/manuals/product/bigip-system-initial-configuration-11-6-0/1.html#conceptid

Creating a device group using the configuration utility: https://support.f5.com/kb/en-

us/solutions/public/13000/600/sol13649.html

Choosing the Level of Integration

After the F5 load balancers are up and running, you need to determine the level of integration between BIG-IP

and ACI:

You can use the F5 device package to allow ACI to manage the BIG-IP devices. This approach enables

service insertion and provides full ACI feature benefits.

You can maintain the standard management of the BIG-IP devices outside ACI using the current F5

application delivery controller (ADC) management tool set. This approach provides the capability to

enable ACI features in the future.

Application Migration Using the Device Package for Full Integration of Cisco ACI

The device package option allows services to be fully integrated into Cisco APIC, the Cisco ACI fabric controller

(Figure 6). The device package is a custom interface between APIC and BIG-IP. The device package defines the

variables and procedures needed to properly configure the system. This tight integration provides a single

management point for application services deployment and enforcement. Uniform deployment and enforcement

policies enable speedy application deployment and agility.

One point to keep in mind when using the device package is that the features you can configure in ACI for BIG-IP

depend on the features that have been exposed in the device package release.

Because the most common features are included in the device package already, this method of deployment is

common and is the focus of this document.

Supported features are listed in the release notes of the latest device package:

https://downloads.f5.com/esd/product.jsp?sw=Third-Party-Integration&pro=CiscoAPIC

© 2015 Cisco | F5. All rights reserved. Page 9

Figure 6: Device Package Option Showing Expanded Service Integration View

Integrating the Device Package

To integrate the device package, you use a service contract to send traffic to the BIG-IP LTM. This contract allows

the fabric to send the traffic to the BIG-IP device automatically in the normal flow of traffic between the EPGs

(Figure 7).

Figure 7: Detailed Service Graph

To use device package integration, follow these steps:

1. Install the F5 device package.

2. Create of the logical device cluster.

3. Add the BIG-IP systems to the device cluster as concrete devices.

4. Define the logical and physical relationships for the logical interfaces.

5. Create the service graph using BIG-IP as a function node.

6. Assign the service graph to the service contract.

© 2015 Cisco | F5. All rights reserved. Page 10

Detailed steps for configuring BIG-IP and integrating it into APIC are discussed in the following guides:

F5 and Cisco APIC quick-start guide: https://downloads.f5.com/esd/serveDownload.jsp?path=/third-party-

integration/ciscoapic/1.1.0/english/build-141/&sw=Third-Party-

Integration&pro=CiscoAPIC&ver=1.1.0&container=build-141&file=cisco-apic-quick-start.pdf

F5 device package and Cisco APIC users guide:

https://downloads.f5.com/esd/serveDownload.jsp?path=/third-party-

integration/ciscoapic/1.1.0/english/build-141/&sw=Third-Party-

Integration&pro=CiscoAPIC&ver=1.1.0&container=build-141&file=cisco-apic-users-guide.pdf

For detailed deployment steps for integrating Layer 4 through 7 service devices, such as F5 BIG-IP, into APIC,

see the following guide. Please refer to the “Configuration Parameters” section of the document for guidance on

generating XML configuration parameters for use with the F5 and ACI device package.

Cisco APIC Layer 4 through 7 services deployment guide:

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/L4-

L7_Services_Deployment/guide/b_L4L7_Deploy/b_L4L7_Deploy_chapter_01000.html

After these steps are complete, BIG-IP is connected and integrated with ACI. You now have the ACI Virtual IP

(VIP) for the application and the load-balancing pool. The application EPG diagram should look similar to

Figure 8.

Figure 8: Application EPG and Contract Mapping

The security contract should be similar to that shown in Figure 9.

© 2015 Cisco | F5. All rights reserved. Page 11

Figure 9: Security Contract Relationship between Server EPG and Layer 2 External Bridge Domain EPG

The Layer 4 through 7 service graph in ACI should be similar to that shown in Figure 10.

Figure 10: Service Graph Relationships

With the new VIP and pool working, test that traffic is being handled properly. You can do this by issuing

application requests directly to this new virtual IP address in the ACI fabric. The example here uses a web server,

so you can use a simple cURL command to the VIP in ACI. Figure 11 shows the server in the ACI pool sending

out a custom message.

© 2015 Cisco | F5. All rights reserved. Page 12

Figure 11: cURL Request and Output to the Cisco ACI Virtual IP Address

To help ensure that communication is occurring between the traditional network and the ACI network, you can

perform the following additional checks:

Ping the ACI VIP from the traditional BIG-IP self IP address.

Ping the traditional VIP and ACI VIP from a client in the public-facing network.

Issue a cURL command to each virtual IP address (both traditional and ACI addresses).

Note: The APIC configures the F5 BIG-IP self IP addresses into route domains, so you must specify the proper route

domain if you send a ping from the BIG-IP system controlled by ACI.

In Figure 12, the statistics show that BIG-IP is receiving connections and that they are being distributed to the

actual servers. If all the responses are good, then you should have high confidence that all is working properly.

Figure 12: New Application Server and Two Pool Members

© 2015 Cisco | F5. All rights reserved. Page 13

Steps for Full Application Migration

All the prerequisites are now completed and tested:

The traditional virtual IP address and pool are operational.

The traditional network and the ACI network are connected.

The ACI virtual IP address and pool are operational.

The F5 and ACI device package is installed.

The next step is to begin sending traffic to the ACI VIP from the traditional network BIG-IP VIP. Proceed with the

detailed migration steps provided to transparently add the ACI VIP to the traditional VIP pool and then relocate

the servers as necessary.

1. Log into the original pool and add the ACI VIP as a pool member for the traditional network. In Figure 13,

it is called ACI-VIP.

Figure 13: Original Application Server Pool with Cisco ACI VIP

After the new virtual IP address has been added to the pool, check the monitor status. It will display only green

indicators when the monitor threshold requirements have all been satisfied. After the pool is online, confirm that

the traffic is being load-balanced to the virtual IP address by looking at the statistics. Figure 13 shows packets

and connections going to the ACI virtual IP address member at the traditional network virtual IP address.

Also check the statistics on the BIG-IP in ACI to make sure that it is properly handling traffic. Figure 14 shows the

requests reaching the virtual IP address and then being load-balanced to the local pool members that are in the

ACI fabric.

© 2015 Cisco | F5. All rights reserved. Page 14

Figure 14: Application Server Pool Receiving a Request

You now have two pools handling client requests: one pool located in the traditional network, and a second pool

located in the ACI fabric. The next step is to move the physical server or virtual machine from the original

traditional VIP address pool to the new ACI VIP address pool.

Note: The health monitor request from the original traditional BIG-IP will also be sent to the ACI VIP pool. Thus, you will see

extra connections in the statistics for the ACI VIP.

2. Go to the original pool and select a node to migrate. At the node, select either Disabled or Forced Offline

so that no new requests are sent to the node (Figure 15). When no further traffic is being sent to the

server, it can be moved.

Figure 15: Node Is in the Forced Down State

© 2015 Cisco | F5. All rights reserved. Page 15

The offline diamond of Figure 16 shows that the pool member is disabled and that no new requests will be

allowed. The zero statistics values for connections provide validation that the server can be moved without

affecting the application.

Figure 16: Node Is Down and No Requests Are Being Serviced

3. If the server is a physical server, physically move the server link to the ACI fabric. If the server is a virtual

machine, migrate it to the new virtual switch that is managed by APIC and set the appropriate network.

4. When the server has been attached to the ACI fabric, the dynamic endpoint feature will automatically add

the server to the ACI-VIP server pool. After the server is in the pool, it will be subjected to the same

health monitoring requirements before it becomes an active pool member and responds to new requests

(Figure 17).

Figure 17: Server Added and Waiting to Pass Health Monitoring Threshold

Figure 17 shows the status indicator as red because monitoring requirements have not yet been met. After a few

seconds, the status indicator will become green as for the other pool members (Figure 18).

© 2015 Cisco | F5. All rights reserved. Page 16

Figure 18: Server Up and Actively Part of the Pool

5. Repeat the process and continue moving the servers over until the BIG-IP virtual IP address is the only

entry remaining in the original pool (Figure 19).

Figure 19: Original Pool with Only the Address of the New Pool

As shown in Figure 19, the only address left in the traditional pool is the IP address of the ACI VIP address pool.

This means that all the traffic is being sent to the ACI and BIG-IP network through the traditional VIP.

The final step is to have all new requests go directly to the new ACI VIP address without having to first transit the

traditional network VIP address. This step is covered in the section “Pointing Clients Directly to Cisco ACI VIP

Address” later in this document.

© 2015 Cisco | F5. All rights reserved. Page 17

Application Migration: BIG-IP with EPGs Only

Customers who are not ready for service insertion in ACI can take advantage of the ACI network design benefits

without full integration of F5 BIG-IP. The procedure for using BIG-IP devices without device package integration is

similar to the procedure discussed in the previous section, “Application Migration Using the Device Package for

Full Integration of Cisco ACI.”

Here is a condensed version of the process:

1. Create, configure, and test a new pair of F5 BIG-IP devices, a VIP address, and the corresponding pool.

You can do this easily using device groups. See the link for creating a device group using the

configuration utility in the “For More Information” section at the end of this document.

2. Add the new VIP address (ACI VIP address) to the traditional VIP address pool for servers. This addition

expands the original pool by one pool member, which is actually the virtual IP address of the F5 BIG-IP

device that is directly connected to the ACI fabric.

3. Verify that traffic is going to the ACI VIP address and that the responses are valid and correct.

4. After you verify that the application requests are working, select a pool member from the traditional data

center pool and put it into the disabled state. This step allows all existing stateful transactions and

connections to complete gracefully.

5. When all transactions have completed, remove the member from the existing traditional pool. If the pool

member is a physical server, relocate the server. If it is a virtual machine, move the virtual machine to the

ACI fabric.

6. After the server is in the new ACI fabric, add the server to the ACI pool and enable it as a pool member.

Verify that it passes the monitor checks.

7. Verify that connections are being sent to the new pool members and that the requests are valid.

8. Repeat the process and move each application server from the old pool to the new pool.

At this point, the only address in the traditional pool is the address of the VIP address pool in ACI. This should be

the same as shown earlier in Figure 19.

The final step is to have all new requests go directly to the new BIG-IP LTM that resides in ACI. This process is

discussed in the next section.

Pointing Clients Directly to the Cisco ACI Virtual IP Address

The original VIP address in the traditional network now has only a single entry and sends all traffic to the VIP

address in ACI. To complete the migration, you now need to remove the nested VIP addresses and have clients

go directly to the ACI virtual IP address. You can accomplish this in any of three ways:

If F5 GTM is being used in the network to direct traffic to the local load balancer, update the GTM entry to

send all new requests to the new pool address. When no further requests are going to the original entry,

you can remove it.

Update the DNS entry from the traditional virtual IP address to the new ACI VIP address. Then force an

update of the DNS server entries.

Manually and simultaneously change the virtual IP addresses between the two VIP addresses and then

shut down the pool in the traditional network. This method will be disruptive, you should use it only during

a maintenance window.

© 2015 Cisco | F5. All rights reserved. Page 18

Now the original application virtual server and respective pool are no longer being used. You can verify this by

looking at the connection statistics for BIG-IP. When appropriate, you can decommission and delete the unused

VIP address and pool.

Conclusion

Cisco Application Centric Infrastructure helps address the challenges of timely application provisioning and

resource scale elasticity. To take advantage of these improvements, you need to migrate from the traditional

network infrastructure to an ACI fabric. The transparent migration of workflows, applications, and services is

greatly simplified using F5 BIG-IP application delivery controllers (ADCs). F5 ADCs help make these transitions a

reality with smooth and transparent migration so that the business can stay up and running. When this solution is

coupled with additional features in the ADC such as Global Traffic Manager (GTM) and Application Security

Manager (ASM), application reliability and security is further enhanced.

For More Information

F5 and Cisco solutions: https://f5.com/solutions/technology-alliances/cisco

F5 BIG-IP and Cisco ACI solution overview: http://www.f5.com/pdf/solution-center/cisco-aci-overview.pdf

F5 BIG-IP and Cisco ACI integration demonstration: https://www.youtube.com/watch?v=5Nw2vtid7Zs

F5 BIG-IP and Cisco ACI device package: https://downloads.f5.com/esd/product.jsp?sw=Third-Party-

Integration&pro=CiscoAPIC

Creating a device group using the configuration utility: https://support.f5.com/kb/en-

us/solutions/public/13000/600/sol13649.html

Integrating Cisco ACI with existing networks: http://www.cisco.com/c/en/us/solutions/collateral/data-

center-virtualization/application-centric-infrastructure/white-paper-c11-731860.html

Service insertion with Cisco ACI: http://www.cisco.com/c/en/us/solutions/collateral/data-center-

virtualization/application-centric-infrastructure/white-paper-c11-732493.html

Connecting Cisco ACI to outside Layer 2 and 3 networks:

http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-

infrastructure/white-paper-c07-732033.html

Cisco ACI design guide: http://www.cisco.com/c/en/us/solutions/collateral/data-center-

virtualization/application-centric-infrastructure/white-paper-c11-731960.html

© 2015 Cisco | F5. All rights reserved. Page 19

© 2015 Cisco and/or its affiliates. All rights reserved. Cisco and the Cisco logo are trademarks or registered

trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to

this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective

owners. The use of the word partner does not imply a partnership relationship between Cisco and any other

company. (1110R)

F5 (NASDAQ: FFIV) provides solutions for an application world. F5 helps organizations seamlessly scale cloud,

data center, and software defined networking (SDN) deployments to successfully deliver applications to

anyone, anywhere, at any time. F5 solutions broaden the reach of IT through an open, extensible framework

and a rich partner ecosystem of leading technology and data center orchestration vendors. This approach lets

customers pursue the infrastructure model that best fits their needs over time. The world's largest businesses,

service providers, government entities, and consumer brands rely on F5 to stay ahead of cloud, security, and

mobility trends. For more information, go to f5.com.

C07-733816-00 02/15