The private Ethernet network for metadata is one of the more obscure parts of an Xsan. The goal is to create a very low-latency communications channel for SAN metadata. In other words, when a client clicks "Capture Now," it needs to ask the metadata controller for the location of free space on the SAN. You want the metadata controller to return its response with no delay.

See below for some tips about this network.

Private network tips

Your private network should following these guidelines:

• You should use gigabit Ethernet PCI cards, a gigabit Ethernet switch, and good quality (Cat-5e or Cat-6) cabling.
• In the Network preference pane's "Network Port Configuration," the private network interface should be listed below the public network interface. This sets the public interface as the default.
• When configuring the private interface's TCP/IP parameters, only fill in IP Address and Subnet Mask. Leave the other fields blank.
• Choose an IP address range that is unrouted and unassigned to a DNS domain (see below).

Choosing your IP range

The three IP subnets listed in the Xsan Admin Guide are good starting ranges for your IP range, but that's only part of the story.

Choosing which one is basically a matter of taste, but you must make sure:

• The range is not used by any other network you can access
• Your DNS servers do not include records for the range

The address range 192.168.1.1 - 192.168.1.254 is often used by consumer router manufacturers. If this is the range you use on your network to connect to the Internet, you must not use it for your metadata network. Choose another range.

DNS is a trickier issue to diagnose. Last week, for example, I was setting up a SAN for a small workgroup in a large corporation. Following the instructions in the Xsan guide, we set the private network to use the 192.168.1.x with a 255.255.255.0 subnet mask. We found that Xsan Admin was working extremely slowly. Every tab change or refresh took minutes to complete.

With the proper Terminal command, we were able to determine that the corporate IT department was already using the range 192.168 for another division in its network. Xsan Admin was trying the (incorrect) DNS name for the server for each transaction, timing out, and falling back to the IP address. By changing the range of the private network to 10.17.17.1 with a 255.255.255.0 mask, we were able to eliminate the timeouts without modifying DNS. We chose the "17.17" randomly, but confirmed that it was not in use elsewhere on the corporate network.

About the subnet mask

The subnet mask tells the computer how big the IP range is. A subnet mask of 255.255.255.0 is equivalent to a range of x.x.x.1 - x.x.x.254. This mask is appropriate for almost all private metadata networks.

Useful Terminal commands

dig +short -x 192.168.1.1

This command queries your DNS servers to see if an address has an associated name. If there is no name, then no result is returned. For example, dig +short -x 17.254.3.183 returns apple.com.. (Although Xsan can work with IPs that have associated DNS addresses, the DNS records must be configured perfectly. It is far easier just to keep DNS out of the picture.)

sudo lsof -ni4 | grep fsm

When run from the active metadata controller, shows the IP addresses of all connected Xsan clients. This may be useful to determine that all clients are connecting via the correct network. If you see any addresses in your public range, you have routing problems.