I think I'm going crazy getting my CSS11501 to work as intended!

[theletterz]

I've been posting here before regarding CSS and NAT'ing and how our web servers just log the VIP address of the CSS.

Now it turns out after a talk with our programmers, we can't use NAT at all because the backend servers will deliver services based on source IP addresses.

So here's my configuration: backend servers -> HP Procurve 2650 -> CSS11501

The CSS interface where the servers are connected to have the following configuration:

interface e5

bridge vlan 2

redundancy-phy

phy 100Mbits-FD

And circuit VLAN2 is as follows:

circuit VLAN2

description "LAN"

redundancy

ip address 192.168.1.4 255.255.255.0

I tried yesterday to separate two servers as a test in a vlan so that the CSS would act as a bridge between the servers and our firewall (which acts as a router).

So on the switch, I assign the ports for e5 on the CSS as untagged in the default vlan and tagged in vlan2. I then assigned the server ports for untagged in vlan2 and 'no' for the default vlan.

They can't see each other with this configuration, and setting the e5 interfaces as untagged in vlan2, tagged in vlan1 and the server ports untagged in vlan2, they still can't see each other!

And I really mean they can't see each other, if I clear the arp cache for the servers, the CSS doesn't pick up the MAC addresses again, so it's clear that there's something with the vlan tagging.

I've been working on this for a week and it's just getting more frustrated as I try different things which still doesn't work, what am I doing wrong?

Also there's a potential additional problem which I hope I can get an answer to: The servers has two nic's active. The primary nic has an IP address which is on the same subnet as the CSS WAN interface. If I get the servers and the CSS to talk across the vlans, will this be a problem with bridging, as the CSS finds a host on its LAN segment which has an IP address that belongs to its WAN segment?

[Gilles Dufour]

you're talking about tag and untag, but I don't see the 'trunk' command under your e5 interface.

What device is connected to port e5 ? I assume an HP switch.

What default vlan or native vlan is used on the HP swtich ? It should match the CSS default vlan.

Where is your firewall connected

Your e5 config should look like this

interface e5

trunk

vlan 2

default vlan

vlan 5

If you play with 2 vlans, you will need 2 circuit and 2 subnets.

If you want the css to bridge, you need to use 2 physical interfaces of the CSS.

The CSS can't bridge accross vlan.

So, you could have your HP switch connected to e5 and simply using vlan 2.

Your firewall should be connected to another interface on the CSS and you put it in vlan2 as well.

Then you get the CSS to bridge between the 2.

Let me know if you need anything else.

Gilles.

[theletterz]

gdufour, no, no combination with trunk on e5 worked so I switched it off. Yes, e5 is connected to a HP switch. The default vlan on the HP switch is 1, the firewall is connected to another HP switch (these two are directly uplinked, but are strictly layet 2 switches).

Thanks for the config. If I successfully manage to bridge the CSS, how will it react when it sees traffic coming in on its e5 interface, with an IP address that belongs to the subnet on its e1 interface?

I discussed this problem with our firewall consultants, and he said that the company he's currently working at, the IT administrator has set up a CSS, but with only one circuit. I've never seen any config examples or anything that just uses one (WAN, I presume) circuit, but this would perhaps solve my entire problem. Is such a configuration recommended?

In advance, thanks.

[Gilles Dufour]

we have to be very clear when talking about routing/switching on a L7 switch.

So, when you say traffic entering e5 with ip of e1, are you talking about source ip or destination ip ?

How is the traffic routed/switched to e5 first ? [is the default gateway used by the source the CSS or a device on e1 ?]

I would suggest you to send me a drawing of what setup you're trying to achieve.

I'll then tell you what config you need to use.

Regards,

Gilles.

[theletterz]

Okay, before I/we delve too deep into the problem, I just did a test with setting the default gateway on the servers to the public (e1) IP address of the CSS, changed the IP address in the services to the public IP addresses of the servers, and the servers have full access to all of our networks, internet, *and* the CSS works as intended.

This does however use only one interface on the CSS.

Will this configuration defeat some purpose or anything with the way content switching is supposed to work, or is this okay?

[Gilles Dufour]

This is called one-armed config.

Here is a link to a sample config and list of advantages/disadvantages.

http://www.cisco.com/en/US/products/hw/contnetw/ps789/products_configuration_example09186a0080093dff.shtml

Thanks,

Gilles.

[theletterz]

Thanks Gilles.

I read the list of advantages and disadvantages.

However the only disadvantage I can see, is that the CSS yelds lower performance since it has to shuffle inbound and outbound traffic on the same interface.

For instance: "When using this configuration, the load balanced servers will see all traffic as being originated from the CSS rathar than the real client source IP address. You do not get a true representation of where your traffic is coming from."

and in the following example:

"The CSS is now configured to load balance to the services, however, there is one problem. When the traffic goes through the CSS to get load balanced, the destination IP address is changed but the source IP address is not changed. When those packets head back to the client, they bypass the CSS through the switch because the servers' default gateways are set to the router IP address and the source IP address of the load balanced request is not on the local subnet.

You must not only NAT the destination address of the packet but the source addresses as well. In order to do this, configure the source groups."

This could be considered a bit misleading; I set the default gateway for the servers to the CSS, and not only do I *not* need to NAT, I *do* see the real client source IP address not the CSS VIP address, and furthermore, the servers have full access to all of our network resources as well as the internet if we chose to.

[Gilles Dufour]

There is one problem with pointing the servers to the CSS as default gateway.

If a server needs to open a connection, it will send its traffic through the CSS, the response however will not come back via the CSS.

The CSS requires to see both side of the traffic.

If it does not, like in this case, it will reset/close the connection.

So, in this scenario, you are fine as long as the server do not need to open connection or if no connection will be open with the servers directly.

Gilles.

[theletterz]

Thanks, I think I'm almost where we can close this thread as solved.

I'm not sure if I understood correctly what you meant by if a server needs to open a connection, but I accessed one of the servers which now are behind the one-armed CSS, and successfully managed to download and upload files via ftp to it.

Did I understand you correctly?