Basic Load Balancing Using One Arm Mode with Source NAT on the Cisco Application Control Engine Configuration Example - Revision history

Dhuckaby at 14:53, 3 October 2010

2010-10-03T14:53:48Z

← Older revision		Revision as of 14:53, 3 October 2010
Line 8:		Line 8:
	Clients will send application requests through the MFSC, which routes them to a virtual IP address (VIP) within ACE. The VIP used in this example resides in an ACE context, which is configured with a single VLAN to handle client and server communication (Figure 1.). Client requests will arrive at the VIP and the Cisco ACE will pick the appropriate server to handle the request. ACE will rewrite the destination IP to that of the rserver and rewrite the source IP with one from a nat-pool. Once the client request is fully NAT’d it will be sent to the server over the same VLAN which it was originally received. The server will respond to the Cisco ACE, based on the source IP of the request. The Cisco ACE will receive the response, change the source IP to be the VIP, and send it to the MSFC. The MSFC will forward the response to the client.		Clients will send application requests through the MFSC, which routes them to a virtual IP address (VIP) within ACE. The VIP used in this example resides in an ACE context, which is configured with a single VLAN to handle client and server communication (Figure 1.). Client requests will arrive at the VIP and the Cisco ACE will pick the appropriate server to handle the request. ACE will rewrite the destination IP to that of the rserver and rewrite the source IP with one from a nat-pool. Once the client request is fully NAT’d it will be sent to the server over the same VLAN which it was originally received. The server will respond to the Cisco ACE, based on the source IP of the request. The Cisco ACE will receive the response, change the source IP to be the VIP, and send it to the MSFC. The MSFC will forward the response to the client.

-	[[Image:Basic Load Balancing Using ~~Routed~~ Mode on ACE.jpg]]	+	[[Image:Basic Load Balancing Using Bridged Mode on ACE.jpg]]

	==Configuration==		==Configuration==

Docwikibot: Bot: Adding {{Template:Required Metadata}}

2009-12-18T17:29:17Z

Bot: Adding {{Template:Required Metadata}}

← Older revision		Revision as of 17:29, 18 December 2009
Line 1:		Line 1:
		+	{{Template:Required Metadata}}
	==Goal==		==Goal==

Andyirving: Changed the 192.168.5.0 network range to match the diagram on 192.168.1.0

2009-07-22T13:28:28Z

Changed the 192.168.5.0 network range to match the diagram on 192.168.1.0

← Older revision		Revision as of 13:28, 22 July 2009
Line 32:		Line 32:

	<pre>ACE-1/onearm(config)# rserver lnx1		<pre>ACE-1/onearm(config)# rserver lnx1
-	ACE-1/onearm(config-rserver-host)# ip add 192.168.5.11	+	ACE-1/onearm(config-rserver-host)# ip add 192.168.1.11
	ACE-1/onearm(config-rserver-host)# inservice		ACE-1/onearm(config-rserver-host)# inservice
	ACE-1/onearm(config-rserver-host)# rserver lnx2		ACE-1/onearm(config-rserver-host)# rserver lnx2
-	ACE-1/onearm(config-rserver-host)# ip add 192.168.5.12	+	ACE-1/onearm(config-rserver-host)# ip add 192.168.1.12
	ACE-1/onearm(config-rserver-host)# inservice		ACE-1/onearm(config-rserver-host)# inservice
	ACE-1/onearm(config-rserver-host)# rserver lnx3		ACE-1/onearm(config-rserver-host)# rserver lnx3
-	ACE-1/onearm(config-rserver-host)# ip add 192.168.5.13	+	ACE-1/onearm(config-rserver-host)# ip add 192.168.1.13
	ACE-1/onearm(config-rserver-host)# inservice		ACE-1/onearm(config-rserver-host)# inservice
	ACE-1/onearm(config-rserver-host)# rserver lnx4		ACE-1/onearm(config-rserver-host)# rserver lnx4
-	ACE-1/onearm(config-rserver-host)# ip add 192.168.5.14	+	ACE-1/onearm(config-rserver-host)# ip add 192.168.1.14
	ACE-1/onearm(config-rserver-host)# inservice		ACE-1/onearm(config-rserver-host)# inservice
	ACE-1/onearm(config-rserver-host)# rserver lnx5		ACE-1/onearm(config-rserver-host)# rserver lnx5
-	ACE-1/onearm(config-rserver-host)# ip add 192.168.5.15	+	ACE-1/onearm(config-rserver-host)# ip add 192.168.1.15
	ACE-1/onearm(config-rserver-host)# inservice</pre>		ACE-1/onearm(config-rserver-host)# inservice</pre>

Line 122:		Line 122:

	rserver host lnx1		rserver host lnx1
-	ip address 192.168.5.11	+	ip address 192.168.1.11
	inservice		inservice
	rserver host lnx2		rserver host lnx2
-	ip address 192.168.5.12	+	ip address 192.168.1.12
	inservice		inservice
	rserver host lnx3		rserver host lnx3
-	ip address 192.168.5.13	+	ip address 192.168.1.13
	inservice		inservice
	rserver host lnx4		rserver host lnx4
-	ip address 192.168.5.14	+	ip address 192.168.1.14
	inservice		inservice
	rserver host lnx5		rserver host lnx5
-	ip address 192.168.5.15	+	ip address 192.168.1.15
	inservice		inservice

Chriswelsh: /* show running-config */ removed "http" from policy-map type loadbalance http first-match slb

2009-02-25T05:38:45Z

show running-config: removed "http" from policy-map type loadbalance http first-match slb

← Older revision		Revision as of 05:38, 25 February 2009
Line 156:		Line 156:
	permit		permit

-	policy-map type loadbalance ~~http~~ first-match slb	+	policy-map type loadbalance first-match slb
	class class-default		class class-default
	serverfarm web		serverfarm web

Chriswelsh: /* Configuration */ removed "http" from policy-map type loadbalance http first-match slb

2009-02-25T05:33:43Z

Configuration: removed "http" from policy-map type loadbalance http first-match slb

← Older revision		Revision as of 05:33, 25 February 2009
Line 68:		Line 68:
	Next define the action to take when a new client request arrives. In this case, all traffic will be sent to the “web” serverfarm. This type of load balancing is considered L4 since only class-default is used.		Next define the action to take when a new client request arrives. In this case, all traffic will be sent to the “web” serverfarm. This type of load balancing is considered L4 since only class-default is used.

-	<pre>ACE-1/onearm(config)# policy-map type loadbalance ~~http~~ first-match slb	+	<pre>ACE-1/onearm(config)# policy-map type loadbalance first-match slb
	ACE-1/onearm(config-pmap-lb)# class class-default		ACE-1/onearm(config-pmap-lb)# class class-default
	ACE-1/onearm(config-pmap-lb-c)# serverfarm web</pre>		ACE-1/onearm(config-pmap-lb-c)# serverfarm web</pre>

Pzimmerm: 1 revision

2008-12-04T18:37:24Z

1 revision

← Older revision

Revision as of 18:37, 4 December 2008

Pzimmerm: /* Related show Commands */

2008-12-02T19:37:46Z

Related show Commands

New page

==Goal==

Configure basic load balancing (Layer 3) where client traffic enters on one VLAN and Network Address Translation (NAT) is used when sending the client request out the same VLAN to the servers. The servers will respond to the Cisco® Application Control Engine (ACE), where the server’s IP is replaced with the VIP and the response message is sent to the client via the multilayer switch feature card (MSFC).

==Design==

Clients will send application requests through the MFSC, which routes them to a virtual IP address (VIP) within ACE. The VIP used in this example resides in an ACE context, which is configured with a single VLAN to handle client and server communication (Figure 1.). Client requests will arrive at the VIP and the Cisco ACE will pick the appropriate server to handle the request. ACE will rewrite the destination IP to that of the rserver and rewrite the source IP with one from a nat-pool. Once the client request is fully NAT’d it will be sent to the server over the same VLAN which it was originally received. The server will respond to the Cisco ACE, based on the source IP of the request. The Cisco ACE will receive the response, change the source IP to be the VIP, and send it to the MSFC. The MSFC will forward the response to the client.

[[Image:Basic Load Balancing Using Routed Mode on ACE.jpg]]

==Configuration==

The Cisco ACE needs to be configured via access control lists (ACLs) to allow traffic into the Cisco ACE data plane. After the ACL checks are made, a service policy, which is applied to the interface, is used to classify traffic destined for the VIP. The VIP is associated with a load-balancing action within the multimatch policy. The load-balancing action tells the Cisco ACE how to handle traffic that has been directed to a VIP. In this example, all traffic is sent to a server farm, where it is distributed in round-robin fashion to one of five real servers. The Cisco ACE configuration occurs in layers, such that it builds from the real IPs to applying the VIP on an interface. Due to this layered structure, it is optimal to create the configuration by working backward from the way the flow is processed. Thus, to enable server load balancing you need to do the following:

* Enable ACLs to allow data traffic through the Cisco ACE device, as it is denied by default.
* Configure the IPs of the servers (define rservers).
* Group the real servers (create a server farm).
* Define the virtual IP address (VIP).
* Define how traffic is to be handled as it is received (create a policy map for load balancing).
* Associate a VIP to a handling action (create a multimatch policy map [a service policy])
* Create client- and server-facing interfaces.
* Apply the VIP and ACL permitting client connections to the interface (apply access group and service policy to interface).

To begin the configuration, create an access list for permitting client connections.

<pre>ACE-1/onearm(config)# access-list everyone extended permit ip any any
ACE-1/onearm(config)# access-list everyone extended permit icmp any any</pre>

{{note|Although this example shows a “permit any any,” it is recommended that ACLs be used to permit only the traffic you want allow through the Cisco ACE. In the past, server load-balancing (SLB) devices have used the VIP and port alone to protect servers. Within the Cisco ACE, ACLs are processed first, and thus dropping traffic using an ACL requires fewer resources than dropping it once it passes the ACLs and reaches the VIP. }}

The Cisco ACE needs to know the IP address of the servers available to handle client connections. The rserver command is used to define the IP address of the service. In addition, each rserver must be place in service for it to be used. The benefit of this design is that no matter how many applications or services an rserver hosts, the entire real server can be completely removed from the load-balancing rotation by issuing a single “no inservice” or “no inservice-standby” command at the rserver level. This is very beneficial for users needing to upgrade or patch an rserver, because they no longer have to go to each application and remove each instance of the rserver.

<pre>ACE-1/onearm(config)# rserver lnx1
ACE-1/onearm(config-rserver-host)# ip add 192.168.5.11
ACE-1/onearm(config-rserver-host)# inservice
ACE-1/onearm(config-rserver-host)# rserver lnx2
ACE-1/onearm(config-rserver-host)# ip add 192.168.5.12
ACE-1/onearm(config-rserver-host)# inservice
ACE-1/onearm(config-rserver-host)# rserver lnx3
ACE-1/onearm(config-rserver-host)# ip add 192.168.5.13
ACE-1/onearm(config-rserver-host)# inservice
ACE-1/onearm(config-rserver-host)# rserver lnx4
ACE-1/onearm(config-rserver-host)# ip add 192.168.5.14
ACE-1/onearm(config-rserver-host)# inservice
ACE-1/onearm(config-rserver-host)# rserver lnx5
ACE-1/onearm(config-rserver-host)# ip add 192.168.5.15
ACE-1/onearm(config-rserver-host)# inservice</pre>

Now group the rservers to be used to handle client connections into a server farm. Again, the rserver must be placed in service. This allows a single instance of an rserver to be manually removed from rotation.

<pre>ACE-1/onearm(config-cmap)# serverfarm web
ACE-1/onearm(config-sfarm-host)# rserver lnx1
ACE-1/onearm(config-sfarm-host-rs)# inservice
ACE-1/onearm(config-sfarm-host-rs)# rserver lnx2
ACE-1/onearm(config-sfarm-host-rs)# inservice
ACE-1/onearm(config-sfarm-host-rs)# rserver lnx3
ACE-1/onearm(config-sfarm-host-rs)# inservice
ACE-1/onearm(config-sfarm-host-rs)# rserver lnx4
ACE-1/onearm(config-sfarm-host-rs)# inservice
ACE-1/onearm(config-sfarm-host-rs)# rserver lnx5
ACE-1/onearm(config-sfarm-host-rs)# inservice</pre>

Use a class map to define the VIP to which clients will send their requests. In this example, the VIP is considered L3 (Layer 3) because there is a match on any port. If the VIP were to match only HTTP traffic, the match would be bound to port 80 and considered an L4 (Layer 4) VIP. (For example, “match virtual-address 172.16.1.100 tcp eq 80”).

<pre>ACE-1/onearm(config)# class-map slb-vip
ACE-1/onearm(config-cmap)# match virtual-address 172.16.5.100 any</pre>

Next define the action to take when a new client request arrives. In this case, all traffic will be sent to the “web” serverfarm. This type of load balancing is considered L4 since only class-default is used.

<pre>ACE-1/onearm(config)# policy-map type loadbalance http first-match slb
ACE-1/onearm(config-pmap-lb)# class class-default
ACE-1/onearm(config-pmap-lb-c)# serverfarm web</pre>

Since the VIPs and load-balancing actions are defined independently, they must be associated so that the Cisco ACE knows how to handle traffic destined for a VIP. The association is made using a multimatch policy map. Keep in mind that multimatch policy maps are applied to interfaces as service policies. “nat dynamic” is configured to make the Cisco ACE source NAT all client requests. The nat-pool will be defined in a later step.

<pre>ACE-1/onearm(config)# policy-map multi-match client-vips
ACE-1/onearm(config-pmap)# class slb-vip
ACE-1/onearm(config-pmap-c)# loadbalance policy slb
ACE-1/onearm(config-pmap-c)# loadbalance vip inservice
ACE-1/onearm(config-pmap-c)# nat dynamic 5 vlan 50</pre>

At this point the interface VLAN can be created to interconnect the Cisco ACE to the network.

<pre>ACE-1/onearm(config)# interface vlan 50
ACE-1/onearm(config-if)# description “Client-Sever VLAN”
ACE-1/onearm(config-if)# ip address 172.16.5.5 255.255.255.0
ACE-1/onearm(config-if)# no shutdown</pre>

The last step is to apply the ACL and service policy (policy-map multi-match) to the client side interface. Both the access group and service policy are applied on the input side of the interface. The nat-pool is also created, for use in the multi-match policy.

<pre>ACE-1/onearm(config)# interface vlan 50
ACE-1/onearm(config-if)# access-group input everyone
ACE-1/onearm(config-if)# service-policy input client-vips
ACE-1/onearm(config-if)# nat-pool 5 172.16.5.200 172.16.5.209 netmask 255.255.255.0 pat</pre>

{{note|There is no need to add an access group to the server side, as the Cisco ACE automatically creates pinholes to allow server response traffic to pass back to the client.}}

==Related show Commands ==

This section provides information you can use to confirm your configuration is working properly.

Certain show commands are supported by the [https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl Output Interpreter Tool (registered customers only)], which allows you to view an analysis of show command output.

<pre>ACE-1/onearm #show arp
ACE-1/onearm #show acl
ACE-1/onearm #show service-policy client-vips
ACE-1/onearm #show serverfarm
ACE-1/onearm #show rserver
ACE-1/onearm #show stats</pre>

==Comments==

Once you’ve completed the configuration, verify that the Cisco ACE has an Address Resolution Protocol (ARP) response for each rserver and the default route to the client. Check the ACL hits to ensure that client connections are being accepted. Check the service policy output to see the client connection hits, and verify that the server is responding with response packets. The “show” command for serverfarm and rserver can be used to display the exact rserver handling the connection and the amount of work the entire server farm has handled. The “show stats” command provides a higher level of monitoring of ACE load balancing, inspection, probes, and other important metrics.

==show running-config ==

<pre>ACE-1/onearm# sho run
Generating configuration....

access-list everyone line 8 extended permit ip any any
access-list everyone line 16 extended permit icmp any any

rserver host lnx1
ip address 192.168.5.11
inservice
rserver host lnx2
ip address 192.168.5.12
inservice
rserver host lnx3
ip address 192.168.5.13
inservice
rserver host lnx4
ip address 192.168.5.14
inservice
rserver host lnx5
ip address 192.168.5.15
inservice

serverfarm host web
rserver lnx1
inservice
rserver lnx2
inservice
rserver lnx3
inservice
rserver lnx4
inservice
rserver lnx5
inservice

class-map match-all slb-vip
2 match virtual-address 172.16.5.100 any

policy-map type management first-match remote-access
class class-default
permit

policy-map type loadbalance http first-match slb
class class-default
serverfarm web

policy-map multi-match client-vips
class slb-vip
loadbalance vip inservice
loadbalance policy slb
nat dynamic 5 vlan 50

interface vlan 50
description "Client-Server VLAN"
ip address 172.16.5.5 255.255.255.0
access-group input everyone
service-policy input client-vips
service-policy input remote-access
nat-pool 5 172.16.5.200 172.16.5.209 netmask 255.255.255.0 pat
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.5.1</pre>

==Related Information==
[http://www.cisco.com/web/psa/products/index.html Technical Support & Documentation - Cisco Systems]



[[Category:Data Center Application Services Configuration Examples]]