01-04-2010 09:57 AM
Just a general question regarding the ACEs.
Currently, a pair of 6509s each with vss720s and an ACE.
Current layout (only one VIP right now, more to come very soon)
is very similar to diagram in cisco document ID 107400, configuring
ACE in routed mode with L7 policies. It seems to me that the design
in this document implies that ALL traffic to and from the real servers
(slb as well as non-slb) traverses the ACE.
My layout is as follows:
One vlan (call it vlan 100) is for VIPs and has L3/hsrp on the msfcs.
Other vlan (call it vlan 101) is for real servers and only exists at layer
2 on the 6509s. The alias IP on interface vlan 101 is the default gateway
for the real servers. I have a static route on the msfc for non-slb traffic and
other traffic directly to the real servers. Real servers are VMs.
The question I have is this - not all traffic that traverses the ACE is
load balance eligible, there will be pass-trhough traffic (non slb eligible)
that traverses the ACE. This does accomplish both forward and reverse
slb traffic traversing the ACE, but with non-slb traffic traversing the ACE,
is this scalable? I guess what I'm worried about paying a performance penalty
knowing that a lot of the traffic isn't slb eligible. I have no problem installing
a license for increased bandwidth.
Any responses/advice/comments are appreciated - chris
01-04-2010 11:04 AM
If the non-slb traffic is too important, it is sometimes better to have a one-armed design.
However, one-armed is more complex to implement (snat or policy-map is required).
The ACE resources can be seen with a 'show resource usage'.
Some of the important ones are BW, concurrent-connection, connection rate.
Those will be impacted by non-slb traffic.
Only the BW can be upgraded to 8G or 16G.
The concurrent-connections limit is 4M and the connection rate will vary depending on the load of the box.
Gilles.
01-05-2010 05:11 AM
Thanks for the reply, I appreciate it.
I did think about trying to fit the load balancing into our
current topology, and unfortunately due to some things
beyond my control, I don't believe that one-armed is an
option (need to see real source IPs, real servers opening
connections back to client, etc). So I believe that the design
as I've outlined is the best way to go, time will tell. But your
response does help and I can definitely monitor better to see
if we will hit any limitations.
If you don't mind, one other question on a completely different
subject. I do have a need to configure ssl termination on a new
VIP. In the ssl guide, under importing certificates, the doc states
that the ACE supports importation of PEM encoded certificates.
In the chapter "displaying certificate information", the docs states
that with the "sho crypto files" command, file formats may be shown
as PEM, DER, or PKCS12. Does this mean that ONLY PEM encoded
certs can be imported? If our server team has ordered a DER encoded
cert already, can that be imported and used for the ssl termination?
Thanks again, I appreciate it - chris
01-05-2010 08:51 AM
We support only PEM you do a terminal import.
If you use FTP or SFTP to import the key/cert we support PEM, DER and PKCS12.
Gilles.
01-05-2010 09:12 AM
Gilles,
Thank you, that certainly clears things up.
I appreciate it - chris
01-07-2010 06:42 AM
Cmarva,
One of my contexts is configured in one arm mode. The ACE has a command that you can enter in the policy-map of the configuration that will insert the original header.
Regards,
John...
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: