topic Re: Basic config help in Application Networking

Basic config help

jaimemurphy — Fri, 30 Jan 2004 15:47:51 GMT

I am having problems getting my 11501 to work with my 2000 Terminal servers. I have been through the basic config and see that the hits under content services statistics but client come back with a "The client could not connect to the Terminal server" error message. Clients can connect if pointed at the actual servers IP not the VIP ip. I am new to this product.

CSS 11501

OS = 7.20.206

Win2k Terminal servers SP4

RDP and Terminal server clients (Ver 5 build 2195)

running config as follows:

configure

!*************************** GLOBAL ***************************

no restrict web-mgmt

ftp-record Primary-Boot 192.168.100.114 css des-password xxxx

ftp-record Secondary-Boot 10.1.1.1 anonymous des-password xxxxx

ftp-record DEFAULT_FTP 192.168.100.114 css des-password xxxx

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

circuit VLAN1

ip address 172.16.10.10 255.255.254.0

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

service CF01T01

protocol tcp

port 3389

ip address 172.16.10.76

service CF01T02

ip address 172.16.10.77

protocol tcp

port 3389

max connections 25

active

service CF01T03

ip address 172.16.10.78

protocol tcp

port 3389

max connections 25

active

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

owner CF_Terminal_Servers

content CF_Terminal_Servers

add service CF01T01

add service CF01T02

vip address 172.16.10.75

protocol tcp

port 3389

add service CF01T03

active

!*************************** GROUP ***************************

group TerminalServers

add service CF01T02

add service CF01T03

vip address 172.16.10.75

add service CF01T01

active

Re: Basic config help

d.parks — Fri, 30 Jan 2004 17:02:48 GMT

Depending on your network layout, you may need to change your group configuration. Try "add destination service" instead of "add service"

Re: Basic config help

stevehall — Fri, 30 Jan 2004 17:58:13 GMT

Jaime,

I can not be positive, but it looks likely that the servers are not behind the CSS, but in front (sharing an interface with the default gateway). If this is the case, moving them behind the CSS should get it working. If this is not possible, you will need access lists to activate the group, since the NAT will have to be more complex.

If that is the case, let me know and I will formulate an ACL that should get you moving in the right direction.

-Steve

Re: Basic config help

d.parks — Fri, 30 Jan 2004 19:42:12 GMT

Using the "destination service" command in your group will NAT the traffic without an ACL.

An ACL would likely work as well though.

Re: Basic config help

stevehall — Fri, 30 Jan 2004 21:10:27 GMT

The only issue I see with using destination service in the group is you are already using the group with the "add service" option.

You can't add a service to a group twice, which included "add service" and "add destination service" for the same service. That is the reason ACLs will be required.

-Steve

Re: Basic config help

d.parks — Fri, 30 Jan 2004 22:39:03 GMT

Good point, though I suspect the original group configuration may not be needed. I'm assuming that the servers' non-loadbalanced traffic does not pass through the CSS due to how the routing is setup. From what I've seen, this type of group configuration is generally only needed when the servers go through the CSS to get to another address space, usually the internet, and their addresses are not valid in that space.

One question for you regarding the ACL based NAT configuration since I'm not familiar with it... Do you have to take an outage to reconfigure the NAT when adding servers to your pool? My only gripe with the "source group" method is that I've got to suspend my groups to add or remove services.

Re: Basic config help

andrew.thomson — Wed, 04 Feb 2004 13:13:45 GMT

I have a "one-armed configuration" as well and successfully use a simple source group with "add destination service" to ensure traffic is returned through the CSS.

However, I also have the gripe about having to suspend the group (and disrupt existing flows) in order to add a new service.

I would be interested to know if there is a logical reason or should we raise an enhancement request.

The only other ways to avoid down time that I have found is to create a group per service, or configure spare services to insert in the group, to be configured with detail at a later date.

Incidentally how does HSE handle this sort of configuration. We are considering deploying HSE but not if we have to do a lot of fiddling around!