CSS11501 - VIP IP Filter

[dily]

Hi, I have CSS1501 running in one-armed mode, for VIP setup below for port 443 (SSL Certificates are running on back-end servers):

  content APP_https
    vip address x.x.x.x
    port 443
    protocol tcp
    advanced-balance sticky-srcip
    sticky-inact-timeout 65
    add service ServerA
    add service ServerB
    add service ServerC
    active

NEW REQUIREMENT - can the CSS be setup filter by source IP's, meaning:

I will add 2 new Servers C & D to this VIP

I have specific users with their IP's

I need to modify VIP config - filter by source IP's - to allow these users to access the SAME VIP address ... but ONLY new servers C & D will handle/load-balnce this traffic load for these users.

Can this be done?  If yes, how?

I assume I need to suspend/activate the VIP to make this change.

Thanks in advance for the help.

Regards,

Diane Ly       

TI Network Infrastructure

dly@ti.com

[dily]

Sorry I have a typo - new servers should be D & E

[ajay chauhan]

I dont think if its possible on any cisco LB so far I have seen PSLB on Foundry the way you want to get real servers based

on source IP.

Ajay

[pablo.nxh]

Hello Diane,

This is possible with the CSS but  only with the use of ACLs in order to control traffic handling.  Something important to mention is that since you're adding two new servers load balance will not be possible with ACLs for these new bunch of users; you'll need to figure whether to split user traffic, i.e say you have new users on 192.168.10.X/24 and 192.168.20.X/24 then you can send traffic from subnet 10 to server D and traffic from subnet 20 to server  E.

The other option would be kind of a failover scenario where all the traffic goes to Server D but if the keepalive fails then all the traffic will be redirected to server E.

Here is a config sample for both scenarios.

Option #1

nql Subnet-A

  ip address 192.168.10.0 255.255.255.0

nql Subnet-B

  ip address 192.168.20.0 255.255.255.0

acl 1

clause 10 permit any nql Subnet-A destination content SSL_Owner/APP_https prefer Service-D

clause 11 permit any nql Subnet-B destination content SSL_Owner/APP_https prefer Service-E

clause 30 permit any any destination any

apply circuit-(VLAN10)

CSS(config)# acl enable

Option # 2

nql New-Users

  ip address 192.168.10.0 255.255.255.0

  ip address 192.168.20.0 255.255.255.0

acl 1

clause 10 permit any nql New-Users destination content SSL_Owner/APP_https prefer Service-D

clause 11 permit any nql New-Users destination content SSL_Owner/APP_https prefer Service-E

clause 30 permit any any destination any

apply circuit-(VLAN10)

CSS(config)# acl enable

P.D All Cisco load balancers are able to acomplish this; actually on CSM and ACE is way easier than CSS.

HTH

__ __

Pablo

[dily]

Thanks Pablo for your help with the config.

These are the existing users - they're scatter in multi-subnets. 

For Option #1:

clause 10 permit any nql Subnet-A destination content SSL_Owner/APP_https prefer Service-D

clause 11 permit any nql Subnet-B destination content SSL_Owner/APP_https prefer Service-E

If "prefer Service-D" died, "Subnet-A" users will NOT failover to "Service-E", correct?

If that's the case, I might have to go with Option #2 - the failover scenario.

I'm concerned about CSS11501 - CPU & flow processing performance degradation - once the ACL is enabled.

Any ideas what's the performance hit going to be?

Thx, Diane

[pablo.nxh]

Hi Diane,

In scenario 1 If service D dies then your users will be sent to either A, B or C so yup I'd think option 2 fits better with your LB needs in this case.

About your second question I have to say that performance would go hand-to-hand with the current load going through the CSS and the number of config lines you have in place; if you just need ACL's to accomplish this then I'd say the performance degradation would be none or barely noticeable... nothing to be worried about.

HTH

__ __

Pablo

[dily]

Great, thanks for your help again Pablo!

Diane