Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
You may experience some slow load times, errors, and slight inconsistencies. We ask for your patience as we finalize the launch. Thank you.

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

ACE - Balance HTTP and sticky only SSL/TLS

Hi there,

I have a situation that I am trying to solve. We have lot of services trough ACE, but now I have to modify one of them, PROXY servers. 
I have six (6) servers working with Sticky, but with a MASK 255.255.255.0, which produce an unbalanced situation some times, and that affect some servers on depending of how many users connected to that server. We have between 40K and 50K conns in that serverfarm, but in Sticky terms we have arround 700 /24 subnets.

I want to modify the configuration, specificaly the MASK to 255.255.255.255, which is going to increase a lot Sticky resources. But thinking in optimize Sticky resources, I want to know if there is a way to select only e-commerce, Home Banking or other kind of SSL/TSL traffic (always using port 80 trough proxy servers), so I could use Sticky only  for connections that need it, and leave other HTTP traffic without this feature.

I´m sorry, may be I'm doing a silly question, but don´t have the experience to make this configuration, and I will apreciate your help.

 

Here is the actual configuration:

probe tcp HTTP
  description Keepalive web servers
  interval 20
  passdetect interval 30
!
rserver host Server1
  ip address 10.1.1.1
  inservice
rserver host Server2
  ip address 10.1.1.2
  inservice
rserver host Server3
  ip address 10.1.1.3
  inservice
rserver host Server4
  ip address 10.1.1.4
  inservice
rserver host Server5
  ip address 10.1.1.5
  inservice
rserver host Server6
  ip address 10.1.1.6
  inservice
!
serverfarm host PRX
  failaction purge
  predictor leastconns
  probe HTTP
  rserver Server1
    inservice
  rserver Server2
     inservice
  rserver Server3
    inservice
  rserver Server4
    inservice
  rserver Server5
    inservice
  rserver Server6
    inservice
!
sticky ip-netmask 255.255.255.0 address source sticky-PRX
  timeout 60
  serverfarm PRX
!
class-map match-any VIP-PRX
  2 match virtual-address 10.10.10.101 tcp eq www
!
policy-map type loadbalance first-match POLICY-L7-PRX
  class class-default
    sticky-serverfarm sticky-PRX
!
policy-map multi-match PRX-Balance
  class VIP-PRX
    loadbalance vip inservice
    loadbalance policy POLICY-L7-PRX
    loadbalance vip icmp-reply
!
!
interface vlan 100
  ip address 10.10.10.11 255.255.255.0
  alias 10.10.10.10 255.255.255.0
  peer ip address 10.10.10.12 255.255.255.0
  no normalization
  access-group output SOLO-SLB
  service-policy input PRX-Balance
!

 

Thanks

Alexis

  • Other Data Center Subjects
Everyone's tags (1)
1 REPLY
New Member

You might want to check out

You might want to check out this new product called ITD.

Simple and faster solution:

ITD provides :

  1. ASIC based multi-terabit/s L3/L4 load-balancing at line-rate
  2. No service module or external L3/L4 load-balancer needed. Every N7k port can be used as load-balancer.
  3. Redirect line-rate traffic to any devices, for example web cache engines, Web Accelerator Engines (WAE), video-caches, etc.
  4. Capability to create clusters of devices, for example, Firewalls, Intrusion Prevention System (IPS), or Web Application Firewall (WAF), Hadoop cluster
  5. IP-stickiness
  6. Resilient (like resilient ECMP)
  7. VIP based L4 load-balancing
  8. NAT (available for EFT/PoC). Allows non-DSR deployments.
  9. Weighted load-balancing
  10. Load-balances to large number of devices/servers
  11. ACL along with redirection and load balancing simultaneously.
  12. Bi-directional flow-coherency. Traffic from A-->B and B-->A goes to same node.
  13. Order of magnitude OPEX savings : reduction in configuration, and ease of deployment
  14. Order of magnitude CAPEX savings : Wiring, Power, Rackspace and Cost savings
  15. The servers/appliances don’t have to be directly connected to N7k
  16. Monitoring the health of servers/appliances.
  17. N + M redundancy.
  18. Automatic failure handling of servers/appliances.
  19. VRF support, vPC support, VDC support
  20. Supported on both Nexus 7000 and Nexus 7700 series.
  21. Supports both IPv4 and IPv6
  22. N5k / N6k support : coming soon


Blog

At a glance

ITD config guide

Email Query or feedback:ask-itd@external.cisco.com

114
Views
0
Helpful
1
Replies