cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
873
Views
0
Helpful
13
Replies

access server cluster from the same servers via CSS VIP address

aliver
Level 1
Level 1

Hi,all!

We are need to access server cluster from itself servers via CSS content VIP address, but it is not work because if balance rule decide to send request to server from which it arrived CSS return session packet not from VIP address as source but from vlan circuit address..

if CSS send request to another server - all is OK.

for example we have config

circuit VLAN252

ip address 192.168.252.241 255.255.255.240

ip virtual-router 4 priority 110 preempt

ip redundant-interface 4 192.168.252.243

circuit VLAN100

ip address 192.168.33.253 255.255.255.224

ip virtual-router 3 priority 110 preempt

ip redundant-interface 3 192.168.33.254

--------------

service web1

ip address 192.168.33.250

redundant-index 41

port 80

keepalive type http

active

service web2

ip address 192.168.33.249

redundant-index 42

port 80

keepalive type http

active

-----------------

content webs

vip address 192.168.32.1

protocol tcp

port 80

add service web1

add service web2

advanced-balance sticky-srcip

redundant-index 100

client requests from VLAN252 area is OK always.

requests from servers web1 and web2 to address 192.168.32.1 is OK only if content rule send request to another server then it was arrive.

from web1 -> web2 and web2 -> web1

if request from web1 CCS send to web1 it does not work.

Sniffer show that go away from web1 packet 192.168.33.250 -> 192.168.32.1 and arrive 192.168.33.253 -> 192.168.33.250

although must be 192.168.32.1 -> 192.168.33.250

Why does it occur? and how to resolve this trouble?

Thanks!

13 Replies 13

jfoerster
Level 4
Level 4

Hi,

the traffic looks like this (SRC-IP/DST-IP)

WEB1-VIP (192.168.33.250/192.168.32.1)

CSS decides to use web1 so the packet will look like this

CSS-WEB1(192.168.33.250/192.168.33.250)

So why should WEB1 send the traffic back to the CSS as the source is his own IP-Address?

To solve this problem you need to source-nat the traffic.

If you configure a source-group natting that traffic so that the SRC-IP is an IP-Address configured on the CSS this traffic will work as the source web1 is seeing is on the CSS so he sends the traffic back and the flow is complete.

Kind Regards,

Joerg

Thank You, Joerg for quick reply!

You are right!

But how correctly configure source-natting for my purpose?

I'm trying to do following...

group webs-back

vip address 192.168.32.11

active

acl 5

clause 10 permit tcp 192.168.33.248 255.255.255.252 destination 192.168.32.1 eq 80 sourcegroup webs-back

clause 100 permit any any destination any

apply circuit-(VLAN100)

but nothing happens...and no hits in acl 5 clause 10

should I add service or destination service to my source-group?

HI,

first of all you have to add web1 and web2 in the

group Webs-back

vip address 192.168.32.11

add service web1

add service web2

active

Next make sure you have no other circuit defined. If you have any other circuit apply and ACL permitting IP any any to those circuits. Afterwards issue and acl enable because otherwsie the ACLs won't have any effect. Once again the warning, if you have any circuit without an ACL and you issue the acl enable an ACL deny ip any any will be applied to this circuit.

Kind Regards,

Joerg

I add services and ACL always been enabled.

But no effect! no hit counts on clause 10

now config is...

acl enable

------------

group Webs-back

vip address 192.168.32.11

add service web1

add service web2

active

--------

acl 5

clause 10 permit tcp 192.168.33.248 255.255.255.252 destination 192.168.32.1 eq 80 sourcegroup Webs-back

clause 100 permit any any destination any

apply circuit-(VLAN100)

Hi,

could you change clause 10 to permit IP?

Btw could you apply this acl to the other circuit to?

Thx.

Kind Regards,

Joerg

I check efficiency of my schema and its work!!

and sniffer show that go away and arrive packets from 192.168.32.11

but still no hits in clause 10

Hi,

have you checked that not all requests are NATed?

Have you applied the ACl to the other circuit as asked before?

Kind Regards,

Joerg

Hi!

1) Yes, all requests are NATed (so ACL is not work)

2) No, applied to VLAN100 only! because on other circuits applied other ACLs and I cannot change their (Its a working schema)

How to force CSS to NAT only specified traffic? What is the right ACL for it?

your destination is incorrect.

Replace the ip address with the content rule name.

like this

clause 10 permit any x.x.x.x destination content sourcegroup

Regards,

Gilles.

No changes! Everything is just as was later.

No hits in acl and NATting for all requests.

may be remove services from group?

is group with only VIP address workable?

yes, if you want the acl to do the nating, you need to remove the services from the group.

Regards,

Gilles.

Hi Gilles,

well once I tested the config mentioned above in my lab and it worked well even having the services configured in the source-group(if my brain does not fool me). Shouldn't this work as the ACL is permitting traffic to NAT if the source and destination is matching and bypassing any other traffic?

Regards,

Joerg

Joerg,

in this acl, there is no bypass.

Only permit.

So, if you permit the traffic with no sourcegroup, the traffic should hit the vip and then the group.

If you have a service configured under the group, the CSS will nat.

Here however, the group only contains 'add service ...' so it should not apply to ANY source ip but only the ip of the servers.

I'm curious if the CSS was really configured with 'add service' and not 'add destination service' which would really NAT everything as indicated.

Anyway, once you decide to use acl, better remove all services from the group and let the acl do the job.

Regards,

Gilles.

Review Cisco Networking for a $25 gift card