F5 ARX-VE, ARX-500, ARX-4000, ARX-1500, ARX-2000 Planning Manual

...

ARX® Site Planning Guide

810-0036-00

Publication Date

Legal Notices

This manual was published on May 13, 2013.

F5 Networks, Inc. (F5) believes the information it furnishes to be accurate and reliable. However, F5 assumes no responsibility for the use of this information, nor any infringement of patents or other rights of third parties which may result from its use. No license is granted by implication or otherwise under any patent, copyright, or other intellectual property right of F5 except as specifically described by applicable user licenses. F5 reserves the right to change specifications at any time without notice.

Trademarks

Access Policy Manager, Advanced Client Authentication, Advanced Routing, APM, Application Security Manager, ARX, AskF5, ASM, BIG-IP, BIG-IQ, Cloud Extender, CloudFucious, Cloud Manager, Clustered Multiprocessing, CMP, COHESION, Data Manager, DevCentral, DevCentral [DESIGN], DNS Express, DSC, DSI, Edge Client, Edge Gateway, Edge Portal, ELEVATE, EM, Enterprise Manager, ENGAGE, F5, F5 [DESIGN], F5 Management Pack, F5 Networks, F5 World, Fast Application Proxy, Fast Cache, FirePass, Global Traffic Manager, GTM, GUARDIAN, IBR, Intelligent Browser Referencing, Intelligent Compression, IPv6 Gateway, iApps, iControl, iHealth, iQuery, iRules, iRules OnDemand, iSession, L7 Rate Shaping, LC, Link Controller, Local Traffic Manager, LTM, Message Security Manager, MSM, OneConnect, OpenBloX, OpenBloX [DESIGN], Packet Velocity, Policy Enforcement Manager, PEM, Protocol Security Manager, PSM, Real Traffic Policy Builder, Rosetta Diameter Gateway, ScaleN, Signaling Delivery Controller, SDC, SSL Acceleration, StrongBox, SuperVIP, SYN Check, TCP Express, TDR, TMOS, Traffic Management Operating System, Traffix Diameter Load Balancer, Traffix Systems, Traffix Systems (DESIGN), Transparent Data Reduction, UNITY, VAULT, VIPRION, vCMP, virtual Clustered Multiprocessing, WA, WAN Optimization Manager, WebAccelerator, WOM, and ZoneRunner, are trademarks or service marks of F5 Networks, Inc., in the U.S. and other countries, and may not be used without F5's express written consent.

All other product and company names herein may be trademarks of their respective owners.

Patents

This product may be protected by U.S. Patents 7,877,511; 7,958,347. This list is believed to be current as of May 13, 2013.

Export Regulation Notice

This product may include cryptographic software. Under the Export Administration Act, the United States government may consider it a criminal offense to export this product from the United States.

RF Interference Warning

This is a Class A product. In a domestic environment this product may cause radio interference, in which case the user may be required to take adequate measures.

FCC Compliance

This equipment has been tested and found to comply with the limits for a Class A digital device pursuant to Part 15 of FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This unit generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case the user, at his own expense, will be required to take whatever measures may be required to correct the interference.

Any modifications to this device, unless expressly approved by the manufacturer, can void the user's authority to operate this equipment under part 15 of the FCC rules.

ARX Site Planning Guide iii

Canadian Regulatory Compliance

This Class A digital apparatus complies with Canadian ICES-003.

Standards Compliance

This product conforms to the IEC, European Union, ANSI/UL and Canadian CSA standards applicable to Information Technology products at the time of manufacture.

Acknowledgments

This product includes software from several third-party vendors. Each vendor is listed below with the applicable copyright.

Export of this software from the United States of America may require a specific license from the United States Government. It is the responsibility of any person or organization contemplating export to obtain such a license before exporting.

Unless otherwise noted, the companies, organizations, products, domain names, email addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred.

Revision History

October 2005 - Rev A

November 2005 - Rev B - hardware correction

March 2006 - Rev C - Software Release 2.3

August 2006 - Rev D, updates for Software Release 2.4

September 2006 - Rev E, added more configuration limits

September 2006 - Rev F, updates for Software Release 2.4.2

March 2007 - Rev G, added best practices for more filer types; updates for Release 2.5

May 2007 - Rev H, updates for Release 2.5.1

December 2007 - Rev J, clarification of Metadata-share best practices

February 2008 - Rev K, clarification of Console-cable pinouts for Release 2.7.1

March 2008 - Rev L, conversion to F5 format for Release 3.1.0

June 2008 - Rev M, more namespace/volume limits for Release 3.2.0

June 2008 - Rev N, updates for the ARX

October 2008 - Rev P, re-brand the OS and revise power specifications for ARX4000

June 2009 - Rev Q, update filer/server instructions

November 2009 - Rev R, add ARX

January 2010 - Rev S, more updates for Release 5.01.000

March 2010 - Rev T, updates for Software Release 5.01.005

September 2010 - Rev U, add updates for Release 5.02.000

4000 chassis, and for Release 4.0.0

2000 and other updates for Release 5.01.000

January 2011 - Rev V, add updates for Release 5.03.000

June 2011 - Rev W, add updates for Release 6.00.000

September 2011 - Rev X, add updates for Release 6.01.000

October 2011 – Rev Y, refer to licensed limits

July 2012 - Rev Z, add updates for Release 6.02.000

October 2012 - Rev AA, add updates for Release 6.03.000

June 2013 - Rev AB, add updates for Release 6.04.000

ARX Site Planning Guide v

Site Planning

This manual describes network and environmental considerations for

installing an Adaptive Resource Switch (ARX prepare for adding an ARX to your network.

). Use this document to

Concepts and Terminology

clients

servers

back end front end

ARX (proxy)

The ARX acts as a resource proxy between the current clients and servers on your network. The switch terminates client requests, determines the correct server to process the request, and then originates a new request to the server. Messages in the reverse direction, from servers to clients, also terminate and restart at the ARX. The clients are said to be at the front end of the ARX, and the servers are said to be at the back end. As you plan to add a switch to your network, it is helpful to remember the sharp division between the switch’s front-end and back-end processing.

The following figure illustrates this sharp division.

Figure 1.1 ARX architecture showing front end versus backend

Concepts and Terminology

Platforms and Modules

ARX Site Planning Guide 1 - 3

You can purchase any of the following ARX platforms:

• Single-port ARX-VE (a virtual appliance)

• Single-port ARX-500

• 8-port ARX-1500

• 12-port ARX-2000

• 4-port ARX-2500, with 2 additional 10-Gigabit ports

• 12-port ARX-4000, with 2 additional 10-Gigabit ports

This document is relevant to all of the above platforms.

Chapter 1 Site Planning

Namespaces

You can configure one or more namespaces for your front-end clients. Each namespace is a collection of virtual file systems, called volumes, under a single authentication domain. A volume is a collection of shares (or exports) hosted on the back-end file servers.

Selecting a Network Topology

You can deploy the ARX in one of the following network topologies:

• One-armed proxy. The ARX uses a single logical connection to reach all clients and servers.

• Multiple subnet. The ARX terminates one or more client subnets and a separate server subnet.

The following subsections describe each of these topologies.

One-Armed Proxy Topology

In a one-armed proxy topology, the ARX connects to a single IP subnet on a single VLAN. All of the switch’s connectivity to clients and servers goes through this single subnet/VLAN. The connection is typically through a link-aggregation channel.

One-Armed Proxy: Before Installing an ARX

Figure 1.2 shows clients and servers on the same VLAN and subnet before the introduction of the ARX. The router connects the LAN to additional client and server subnets, perhaps on other campuses.

1 - 4

Selecting a Network Topology

servers

Figure 1.2 Clients and servers on the same VLAN before using the ARX.

VLAN 25, IP subnet 192.168.25

DASclients NAS

One-Armed Proxy: After Installing an ARX

The ARX has a single physical connection to the client/server subnet. On the switch, you configure the same subnet and VLAN for both front-end clients and back-end servers. You can also add static routes to additional client and/or server subnets.

Figure 1.3 shows clients and servers after cutting in an ARX.

ARX Site Planning Guide 1 - 5

Chapter 1

DASclients NAS

servers

VLAN 25, IP subnet 192.168.25.x

Site Planning

Figure 1.3 Clients and servers on a VLAN after cutting in an ARX.

Multiple Subnet Topology

A multiple subnet deployment divides clients and servers into multiple IP subnets. You can define multiple subnets, static routes, and default routes on the ARX to reach any number of subnets at the front end or back end.

Multiple Subnet: Before Installing an ARX

Figure 1.4 shows clients and servers on separate VLANs and subnets, with a router connecting the two subnets.

1 - 6

Selecting a Network Topology

Figure 1.4 Clients and servers on separate VLANs and subnets

servers

192.168.25.x

172.100.90.x

clients

Multiple Subnet: After Installing an ARX

As shown in Figure 1.5, the ARX has a separate connection to the client subnet and the server subnet in a multiple subnet topology. The switch serves as a proxy for CIFS and/or NFS transactions between the clients and servers.

As a proxy, the ARX has separate transactions with clients on its front end and servers on its back end. In this topology, the ARX does not cause looping.

ARX Site Planning Guide 1 - 7

Chapter 1

Note

Site Planning

Figure 1.5 ARX as proxy for CIFS and/or NFS transactions

servers

192.168.25.x

back en front en

ARX (prox

172.100.90.x

clients

Allocating IP Addresses

As a resource proxy with distributed processors, the ARX requires several IP addresses to communicate with front-end clients and its back-end servers. Every network processor on the switch requires its own address to terminate and originate transactions with back-end servers. These IP addresses are called proxy IP addresses.

Communication to client subnets is less distributed: a minimum of one IP address is required per namespace to handle client requests. The client-side IP addresses are called virtual IPs, or VIPs.

The ARX also requires one or more management IP addresses to load new software images. The switch has one out-of-band management interface, and you can configure one in-band interface for each VLAN. The in-band interfaces can also be used to connect one ARX to another in a Resilient Overlay Network (RON).

At least one in-band management interface is required for any redundant switch pair.

The Server Subnet and Proxy IP Addresses

The proxy IP addresses must reside on a single server subnet. If you have multiple server subnets in your current network, you can configure static routes to the remote subnets (through a router on a local server subnet). The

1 - 8

Allocating IP Addresses

chosen server subnet must have enough address space for one proxy IP address per network processor. The number of network processors varies for each platform type. The following table shows the number of proxy IP addresses for each platform type.

Table 1.1 Required number of proxy IP addresses and platform types

Number of Proxy IPs Required Platform Type

12 ARX-4000

3ARX-2500

4ARX-2000

2ARX-1500

1 ARX-500 or ARX-VE

In any chassis type, the CLI issues a warning if insufficient proxy IP addresses have been defined.

Adding Proxy IP Addresses to Domain Name Servers

During an NFS mount, some back-end servers perform domain name server (DNS) reverse-lookups against remote NFS clients. This is designed as an authentication mechanism. To prevent such file servers from denying access to the proxy IP addresses, add the proxy IP addresses to your DNS configuration.

Adding Virtual IP Addresses

Clients access ARX storage through a unique virtual IP address (VIP) or VIPs. All VIPs can reside on a single client subnet or they can be divided among several client subnets. Any client must be able to reach its respective VIP. The ARX can send responses back to clients through a client subnet, a static route, or a default route.

ARX Site Planning Guide 1 - 9

Chapter 1

Note

Site Planning

Configuring Management IP Addresses

You can configure in-band management interfaces, one per configured VLAN. At least one such interface is required for many installations – and adding at least one in-band management interface is strongly recommended in any case.

◆ A switch in a Resilient Overlay Network (RON) of switches requires at

least one in-band management address. A RON is a network of IP tunnels that connects multiple ARXes together. Each tunnel requires an in-band IP address as an endpoint. You can re-use the same in-band management IP for multiple RON tunnels, but at least one is required.

◆ Redundant switches also require at least one in-band management

interface to communicate with shared, external resources (the quorum disk).

The ARX also has an interface for out-of-band management (typically labeled MGMT) on its front panel. This interface is designed for installations with discrete management networks. It must have an IP address outside of the server subnet or any of the client subnets.

ARX-VE does not offer out-of-band management.

Ports Required by the ARX

The ARX is assumed to operate in a three-tiered network in a large data center. The first tier is core routers that provide connectivity to a campus or WAN. The second tier has redundant distribution switches that distribute all data center traffic between the access switches; the access switches constitute the third tier of the network. All LAN clients and back-end file servers connect to the access switches. Through the access switches and distribution switches, LAN clients connect to all back-end servers/storage, to one another, and to the WAN. Figure 1.6 shows a sample network.

1 - 10

Figure 1.6 Sample Network

L2 switch

WAN/campus

core routers

access switches

clients

back-end filers and servers

distribution switches

L2 switch

Allocating IP Addresses

The sample network has redundant ARX devices connected at each of the distribution switches. Physically, this is a one-armed connection; conceptually, the ARX has clients in front and file servers in back.

The network file servers are the storage behind the (front-end) services of the ARX. The servers can be heterogeneous: NAS devices and file servers need only support CIFS or NFS.

Table 1.2 lists the ports required by the ARX to communicate with its

authentication services, back-end storage, and front-end client services. If you plan to operate in a secure environment, these ports must be opened on fire walls in order for the ARX to function properly.

All client/server data is on the inband network. The inband network enables clients and servers to talk to the ARX. The higher layer protocols use the inband network. If traps and email home are configured, they also use the inband network.

The out-of-band network is used to connect to the CLI or the GUI for purposes of querying or configuring the ARX.

There is a third network (heartbeat) between the two ARX devices in a high-availability configuration that is used to pass redundancy information between the switches.

ARX Site Planning Guide 1 - 11

Chapter 1 Site Planning

Table 1.2 Ports Required by the ARX

Inbound

Port Service/Protocol

ARX Management

161 SNMP agent for

polling UDP

162 SNMP traps TCP/UDP

22 SSH TCP

23 TELNET TCP

443 HTTPS TCP

80 HTTP TCP

514 SYSLOG UDP If External Syslog is used.

25 SMTP TCP

139 MMC TCP

VIP | XIP | MGMT

✓

✓✓

✓

✓✓

Outbound VIP | XIP | MGMT

✓

Comment

Disabled by default.

Disabled by default. The port is configurable.

Enabled by default.

Disabled by default.

GUI enabled by default.

GUI disabled by default.

For Email Home.

49803 RON UDP

20/21 FTP TCP

SCP

123 NTP TCP/UDP

1812 RADIUS

NFS Proxy

111 rpcbind TCP/UDP

2049 server V2 UDP/TCP

2049 server V3 UDP

2049 locked TCP/UDP

635 mountd TCP/UDP

✓✓

✓

Inband only.

Passive mode client only, no server.

Client, no server.

Disabled by default.

✓✓

1 - 12

Table 1.2 Ports Required by the ARX (Continued)

Allocating IP Addresses

Port Service/Protocol

637 nlockmgr TCPUDP

638 status TCP/UDP

CIFS Proxy/SMB

445 CIFS (SMB) Server

TCP

139 CIFS (SMB) Server

TCP

CIFS (SMB) over NETBIOS

CIFS Authentication/Other

53 DNS TCP/UDP

389 LDAP TCP/UDP

25805 NTLM agent default

TCP

Inbound VIP | XIP | MGMT

Outbound VIP | XIP | MGMT

Comment

✓✓

Preferred port.

✓✓

Queries.

✓✓

Default, port is configurable.

464 lc passwd

137/138 WINS UDP

88 Kerberos TCP/UDP

137, 138 NetBIOS TCP/UDP

445 Microsoft Directory

Services TCP

NFS Authentication (NIS)

NIS UDP/TCP

DNS UDP/TCP

Snapshot Management to File Servers

514 RSH (remote shell)

TCP

22 SSH TCP

✓✓

✓✓✓

UDP and TCP

Name service

✓✓

Client, no server. Outbound only.

✓

Enabled by default.

ARX Site Planning Guide 1 - 13

Chapter 1 Site Planning

Table 1.2 Ports Required by the ARX (Continued)

Port Service/Protocol

598, 5986

High-Availability (HA)

49800 “rendezvous”

API (new in 5.2.0)

83 HTTP-API

843 HTTPS-API

WINRM (Windows Remote Management) TCP

Using NTP

Inbound VIP | XIP | MGMT

✓

Outbound VIP | XIP | MGMT

✓

Comment

To support time-based policies, the clock on the ARX must be consistent with the clock in its back-end servers. For example, an accurate clock is needed to determine when to trigger age-based file migration or replication. Accurate time is also important because the ARX keeps track of time-based file attributes, such as last-modified time and create time.

In a redundant pair of ARX devices, time consistency between the redundant peers is vital. A redundant peer may trigger a failover if an improper clock setting makes a heartbeat appear to be out-of-date.

For these reasons and others, we strongly recommend using two or more NTP servers for the servers, clients, and the ARX devices.

Automatically Discovering Your File Servers

Prior to installing an ARX, best practices recommend using F5 Data Manager, a web-based application that can give you a detailed understanding of your unique file storage configuration, contents, structure, and usage. With this understanding, you can identify and apply data management policies to create an efficient and cost-effective storage environment.

Data Manager can give you a snapshot of your current environment as it exists today, starting with file server discovery.

1 - 14

+ 44 hidden pages

F5 ARX-VE, ARX-500, ARX-4000, ARX-1500, ARX-2000 Planning Manual

Specifications and Main Features

Frequently Asked Questions

User Manual