Re: Is this valid?

paul.matthews · ‎07-20-2004

I have been asked to look at a CSS config, but am still quite new to them myself. There are a pair set for box-box redundancy. I have dropped those bits out as the bits I am interested in are the use of a content rule to create a VIP for the return traffic, and the group at the bottom.

It does look a bit of a waste of a CSS - the content rule appears to be a failover rule rather then doing much of use!

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

ip route 0.0.0.0 0.0.0.0 172.19.2.2

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

circuit VLAN1

ip address 172.19.1.1 255.255.255.0

circuit VLAN2

ip address 172.19.2.2 255.255.255.0

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

service remoteproxy

ip address 10.11.12.1

active

service insurancesvr1

ip address 172.19.1.2

keepalive method get

port 8080

keepalive type tcp

active

service insurancesvr2

ip address 172.19.1.3

keepalive method get

port 8080

keepalive type tcp

active

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

owner TEST

content returnVIP

vip address 172.19.1.254

add service remoteproxy

active

content insuranceservers

vip address 172.19.1.3

add service insurancesvr1

primarySorryServer insurancesvr2

protocol tcp

active

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

group translate

vip address 172.19.1.254

add service remoteproxy

active

d.parks · ‎07-20-2004

This looks very broken to me... Why is the sorryserver's IP the same as the content VIP? I also don't see where the group comes into play.

Perhaps if you describe what you're trying to do, we can come up with a solution?

paul.matthews · ‎07-20-2004

The address clash was a typo on my part in sanitising the addresses as this is for a secure customer.

Imagine the config like this instead (just changed the VIP)

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

ip route 0.0.0.0 0.0.0.0 172.19.2.2

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

circuit VLAN1

ip address 172.19.1.1 255.255.255.0

circuit VLAN2

ip address 172.19.2.2 255.255.255.0

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

service remoteproxy

ip address 10.11.12.1

active

service insurancesvr1

ip address 172.19.1.2

keepalive method get

port 8080

keepalive type tcp

active

service insurancesvr2

ip address 172.19.1.3

keepalive method get

port 8080

keepalive type tcp

active

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

owner TEST

content returnVIP

vip address 172.19.1.254

add service remoteproxy

active

content insuranceservers

vip address 172.19.1.199

add service insurancesvr1

primarySorryServer insurancesvr2

protocol tcp

active

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

group translate

vip address 172.19.1.254

add service remoteproxy

active

I wish I knew what the originator was trying to do - my thoughts would be to scrap the config and start from scratch with redundant interface/vip/ASR rather than Box to box, but I don't know if the group is in there for a reason, and what the point of the proxy vip is...

d.parks · ‎07-20-2004

In that case, the "insurance" content rule and services look ok to me.

The other content rule, group, and service do not seem to be involved at all with the "insurance" configuration, so I'm not sure what might be going on there.

As configured, any traffic sourced from the remoteproxy service that passes through the CSS would be translated to the translate group's VIP address.

paul.matthews · ‎07-20-2004

Thanks for that. I was thinking the intent of the remote proxy group was to simulate a VIP for the return traffic. I was a little uncertain about the idea of using a content rule for that though!

d.parks · ‎07-20-2004

The content rule isn't required for the translation piece. They are often used together, but they don't have to be.