Re: CSS connection problem on VIP

yolo230985 · ‎02-26-2005

Here is my very simple configuration:

!Active version: ap0610405

configure

!************************* INTERFACE *************************

interface e1

bridge vlan 20

description "web1"

interface e2

bridge vlan 20

description "client"

interface e5

bridge vlan 20

description "web2"

interface e16

bridge vlan 16

phy 100Mbits-FD

description "Catalyst"

!************************** CIRCUIT **************************

circuit VLAN20

ip address 192.168.20.2 255.255.255.0

circuit VLAN16

ip address 10.0.0.4 255.0.0.0

!************************** SERVICE **************************

service web1

ip address 192.168.20.12

port 80

protocol tcp

active

service web2

ip address 192.168.20.13

port 80

protocol tcp

active

!*************************** OWNER ***************************

owner web_site

content load_balancing

add service web1

add service web2

vip address 10.0.0.20

port 80

protocol tcp

active

content load_balancing_192

add service web1

add service web2

vip address 192.168.20.20

active

CSS11152# sh summary

Global Bypass Counters:

No Rule Bypass Count: 0

Acl Bypass Count: 0

Owner Content Rules State Services Service Hits

web_site load_balancing Active web1 2

web2 3

load_balancing_1 Active web1 11

web2 12

CSS11152# sh service summary

Service Name State Conn Weight Avg State Idx

Load Transitions

web1 Alive 0 1 2 0 1

web2 Alive 0 1 2 0 2

The problem is that I cannot connect to 10.0.0.20:80 although I can ping the host from a machine connected to the same VLAN on the Catalyst. On the other hand I do not have any problem connecting to 192.168.20.20:80 from the "client" which is connected on the interface e2. What am I missing here?

seilsz · ‎02-27-2005

What are the web servers using as their gateway? Have you looked at a sniffer trace from the client and server sides?

~Zach

yolo230985 · ‎02-28-2005

The web servers have two networks interfaces one is currently used for for Internet access,for example the web1 has IP:10.0.0.12/255.0.0.0 and gateway:10.0.0.1 and the second interface has IP:192.168.20.12 without gateway. I tried with gateway 192.168.20.20 but no luck. Is the gateway necessary?

seilsz · ‎02-28-2005

Depends on where your clients are located. Regardless, the return traffic (server --> client) has to pass through the CSS.

Where are the client machines located? What IP addresses do your clients have?

~Zach

yolo230985 · ‎02-28-2005

Here is the output of tcpdump when I run "lynx http://10.0.0.20" from the client 10.0.0.22

10:50:23.542733 IP 10.0.0.22.46436 > 192.168.20.12.http: R 1526094082:1526094082(0) win 0

I see the IP 192.168.20.12, how is that possible?!

I attached a schematic diagram showing how I have connected the components.

seilsz · ‎02-28-2005

It looks like this tcpdump is taken from the server side of the connection, which is why you see traffic destined to the real IP address of the server.

~Zach

yolo230985 · ‎02-28-2005

I found where the problem is! I forgot to mention on my previous diagram about the primary network interfaces on the web servers which are connected to the Catalyst. These interfaces have IPs 10.0.0.12 and .13 IPs. So, when I send a request from the host 10.0.0.22 the CSS sends the request to the 192.168.20.12 (second interface) but the server tries to respond back from the 10.0.0.12 (first interface). Is that correct? Now, the question is how do I overcome this problem? I want to keep the primary network interface and I want the second interface with the 192.168.20.xx IPs to participate in load balancing through the CSS.

seilsz · ‎02-28-2005

Will your clients always be located on the 10.0.0.0/8 address space? Can you add a route on your web servers to force traffic destined for the 10/8 address space to go back out the 192.168.20.x interface?

~Zach

yolo230985 · ‎03-01-2005

The first network card (10.0.0.xx) accepts and answers traffic from the Internet. What I want to do is the second network card (192.168.20.xx), which is connected on the CSS, to accept and answer traffic form the Internet, too. Right now when traffic from the Internet arrives on 192.168.20.xx the answer is routed back through the 10.0.0.xx, and this is the cause of the problem. I want to route the traffic back from the network card that received the request.