ACE4710 deployment models

[billmatthews]

I'm looking for some advice on an ACE 4710 deployment model.  We'll be doing an eval later in the year, but I'm just looking to understand the architecture.

We have a stack of 3750 switches with a single VLAN (10.1.1.0/24).  Connected to that stack is a pair of web servers (10.1.1.5 and 6) that we want to provide load balancing/failover for.  Some of the clients are located right there on that same VLAN.  Other clients may be coming from other spots in the infrastructure.

It sounds like I could put a pair of 4710s connected to that stack of switches, in a single arm deployment?  And then the virtual IP and the real servers would all be 10.1.1.0/24.  Maybe use an etherchanel to connect each 4710 to two 3750s?

Or would it make more sense to use a routed deployment?  I read http://www.cisco.com/en/US/prod/collateral/contnetw/ps5719/ps7027/ps8361/guide_c07-572616_ps7027_Products_White_Paper.html and it focuses mostly on a routed deployment.  Any other docs that compare/contrast the different styles?

Thanks, Bill

[Daniel Arrondo Ostiz · Accepted solution]

Hi Bill,

In the topology you are mentioning, a one-arm setup would be the easiest to implement. However, as you probably read, for this topology, you need to apply NAT to the source IP of the connection. This can bring trouble if your application needs to know the real IP of the client for some reason, so make sure to take this into account when making the decision.

If seeing the real IP of the client is critical, then the second easiest to implement topology is briged mode. For this one, you would not need to touch any of the IP addresses or routes, and it would be enough to move the two servers to a new vlan behind the ACE.

As for how to physically connect the ACE, an etherchannel to the 3750 stack would be the best approach because on top of the extra bandwidth (which may or may not be required), you would also get some link redundancy.

I believe all three topologies are properly explained in the cisco.com documentation, but if you have specific questions about any of them, please, do not hesitate to contact me again.

Best regards

Daniel

[billmatthews]

VERY helpful reply Daniel.  We believe our app doesn't require seeing the real IP of the client, but we'll test in the lab.

Thanks

Bill

[francisfox]

We are about to deploy a pair of redundant 4710's in front of a blade server. The clients and 4710's are connected to stacked 3120g's in the blade server, the clients come in from another blade server via it's 3120g's.  I am considering the same kind of issues. Looking at the config guides on http://docwiki.cisco.com/wiki/Cisco_Application_Control_Engine_(ACE) there appears to be very little difference between routed and one armed mode, however one armed may suit connecting a redundant pair together.  What are the pro's and cons of each? Also, can you expand on "This can bring trouble if your application needs to know the real IP of the client for some reason". Regards. Francis.

[Daniel Arrondo Ostiz]

Hi Francis,

It's hard to talk about pros and cons because, in the end, you can achieve the same results with any of the topologies.

The main advantage of one-arm over other topologies is the easiness of implementation on a alrady working environment. To implement it, you don't need to make any changes to your vlans or the IP addressing scheme, just plug the ACE in the server vlan. In exchange, the one-arm setup requires some extra configuration to ensure that the reply from the servers is going back through the ACE.

The most common way of achieving this is source-nat. With this configuration, the servers will see all the requests coming from one single IP address (or a few of them if the nat pool includes more than one). There are some applications that use the client ip address for authorization/accounting purposes, so, for those, not seeing the real address of the client is unacceptable.

As I said, source-nat is the most common way of ensuring that return traffic goes through the ACE, but it's not the only one. As an alternative, it's also normally possible to configure policy-based-routing on the switch so that any traffic from the server IP addresses towards the clients is forwarded to the ACE.

Regards

Daniel

[francisfox]

Hi Daniel

I wonder if you can help with an inital configuration problem I am having with the ACE.  I have connected the ACE to my switch using an etherchannel trunk link.  The ACE is in the same VLAN as the switch.  The VLAN on the ACE is in a user VC and has an ACl with permit ip any on it.  The problem is that I can't ping the SVI on the switch from the ACE or the VLAN address from the switch.   Should I expect to?

[Daniel Arrondo Ostiz]

Hi Francis,

Apart from allowing all traffic with an ACL, to ping the ACE you also need to have ICMP allowed in a management policy.

For more details, check http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA4_2_0/configuration/administration/guide/access.html#wp1089698

Daniel

[francisfox]

Hi Daniel

Thanks for that, I can ping my vlan on the ACE now but I had to convert the interface between the ACE and the switch from a trunk to access port.  I could then ping in each direction.  Having achieved that I thought I would make it a trunk again.  This done I can ping the switch from the ACE OK, but the ping from the switch to the ACE fails.  This is puzzling me. Do you have any ideas? I would like to use a trunk interface so I can run the FT VLAN over it as well

Regards

Francis

[Daniel Arrondo Ostiz]

Hi Francis,

This looks like a problem with your configuration. Open a TAC case and we will check it further.

Daniel

[francisfox]

You're right Daniel, it was my configuration, the range of source addresses for my ICMP allow policy on the ACE was not broad enough. All okay now.  Many thanks for your help.