CSM-S, move to one-arm configuration.

[andrea.meconi]

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

[chrhiggi]

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

[andrea.meconi]

Hello Christopher and many many thanks for your help.

I'm reading design guide "Server Farm Security in the Business Ready Data Center Architecture v2.1" that suggests to use vlan server when configuring one-arm.

What do you think about?

Thanks.

Regards.

Andrea

[chrhiggi]

Andrea-

Thats not a bad idea.  The VLAN designation of "Client" vs. "Server" is subtle when deploying a one-armed configuration, but you will end up with more bandwidth and PPS by using a server VLAN. 

Here is the back story behind that:

The documentation for the CSM denotes this about the Client vs. Server VLANs:

The differences between client-side and server-side VLANs are as follows:

•When configuring bridge mode, you cannot bridge two server VLANs or two client VLANs. You can only bridge a client and a server VLAN.

•Denial of service (DoS) protection features are more aggressive on the client-side VLANs, especially when rate limiting control traffic is sent to the central processing unit.

However, there are a few other things that the CSM does aside from just that.

1.) A "Client" VLAN is limited internally to 500 packets per tick and 2,000 packets per tick (a tick is a CPU clock cycle which is roughly .819 seconds for the CSM)

2.) In a routed mode, if you have a server listed in the CSM configuration + the CSM has ARP for that server + the ARP response was learned off of a "Server" vlan - The CSM will allow that IP to initiate connections through itself. 

  If you had another server that was in the CSM configuration + we had an ARP entry for it, however, the ARP was learned off of a "Client" VLAN - The CSM would drop any initiated connections from the server.

The reason behind these 2 ideas has to do with the DoS capabilites of the CSM.  You need the Client facing VLAN to be more restrictive than the server.  In a one-armed mode, since there is a direct routed path to the servers that is outside of the CSM entirely, it is assumed that you are protecting them from attack by other means. For examply, you would have a firewall/IDS/security device at the head end of the network that would not allow external clients to go directly to a server - they only have access to the CSM. As well, the security device would have basic DoS abilities.  Given that, you do not need the CSM to protect the servers, so it is not necissary to use a "Client" vlan.

Regards,

Chris Higgins

[andrea.meconi]

Hello Christopher.

So if I understand well I can move to one arm very quickly.

Please have a look at the attached example.

ACTUAL CONFIG WITH BRIDGE MODE

!
vlan 500 client
  ip address 192.168.150.59 255.255.255.0 alt 192.168.150.60 255.255.255.0
  gateway 192.168.150.250
!
vlan 502 server
  description Server Farm DMZ0
  ip address 192.168.150.59 255.255.255.0 alt 192.168.150.60 255.255.255.0
!
real S1
  address 192.168.150.231
  inservice
!
real S2
  address 192.168.150.232
  inservice
!
serverfarm S-FARM
  nat server
  no nat client
  real name S1
   inservice
  real name S2
   inservice
!
vserver S-VIP
  virtual 192.168.150.230 tcp www
  vlan 500
  serverfarm S-FARM
  inservice
!

NEW CONFIG (ONE-ARM)

!
vlan 500 server
  ip address 192.168.150.59 255.255.255.0 alt 192.168.150.60 255.255.255.0
  gateway 192.168.150.250
!
natpool POOL-DMZ0 192.168.150.2 192.168.250.2 netmask 255.255.255.0
!
real S1
  address 192.168.150.231
  inservice
!
real S2
  address 192.168.150.232
  inservice
!
serverfarm S-FARM
  nat server
  nat client POOL-DMZ0
  real name S1
   inservice
  real name S2
   inservice
!
vserver S-VIP
  virtual 192.168.150.230 tcp www
  vlan 500
  serverfarm S-FARM
  inservice
!

What do you think about?

Thanks.

Regards.

Andrea

[chrhiggi]

Hello Andrea-

That is 100% correct configuration, great job.  Don't forget when you make the change, you need to move the switchport the server is connected to from VLAN 502 into VLAN 500.  At that point, you will probably also want to clear the TCAM table (clear mac-address table dynamic) on the 6500 the CSM is in/server is connected to in order to update the L2 location of the server as fast as possible.

Regards,

Chris Higgins