Second Client Side VLAN - CSM

Question

Our current environment has grown to the size that a single Class C subnet on the client side of the CSM is full. We have a need to add an additional Class C subnet for the client side, but our TCOM group gave us a range which is not contiguous to the existing range and therefore cannot be added by simply changing the subnet mask (from 24 to 23).
The default route for all traffic from the CSM is an IP address on the subnet described above.
How should the new subnet be configured? I understand that there can only be one gateway on the CSM...so if traffic comes in on the second subnet, does this mean that it will go back out on the first subnet?
Does this look right
vlan 111 client
ip address 192.168.111.5 255.255.255.0
gateway 192.168.111.1
vlan 222 client
ip address 192.168.222.5 255.255.255.0
On the Switch, when I run
"sho ip route 192.168.111.5"
it replys with "directly connected, via VLan111"
When I run
"sho ip route 192.168.222.5"
it also replies back with the same:
"directly connected, via VLan111"
Please note: That I only manage the CSM and SSL-M. The switch and MSFC are managed by our TCOM group. Thanks for any information on this request!

Answer 1

First, I want to thank you for the quick replies.
I understand what you are explaining here and believe that our current configuration is as you have explained, but need to further clarify what we have in place.
The single vlan on the client side previously had only a single class C subnet. It now has two separate Class C subnets. Traffic can reach the CSM, but never returns back to the client. When I added the configuration for the second VLAN client side and addressed it as part of the second class C address, content would now be returned to the client from the server side. But, I could not get the content to be forwarded to the SSL module which resides on a separate VLAN. I then removed client VLAN and traffic continued to flow properly (except to SSL module). I then cleared connections to the vservers (to emulate a reboot), this caused all traffic to no longer return to the client.
Below is configuration (IP addresses changed to protect the innocent).
ssl-proxy module 2 allowed-vlan 4,219
ip subnet-zero
vlan 200 server
ip address 172.54.200.2 255.255.254.0
alias 172.54.200.1 255.255.254.0
vlan 4 server
ip address 192.168.219.5 255.255.255.0
vlan 219 client
ip address 192.168.219.5 255.255.255.0
gateway 192.168.219.1
natpool SERVERSIDE1 172.54.200.241 172.54.200.254 netmask 255.255.254.0
interface Vlan64
description Network 64
ip address 172.32.64.219 255.255.255.0
ip accounting output-packets
ip route-cache flow
logging event link-status
shutdown
interface Vlan65
description Network 65
ip address 172.32.65.219 255.255.255.0
ip accounting output-packets
ip route-cache flow
logging event link-status
interface Vlan219
description WebTeam URL Network
ip address 192.168.222.2 255.255.255.0 secondary
ip address 192.168.219.2 255.255.255.0
no ip redirects
no ip unreachables
ip pim dense-mode
ip route-cache flow
no ip mroute-cache
standby 10 ip 192.168.219.1
standby 10 timers 3 9
standby 10 priority 110
standby 10 preempt
standby 11 ip 192.168.222.1
standby 11 timers 3 9
standby 11 priority 110
standby 11 preempt
ip classless
ip route 172.54.200.0 255.255.254.0 192.168.219.5
NOTES: SSL-MODULE IP address 192.168.219.6 on VLAN 4.
I will go ahead and open TAC Case and post results later.