ARX configuration/network layout

Derek,

 

 

What model of Cisco switch? Does it support MCEC/VSS? If so then you can treat the channels as virtual and split a single ARX channel across multiple core Cisco switches. If the Cisco switch does not support MCEC/VSS then dual homing channels is not a mode we typically test/deploy with. My only concern would be the potential for MAC address thrashing if things would be learned via multiple channels. I do not know if this would occur, but because this is a mode we don't test, I can't promise what the behavior would be.

 

 

From the VLAN/routing perspective, here is some detail I hope will help you out (I can't paste in the diagrams), but hopefully it explains the issues when deploying in a dual VLAN mode.

 

 

Each customer must decide which ARX deployment mode is best for their environment. In dual VLAN mode the default gateway is pointed to the gateway on the client network where the Virtual IP addresses are configured. If storage is on the same subnet as the server facing VLAN where the proxy IP addresses reside then no additional routing needs to be configured, except for authentication. If however, storage is on a different subnet than where the ARX proxy IP addresses reside, then static routes to the filer subnet, or individual host routes to each filer must be configured using the gateway on the sever facing network. Individual host based routes are only required if there will be clients accessing ARX Virtual Servers on the same subnet as storage virtualized by the ARX.

 

 

The diagram below depicts a typical dual arm deployment. A “client” VLAN/subnet is configured on the 10.1.1.x network. An in-band management IP address (10.1.1.100) and a Virtual IP address (10.1.1.101) are configured on this subnet. Clients access the VIP from many external subnets so the ARX is configured with two default routes which differ only by gateway and cost. The default route to gateway 10.1.1.254 is preferred because it is lower cost (cost of 10), and the default route using gateway 10.1.1.253 is a backup route because of its higher cost (100) and it will only become active if 10.1.1.254 becomes un-available. Default routes should always be used on the client network in a dual VLAN setup because there tends to be more client subnets than storage subnets. Dual VLAN setups will require more manual routes than a one-armed configuration.

 

 

The storage being virtualized by the ARX in the diagram above is also on a remote network, and requires that the ARX have a route to that destination. A default route cannot be configured because there already is a default route in use on the client facing network. The proper configuration in this case is to point the ARX to the gateway (10.5.5.254) on the server side VLAN/subnet and use a static route. The route should be configured for either the subnet (network based route to 10.6.6.0/255.255.255.0) pointing to where the storage resides, if there are no clients that will access the ARX on this subnet, or to the storage (host based route 10.6.6.1/255.255.255.255 & 10.6.6.2/255.255.255.255) if there are also clients that reside on the same subnet as the storage. A host route would need to be added for each storage device under ARX management in this case.

 

 

The routing is setup this way in a dual arm deployment to ensure responses to clients are sent back using the client gateway, and traffic destined for storage is sent via the server network gateway. If there are any stateful firewall devices in the network this is critical so that conversations are not dropped because they are asymmetric meaning responses are sent over a different path than the request. A firewall will not allow this to occur, the request and response would need to traverse the same path.

 

Another consideration for dual arm deployments is that the server subnet must be routable, and the ARX proxy IP addresses must be able to route to external subnets. When the ARX needs to communicate to Active Directory or NIS authentication services, it will initiate the transaction using one of its proxy IP addresses which reside on the server network. If the network does not have a gateway, or if it is configured with a private non-routable subnet in the customer environment, then the ARX will be unable to authenticate clients because it will not be able to contact the authentication services.