CSS redundancy on one-armed configuration

Can we configure box-to-box redundancy on a one-armed configuration or do we have to use the 'Active-active stateful failover ASR' ?
We are using CSS 11500.

you can use box-to-box.
However, the vip/interface redundancy is much more interesting.
With the combination of ASR you have stateful redundancy that you do not have with box-to-box.
Also, box-to-box redundancy as a single point of failure since you can have only 1 cable for the redundancy protocol between the 2 CSS.
If this connection fails, both CSS will become active and you get into lot of troubles.
Regards,
Gilles.

Similar Messages

CSS One Arm Configuration with VIP(non-shared)/IP Interface Redundancy

With Reference to the following CCO documentation;
1). "How to Configure the CSS to Load Balance Using 1 Interface"
In this example, the Real Server's (10.10.10.2 etc) gateway are pointed to the router's gateway(10.10.10.1) and used the 'add destination service' command to NAT the RealServer's IP address back to the VIP (10.10.10.6).
2). "Understanding and Configuring VIP and Interface Redundancy on the CSS11000".
In the interface redundancy configuration, the gateway of the Real Server are configured as the CSS11000's Interface Redundancy Address (192.168.1.1), not the Router's gateway.
Can anyone help to advise on the preferred one arm configuration with VIP/IP redundancy?
(i). Is the reason for configuring the gateway of the Real Server to CSS11000's Interface Redundancy Address in 2) same as using 'add destination service' command in 1)? That is to make sure that the return path from Real Server back to Client passes through the CSS and is NAT back to the VIP.
(ii). To configure VIP(non-shared)/IP Interface redundancy(Active/Backup Mode) in a one arm configuration, my understanding is that there are 2 methods of configuration. Is it correct? Which method is preferred?
Method a)
1.Configure the Real Server's gateway to Router's Gateway
2.Configure 'add destination service' command on the CSS to NAT the RealServer's IP address back to the VIP
3.Configure VIP(non-shared) redundancy for the VIP on the CSS
4.IP Interface Redundancy on the CSS is not required as the Real Server's gateway is already pointing to the Router's gateway. (Assuming that HSRP redundancy is already running on the Router)
Method b)
1. Configure the Real Server's gateway to the CSS's IP Interface Redundancy IP Address
2. Configure IP Interface Redundancy on the CSS (as the Real Server's gateway)
3. Configure VIP(non-shared) redundancy for the VIP on the CSS

if you use method a) (server gateway is the router) you need the CSS to nat
the source ip address of the client in order to force the server to send traffic back to the CSS.
The issue then is that the server does not see the IP address of real client.
The server only see connections with source IP address = CSS ip address.
With method b) you don't have the above problem, but connection initiated by the servers are sent to the CSS that will then send it to the router.
You have a performance issue because the traffic will cross 2 times the one-armed interface.
If this is a new design, it is strongly recommended not to use one-armed setup.
Regards,
Gilles.

CSM-S, move to one-arm configuration.

Hello.
We are using a couple of CSM-S with a single subnet bridge and fault tolerance configuration. Now we are evaluating to move to an one-arm configuration, so I’m reading some design guides.
We want to move to this topology because there are some advantages like efficient utilization of resources.
Because we are serving different areas with different security level I’m looking for best practices also.
The main question is about security because CSM does not support virtual contexts like ACE.
Any suggestions?
Thanks.
Andrea

Hello Andrea,
As you noted, the capability for ACE to be able to keep traffic segregated is much easier to work with than the CSM's. Basically, you have to utilize both client groups and the VLAN statement under Vservers to be able to keep traffic segregated. Here is an example:
module ContentSwitchingModule 4
vlan 100 client
ip address 192.168.100.1 255.255.255.0
vlan 150 client
   ip address 192.168.150.1 255.255.255.0
vlan 200 client
   ip address 192.168.200.1 255.255.255.0
vlan 250 client
   ip address 192.168.250.1 255.255.255.0
natpool POOL-1 192.168.100.2 192.168.250.2 netmask 255.255.255.0
natpool POOL-2 192.168.150.2 192.168.250.2 netmask 255.255.255.0
natpool POOL-3 192.168.200.2 192.168.250.2 netmask 255.255.255.0
natpool POOL-4 192.168.250.2 192.168.250.2 netmask 255.255.255.0
serverfarm DMZ1
nat server
nat client POOL-1
real 192.168.100.50
no inservice
real 192.168.100.51
inservice
real 192.168.100.52
inservice
serverfarm DMZ2
nat server
nat client POOL-2
real 192.168.150.82
   no inservice
real 192.168.150.83
   inservice
real 192.168.150.84
   inservice
serverfarm DMZ3
nat server
nat client POOL-3
real 192.168.200.75
   no inservice
real 192.168.200.78
   inservice
real 192.168.200.90
   inservice
serverfarm DMZ4
nat server
nat client POOL-1
real 192.168.250.82
   no inservice
real 192.168.250.83
   inservice
real 192.168.250.84
   inservice
vserver DMZ1
virtual 192.168.100.10 tcp www
vlan 100
serverfarm DMZ1
persistent rebalance
inservice
vserver DMZ2
virtual 192.168.150.10 tcp www
vlan 150
serverfarm DMZ2
persistent rebalance
inservice
vserver DMZ3
virtual 192.168.200.10 tcp www
vlan 200
serverfarm DMZ3
persistent rebalance
inservice
vserver DMZ4
virtual 192.168.250.10 tcp www
vlan 250
serverfarm DMZ4
persistent rebalance
inservice
In the above configuration, if any packet comes into vlan 100 destine to 192.168.100.10 on port 80, it can hit the vip. If the same packet comes into any other vlan, it will not be able to hit the vip. The "vlan 100" statement under DMZ1 vserver filters the traffic so that only traffic that came into that vlan can hit that specific vserver.
If you need to do additional filtering, say by source subnet range, you can use client groups to furthur permit/deny traffic at a more granular level. Here is an example:
(The access-list is created globally on the 6500 - the access list is then referenced by number in the CSM configuration. ONLY standard access lists can be used!!)
access-list 2 permit 192.168.0.0 0.0.255.255
access-list 2 deny   any
access-list 3 permit 10.10.0.0 0.0.255.255
access-list 3 deny   any
policy 192_subnet_filter
client-group 2
serverfarm DMZ4
vserver DMZ4
   virtual 192.168.250.10 tcp www
   vlan 250
slb-policy 250_subnet_filter
   persistent rebalance
   inservice
With this configuration, only traffic with a source IP of 192.168.0.0/16 or 10.10.0.0/16 that arrive on vlan 250 will be allowed to hit the vserver. "Client-Group 2" refers to the "Access-list 2" in the global config.
Note that the serverfarm that used to be under the vserver was removed. If you leave the serverfarm DMZ4 statement under the vserver along with the slb-policy applied, and traffic that does not match your client group is sent to that serverfarm. It is another way of filtering traffic out. If you do not include a fallback serverfarm (like the example above), any traffic that doesn't match the client group is reset.
Let me know if you have any furthur questions!
Regards,
Chris Higgins

CSS one-armed-config and SMTP reverse lookup problems?

I was wondering if there would be potential reverse lookup problems from other company's when we try to send mail to their mail Domains.
If I configure failover for our mail server, I am thinking if we are sending mail, there could be a reverse-lookup issue, because our mail server would be configured with public IP Addresses other than what the MX record points to in DNS.
If we originate mail from our inside users, it will originate from the service IP address and not the VIP address.
Is this a valid concern?

The main advantage of this configuration is that the web servers will receive the IP address of the client that made the request. This is often required by web servers' administrators for accounting purposes.
In a one-armed configuration only, the network port ( Enet0) is used on the SCA. Only this specific port can be used for this setup. Encrypted and decrypted traffic will go through the same link
http://www.cisco.com/en/US/products/hw/contnetw/ps2083/products_configuration_example09186a00801bbf4e.shtml

Trying to run CSS11503 08.10.0.02 one-armed DNAT+SNAT with UDP 921

Is there a way to perform DNAT + SNAT and portmap disable on the CIsco CSS 11503. I need to do a DNAT in a one-armed configuration and the to SNAT for UDP traffic with SRC Port 9211 and DST Port 9211. I don't need loadbalancing but only NAT. Is there a way to solve this issue with ACL. Any help will be appreciated...
Thanks

if you want to do DNAT, you have to it a content rule.
The vip will be nated to the service address.
Then you need a group to nat the client ip.
Finally, you need to use the command 'portmap disable' under the group to avoid port mapping.
Gilles.

One-Armed Load Balancing

Can CSS 11000 load balance multiple server farms, using different load balancing algorithms on the same ip subnet and having multiple VIPs in the one-armed configuration.
I know this is not an ideal configuration but have to do it for a relocation project.
Thank yoi

yes you can.
No need for a trunk.
But you have to keep in mind that the CSS must see both sides of a connection.
So, obviously the traffic from the client will hit the CSS vip, but for the server response, you have to make sure it goes back to the CSS.
This can be done with source nating or policy routing.
Gilles.

CSM-S mode -One-Arm-vs- routed

We currently have an environment with CSS running in routed mode. We are building a new data center with 6509s and CSM-S. My question is what is the best mode to run the CSM-S in routed or one-arm and why?

Gilles,
What do you recommend when the traffic flows from the load balanced server are significant?
ie: you are using Oracle application and database servers, load balancing http and https to the app servers. There is significant traffic flow from the app server to the database servers, such that the load balancer in a 2-armed configuration(particularly a CSS11501 w/ 8 10/100 interfaces and a single 1000Base-T interface) would be a significant bandwidth bottleneck.
Also, if Cisco usually does not recommend one-armed config.... why does the latest Server Farm Security Solution Reference Network Design v2.0 (http://www.cisco.com/warp/public/732/systems/docs/dcsrndbk.pdf) recommend a one-armed configuration for the CSS?

Please verify the CSS and SCA configuration for one-armed transparent mode

I have a problem to configure one-armed transparent mode. I cannot access the server with "https://9.9.9.1" even "http://9.9.9.1:80" and "http://9.9.9.1:81" operational. looks CSS cannot communicate properly with SCA.
I couldn't figure out from CCO sample configuration. please correct the attached configuraiton.
Thanks,
** connectivity ********
<client>----<router>----<CSS>---<SCA>,<Server>
- client=7.7.7.100
- router's e0/0=7.7.7.1, e0/1=8.8.8.3(connect to VLAN2 of CSS)
- SCA=11.11.11.100, connect to VLAN3 of CSS
- server=10.147.153.12 and 10.147.153.15 on the same box, connect to VLAN4 of CSS
** configuration *********
CSS11050# sh run
!Generated on 01/01/2079 00:00:47
!Active version: ap0500105
configure
!*************************** GLOBAL ***************************
acl enable
ip route 0.0.0.0 0.0.0.0 11.11.11.100 1
ip route 7.7.7.100 255.255.255.255 8.8.8.3 1
ip route 7.7.7.200 255.255.255.255 8.8.8.3 1
!************************* INTERFACE *************************
interface e2
bridge vlan 2
interface e3
bridge vlan 3
interface e4
bridge vlan 4
interface e5
bridge vlan 4
!************************** CIRCUIT **************************
circuit VLAN1
ip address 9.9.9.2 255.255.255.0
circuit VLAN2
ip address 8.8.8.2 255.255.255.0
circuit VLAN3
ip address 11.11.11.1 255.255.255.0
circuit VLAN4
ip address 10.147.153.1 255.255.255.0
!************************** SERVICE **************************
service ING_SVC_12
protocol tcp
ip address 10.147.153.12
active
service ING_SVC_15
protocol tcp
ip address 10.147.153.15
active
service ING_SVC_SCA
port 443
protocol tcp
ip address 11.11.11.100
type transparent-cache
no cache-bypass
active
service upstream
ip address 8.8.8.3
type transparent-cache
active
!*************************** OWNER ***************************
owner ING_OWNER
content cnt_443
add service ING_SVC_SCA
protocol tcp
port 443
vip address 9.9.9.1
active
content cnt_80
add service ING_SVC_12
add service ING_SVC_15
protocol tcp
port 80
url "/*"
vip address 9.9.9.1
active
content cnt_81
add service ING_SVC_12
add service ING_SVC_15
vip address 9.9.9.1
protocol tcp
port 81
url "/*" <-- If I configure url "/secure/*", not working "http://9.9.9.1:81" from client.
active
!**************************** ACL ****************************
acl 1
clause 10 permit any any destination any
apply circuit-(VLAN1)
acl 2
clause 10 permit any any destination any
apply circuit-(VLAN2)
acl 3
clause 10 permit any any destination any
apply circuit-(VLAN3)
acl 4
clause 10 permit any any destination any
apply circuit-(VLAN4)
ING_SCA# sh run
# Cisco SCA Device Configuration File
# Written: Sun Feb 6 01:12:54 2106 MST
# Inxcfg: version 4.1 build 200211151311
# Device Type: CSS-SCA
# Device Id: S/N 11aca8
# Device OS: MaxOS version 4.1.0 build 200211151311 by reading
### Mode ###
mode one-port
### Interfaces ###
interface network
auto
end
interface server
auto
end
### Device ###
ip address 11.11.11.100 netmask 255.255.255.0
hostname ING_SCA
timezone "MST7MDT"
### Password ###
password idle-timeout 15
### SNTP ###
sntp interval 86400
### Static Routes ###
ip route 0.0.0.0 0.0.0.0 11.11.11.1 metric 1
### RIP ###
no rip
### DNS ###
no ip name-server
no ip domain-name
### Telnet ###
telnet enable
### Web Management ###
web-mgmt port 80
no web-mgmt enable
### SNMP Subsystem ###
no snmp
### SSL Subsystem ###
ssl
server ING create
ip address 9.9.9.1
localport 443
remoteport 81
key default
cert default
secpolicy default
sslv2 enable
sslv3 enable
tlsv1 enable
session-cache size 20480
session-cache timeout 300
session-cache enable
no clientauth enable
clientauth verifydepth 1
clientauth error cert-other-error fail
clientauth error cert-not-provided fail
clientauth error cert-has-expired fail
clientauth error cert-not-yet-valid fail
clientauth error cert-has-invalid-ca fail
clientauth error cert-has-signature-failure fail
clientauth error cert-revoked fail
sharedcipher error failhtml
ephemeral error failhtml
no httpheader client-cert
no httpheader server-cert
no httpheader session
no httpheader pre-filter
httpheader prefix "SSL"
ephrsa
keepalive frequency 5
keepalive maxfailure 3
no keepalive enable
end
end

the problem is the routing.
You need a route for the client pointing to the SCA like this
ip route 7.7.7.100 255.255.255.255 11.11.11.100 1
This is so the reply from the server to the client goes back to the SCA first
for encryption.
Gilles.

CSS11500 one arm design configuration assistance.

Is it possible to configure the CSS11500 as single arm design? if yes how to configure the source nat on the CSS11500, it is not possibe for me to change the default gateway as well as configure CSS as inline.
Regards

yes you can configure CSS in one armed mode. You would do the nat with a group config ie:
service yada
ip address 192.168.20.40
active
content yadayada
vip address 192.168.20.55
add service yada
group yadayadayada
vip address 192.168.20.55
add destination service yada

Can I configure csm as one arm and routing mode at the same time?

My csm currently is configured as the routing mode and bridge mode, resently I have a service requirement which I think the one arm mode should be the best resolution. Can anybody let me know if there will be any affect if I add the one arm mode to the currently production environment?
Thanks in advance.
Jason

Gille,
Thanks for your quick response. I notice you have same opinion about the one arm mode in your other post, but I think in the multi-tire data center design with fw in bridge mode and csm in one arm mode with RHI, do give us a lot of flexibilty. If I use policy routing instead of source nat, can I overcome these limit you metioned?
Do you know who csm could handle the TFTP traffic? I may have too much question, I am realy looking for your suggestion.
Thanks
Jason

CSS 11503 One armed config

All,
I got a question on the one armed config.
Cisco says use "destination service" under the source group to change the default NAT behaviour of the CSS, 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. I understand this way you avoid the packets reaching the router directly when they head back to the client, bypassing the CSS.
Now the question I got here is that, what if I set the Servers' default gateway to the CSS rather than the Router. This way you are actually forcing the packets destined for remote networks to go through the CSS DG.. Should I need the source group anyway here. I think I don?t. Someone please clarify. Much appreciated?
thanks

if you set the default gateway to be the CSS, then there is no need for the source group.
However, if you have traffic going directly to the servers, they will go client-->router-->server-->CSS [breaks - because asymetric flow].
If you never access the server directly, you're ok. OR you can set a route on the router forcing the traffic through the CSS.
Gilles.

CSM in one armed mode Redundancy

Hi,
I have a customer with a one arm setup. However they have no server vlan, only a client vlan. They are using source nat and it is working, however I am unsure how to setup redundancy as the alias command seems to be generally used on the server vlan.
i am running hsrp and a ft vlan accross the csm's
Does anyone have any experience of this type of setup, do i need to add any additional config for fault tolerence??
Cheers
Scott

Scott,
you can use the alias and whatever vlan [client or server].
It is required if your servers or clients are using the CSM as default gateway.
There is no special config required when doing fault tolerance in one-armed mode.
It's the same as inline mode.
Gilles.

CSS 11503 One-arm Design and Server Default Gateway

Our problem is determining the correct default gateway for our web servers. All IP addresses are in the same subnet (VIP, interfaces, and servers). Should the servers default gateway be the L3 switch, or the CSS?
Thanks!
Tom

Hi Tom,
If you have one arm mode, you might have problems with asymmetric flows, due that the CSS behaves similar to a firewall when it comes to flows, as it needs to see both sides of the flow ( client and server side ) in order to handle things correctly. Having this kind of setup, and even when the server pointing to the CSS as its default gateway, ICMP redirects might force the traffic to change dynamically.
You can put as default gateway the L3 switch, but you need to force the traffic that has been load balanced by the CSS to go back to the CSS, otherwise the flow would fail. You can do this by using a group on the CSS, adding the service with the following command: 'add destination service xxxx'. This would NAT the client's IP address for the VIP that you use on the group and would force the flow to go back to the CSS.
Another thing that you can do is to use the CSS as the server's DG, but you must make sure that all L3 devices, including the CSS have ICMP redirects turned off on this subnet. If you have a firewall on this subnet, you would need to turn off proxy ARP as well.
I hope you find this helpful. Thanks!
Regards,
Jose Quesada.

CSS one arm config

CSS 11506
Is it possible to pass Client's IP address
to the Backend servers in One arm config.
It is so that we can get stats on Web Server
Thanks in advance

Unfortunately CSS does not support HTTP header insertion.
You can either perforn PBR at the Real Server's Default gateway or use CSS as default gateway of Real Servers.
Thanks
Syed Iftekhar Ahmed

One-armed LB with Trunk

What are the downsides of using a one-armed LB solution? I am trunking multiple VLANs across one interface instead of using multiple interfaces to connect to my server farm. The servers still have their default gateway as the CSS.

Thee are performance issues if the CSS has to LB over one interface. These should not be under estimated !!
However if you are trunking in to the CSS, you may not have this. It depends on how you configure your "logical" network. You could use one physical interface, but run two vlans over it (a trunk), these vlans are two logical interfaces, so in fact you are not running true one-armed. On CSS the vlans bind to the circuits to form the interfaces, it is only when you are LB over one circuit that you get performance issues.
Hope that made sense :-)

CSS redundancy on one-armed configuration

Similar Messages

Maybe you are looking for