ARX configuration/network layout

Question

Hi guys,&nbsp;
We have a pair of ARX2000's that I'm getting ready to setup.  I want to 
make sure I set them up properly.  The following is how we're planning 
on configuring the ARX's&nbsp;&nbsp;
5 ports set up in an LACP single arm aggregation to allow for a single 
link loss (4 ports sending traffic and one for parity).  It will reside 
in our vlan 32, and use vlan tagging.  All client networks are 
route-able to that network.  We'll have another 5 ports set up in a 
similar aggregation cabled into our redundant core switch - with the 
expectation that this would only ever be used if we lost the primary 
core switch.  Not entirely sure how to set the arx to make sure traffic 
doesn't send on the 2nd set of 5 interfaces.  Our network engineers say 
that we can use spanning tree for this.  The last 2 ports will be set up
 for in-band management. (are these what will handle heartbeat traffic 
as well??)&nbsp;&nbsp;
Is this something that sounds do-able?  I'm coming at this from a 
unix/storage perspective and not so confident on the network layout 
perspective.&nbsp;
&nbsp;Cheers,
&nbsp;-Derek&nbsp;

hadams1234_3487 · Answer

Hell Derek.... 
&nbsp;  
&nbsp; I don't see anything wrong with your idea, I can share how we are setup, per the advice of the F5 consultant.... We have twin 6509 core switches, configured in VSS, so both switches are logically one. Each one of our ARX's has a 8 member LACP arm to the core, four links to the primary, and 4 links to the secondary switch. All ARX traffic is sent thru this single interface "arm". For heart beat traffic we set up two links interconnecting the two ARX's. (direct ARX to ARX connection) In band managment is handled over the 8 member LACP team back to the core switches. Also worth nothing, we do not trunk these ports. They are access interfaces. 
&nbsp;  
&nbsp; Hope this helps.... 
&nbsp;  
&nbsp; Harold

jim_mccarron_44 · Answer

Derek, 
&nbsp;  
&nbsp; Typically we try to avoid anything using Spanning Tree due to the outages it may cause during reconfiguration. The recommended configuration we typically use is  a single channel form each ARX to a single core switch. You could also have multiple VLANs if this is required. The only downside to this approach is if you loose the active core switch, it will also cause the ARX to fail over to the standby. The ARX does not support any sort of resilient link technology today, so you could either go the STP route if you absolutely need to have links to both core switches, or if you are running a Cisco L2 core that supports MCEC (Multi Chassis EtherChannel) / VSS (What Harold is running in the comment above) you can take a single ARX channel and split it across 2 Cisco (1 virtual) switches.   
&nbsp;  
&nbsp; Jim

derek_murphy_38 · Answer

Thanks for the responses Harold and Jim.  I'm at the point where I'm actually setting up the boxes now.. and my setup changed slightly now after reading some docs a bit. 
&nbsp;  
&nbsp; I am figuring on 4 ports lacp going to core switch 1, 4 ports lacp going to core switch 2, 2 ports - heartbeat, 2 ports in-band management.  I still want to go the route of having both ARX's connected to both core switches because I don't want to have to fail over the ARX if I lose a core switch. 
&nbsp;  
&nbsp; One thing I am curious about is how the proxy-ip addresses work with regards to actual data transmission. 
&nbsp;  
&nbsp; The VIP that is going to be bound to the namespace is going to be on our vlan 32  - /22 net (10.10.32.something).    Our netapp filers are all on vlan 114  - /23 net - (10.10.114.something).  My thinking is that the proxy-IP's will be on vlan 114, and the VIP will be vlan 32.  Will that allow the arx to access the filers and retrieve content?  The netapps do not have interfaces on vlan 32 - only 114, and at some point we're going to make 114 a non-routable network so I want to make sure that the ARX will be able to communicate to the filers using the 114 addresses.   
&nbsp;  
&nbsp; Is this how it works?

jim_mccarron_44 · Answer

Its not so easy to follow without a diagram. A few questions.... 
&nbsp;  
&nbsp; Which VLAN will each channel be in? Is Channel1, going to be in VLAN32? and channel 2 in VLAN 114? If so then this is what we call a dual VLAN setup... with Proxy IP addresses in one subnet, and VIPs in another. 
&nbsp; You need to ensure that the proxy IP addresses are routable, as they will be used to talk to any authentication services (domain controllers for CIFS, and NIS servers for NFS). Management IP addresses are used for things like gateway monitoring and communication to the Quorum disk (for redundancy)... you don't need separate VLANs for in-band management. If you make the 114 net non-routable, then you could end up breaking authentication. You'll need to at least allow routing for the proxy IP addresses on the ARX to reach outside resources, and external authentication resources will need to be able to communicate back to the proxy IP addresses.  
&nbsp;  
&nbsp; I don't understand the comment: "2 ports in-band management", your channels should be your "in-band" ports, so Management IP addresses should be assigned to each VLAN, in addition to you MIP's and VIP's.

derek_murphy_38 · Answer

agreed re: diagram - working on that still. 
&nbsp;  
&nbsp; My questions are also stemming from taking the admin class about 4 months ago, and trying to remember everything we covered now - so certain things like the in-band management, I've simply forgot how they work.  Let me try to clarify. 
&nbsp;  
&nbsp; My original idea was:  (which now with inband management being in the channels).. 
&nbsp; arx1: gbe1/1 - gbe 1/4 - cabled into core switch 1 
&nbsp; arx1: gbe1/5 - gbe 1/8 - cabled into core switch 2 
&nbsp; arx1: gbe1/9 - gbe 1/10 - heartbeat 
&nbsp; arx1: gbe1/11 - gbe 1/12 - inband management 
&nbsp;  
&nbsp; arx2: gbe1/1 - gbe 1/4 - cabled into core switch 1 
&nbsp; arx2: gbe1/5 - gbe 1/8 - cabled into core switch 2 
&nbsp; arx2: gbe1/9 - gbe 1/10 - heartbeat 
&nbsp; arx2: gbe1/11 - gbe 1/12 - inband management 
&nbsp;  
&nbsp; Now it seems like it would look more like.. 
&nbsp; arx1: gbe1/1 - gbe 1/5 - cabled into core switch 1 
&nbsp; arx1: gbe1/6 - gbe 1/10 - cabled into core switch 2 
&nbsp; arx1: gbe1/11 - gbe 1/12 - heartbeat 
&nbsp;  
&nbsp; arx2: gbe1/1 - gbe 1/5 - cabled into core switch 1 
&nbsp; arx2: gbe1/6 - gbe 1/10 - cabled into core switch 2 
&nbsp; arx2: gbe1/11 - gbe 1/12 - heartbeat 
&nbsp;  
&nbsp; with ports 1 - 10 on each switch tagged with vlan 32 and 114. 
&nbsp;  
&nbsp; From a client getting data perspective..  we'll have the following: 
&nbsp;  
&nbsp; clients = many vlans -&gt;  files.domain.com vlan 32 -&gt; netapps vlan 114 
&nbsp;  
&nbsp; clients are all over the world, in different offices, on many different vlans.  They are going to access all files over files.domain.com - 10.10.32.50 - vlan 32 for example. 
&nbsp;  
&nbsp; The arx will be serving data from the following: 
&nbsp;  
&nbsp; netapp1 - vlan 114 - 10.10.114.20 
&nbsp; netapp2 - vlan 114 - 10.10.114.21 
&nbsp;  
&nbsp; Clients should not be allowed to go to the netapp directly for access.  We will configure the shares to only allow arx access, but from a routing standpoint, the architects in the group want to make the storage network non-routable someday in the future allowing only machines that have an IP on the 10.10.114 network to send and receive to the netapps. 
&nbsp;  
&nbsp; My hope is to have the arx be able to access content on the netapps, via the 10.10.114 vlan while serving content to the clients on the 10.10.32 vlan (all the same channel of ports on the ARX).  From the sound of it, it seems like this might be something that isn't possible - unless it can work via static routes to domain controllers - cifs, ldap servers - nfs (no nis only ldap for unix here), and ntp servers? 
&nbsp;  
&nbsp; Forgive me if I'm overlooking anything.  My previous experience was with a lab environment on an arx 500 so it was a much simpler setup :) 
&nbsp;  
&nbsp;  
&nbsp; My gut feeling is that it seems like the in-band management and the proxy-IP's are pretty closely related so if anything it would be proxy-ip/inband management on vlan 114, and VIP on vlan 32 (but all ports would need to carry both vlans)?   
&nbsp; Regarding any static routes..  vlan 32 is our server network, so any machine that might be a dependency of the ARX (auth etc..) would be in that network.  We also have a management network (vlan 44) that we would want the arx's 114 interfaces to be able to route to incase we shut down services on the 32 network (domain controllers for maintenance lets say..)

Forum Discussion

ARX configuration/network layout

Recent Discussions

What is the best practice for migrating from iseries to rseries?

iRule to Force Source IP to Specific Backend Node

checking the fan status on the device.

what is this serial number b1:e5:bd:8f:2x:58:xx:27 in device certificate?

How is CPU/Memory shared across Virtual Servers?

Related Content

Perl ARX Network

ARX File Change

ARX Volume Info

Perl ARX Volume

Perl ARX Schedule

ABOUT DEVCENTRAL

RESOURCES

SUPPORT

PARTNERS