JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle ZFS Storage Appliance Administration Guide
search filter icon
search icon

Document Information

Preface

1.  Introduction

2.  Status

3.  Configuration

Configuration

Introduction

Initial

Initial Configuration

Prerequisites

Summary

BUI

Configuring Management Port

CLI

Performing Initial Configuration with the CLI

Network

Network Configuration

Devices

Datalinks

Interfaces

IP MultiPathing (IPMP)

Performance and Availability

Routing

Routing Entries

Routing Properties

BUI

Configuration

Addresses

Routing

CLI

Tasks

BUI

CLI

Storage

Introduction

Configure

Configuration Rules and Guidelines

Verification

Allocation on SAS-2 Systems

Profile Configuration

Import

Add

Unconfig

Scrub

Tasks

BUI

SAN

SAN

Terminology

Targets and Initiators

Target and Initiator Groups

BUI

CLI

Terms

SAN Terminology

FC

Fibre Channel

Target Configuration

Clustering Considerations

Initiator Configuration

Clustering Considerations

Performance Considerations

Troubleshooting

Queue Overruns

Link-level Issues

BUI

Changing modes of FC ports

Viewing discovered FC ports

Creating FC Initiator Groups

Associating a LUN with an FC initiator group

CLI

Changing modes of FC ports

Viewing discovered FC ports

Creating FC Initiator Groups

Associating a LUN with an FC initiator group

Scripting Aliases for Initiators and Initiator Groups

FCMPxIO

Configuring FC Client Multipathing

Tasks

FCMPxIO Tasks

Configuring Solaris Initiators

Configuring Windows Initiators

Windows Tunables - Microsoft DSM Details

Configuring Linux Initiators

Configuring VMware ESX Initiators

Troubleshooting

See Also

iSCSI

Introduction

Target Configuration

Clustering Considerations

Initiator Configuration

Planning Client Configuration

Solaris iSCSI/iSER and MPxIO Considerations

Troubleshooting

Observing Performance

Tasks

iSCSI Tasks

CLI

Adding an iSCSI target with an auto-generated IQN

Adding an iSCSI target with a specific IQN and RADIUS authentication

Adding an iSCSI initiator which uses CHAP authentication

Adding an iSCSI target group

Adding an iSCSI initiator group

SRP

Introduction

Target configuration

Clustering Considerations

Initiator configuration

Observing Performance

Multipathing Considerations

VMWare 4.0

Path Selection Plugin (psp)

Storage Array Type Plugin (satp)

VMWare ESX 4.0 Issues

Tasks

SRP Tasks

CLI

Users

Introduction

Roles

Authorizations

Properties

Users

Roles

BUI

CLI

Tasks

BUI

CLI

Generic

Preferences

Introduction

BUI

CLI

SSH Public Keys

Alerts

Introduction

Actions

Send Email

Send SNMP trap

Send Syslog Message

Resume/Suspend Dataset

Resume/Suspend Worksheet

Execute Workflow

Threshold Alerts

BUI

CLI

Tasks

BUI

Cluster

Clustering

Features and Benefits

Drawbacks

Terminology

Subsystem Design

Cluster Interconnect I/O

Resource Management Concepts

Takeover and Failback

Configuration Changes in a Clustered Environment

Clustering Considerations for Storage

Clustering Considerations for Networking

Clustering Considerations for Infiniband

Redundant Path Scenarios

Preventing 'Split-Brain' Conditions

Estimating and Reducing Takeover Impact

Tasks

Cluster Tasks

Setup Procedure

Shutting Down a Clustered Configuration

Node Cabling

JBOD Cabling

BUI

Tasks

Cluster Tasks

Unconfiguring Clustering

4.  Services

5.  Shares

6.  Integration

Glossary

Network

image:Network configuration

Configuring networking

Network Configuration

The Networking Configuration features permit you to create a variety of advanced networking setups out of your physical network ports, including link-aggregations, virtual NICs (VNICs), virtual LANs (VLANs), and multipathing groups. You can then define any number of IPv4 and IPv6 addresses for these abstractions, for use in connecting to the various data services on the system.

There are four components to a system's network configuration:

In this model, network devices represent the available hardware - they have no configurable settings. Datalinks are a layer 2 entity, and must be created to apply settings such as LACP to these network devices. Interfaces are a layer 3 entity containing the IP settings, which they make available via a datalink. This model has separated network interface settings into two parts - datalinks for layer 2 settings, and interfaces for layer 3 settings.

An example of a single IP address on a single port (common configuration) is:

Devices
Datalink
Interface
igb0
datalink1
deimos (192.168.2.80/22)

The following configuration is for a 3-way link aggregation:

Devices
Datalink
Interface
igb1, igb2, igb3
aggr1 (LACP aggregation)
phobos (192.168.2.81/22)

The datalink entity (which we named "aggr1") groups the network devices in a configurable way (LACP aggregation policy). The interface entity (which we named "phobos") provides configurable IP address settings, which it makes available on the network via the datalink. The network devices (named "igb1", "igb2", ..., by the system) have no direct settings.

Datalinks are required to complete the network configuration, whether they apply specific settings to the network devices or not.

Devices

These are created by the system to represent the available network or InfiniBand ports. They have no configuration settings of their own.

Datalinks

These manage devices, and are used by interfaces. They support:

Note: VNIC-based and VLAN-based datalinks cannot share the same VLAN ID.

The following datalink settings are available:

Property
Description
Name
Use the defined custom name. For example: "internal", "external", "adminnet", etc.
Speed
Use the defined speed. Valid values are auto, 10, 100, 1000 and 10000, representing autonegotiation, forced 10Mbit/sec, forced 100Mbit/sec, forced 1Gbit/sec and forced 10Gbit/sec. Speed and duplex must be either both forced to specific values or both set to auto negotiate. Not all networking devices support forcing to all possible speed/duplex combinations. Disabling auto negotiation is strongly discouraged. However, if the switch has auto negotiation disabled, it may be necessary to force speed (and duplex) to ensure the the datalink runs at the expected speed and duplex.
Duplex
Use the defined transmission direction. Valid CLI values are auto, half, and full, representing autonegotiation, half- and full-duplex respectively. Speed and duplex must be either both forced to specific values or both set to autonegotiate.
VLAN
Use VLAN headers.
VLAN ID
Use the defined VLAN identifier; optional for VNICs.
VNIC
Use a VNIC.
MTU
Use the defined maximum transmission unit (MTU) size. The default MTU is 1500 bytes. Specify a lower MTU (minimum 1280) to leave packet headroom (for example, for tunneling protocols). Specify a larger MTU (maximum 9000) to improve network performance. All systems and switches on the same LAN must be configured with the chosen MTU. After the MTU value is set and the new network configuration is committed to the system, you can return to the network screen and view the datalink status to see the exact MTU value in bytes that was selected. Note that a VLAN or VNIC cannot be configured with an MTU value larger than that of the underlying datalink.
LACP Aggregation
Use multiple network device LACP aggregation.
LACP Policy
Use the defined LACP policy for selecting an outbound port. L2 hashes the source and destination MAC address; L3 uses the source and destination IP address; L4 uses the source and destination transport level port
LACP Mode
Use the defined LACP communication mode. Active mode will send and receive LACP messages to negotiate connections and monitor the link status. Passive mode will listen for LACP messages only. Off mode will use the aggregated link but not detect link failure or switch configuration changes. Some network switch configurations, including Cisco Etherchannel, do not use the LACP protocol: the LACP mode should be set to "off" when using non-LACP aggregation in your network.
LACP Timer
Use the defined interval between LACP messages for Active mode.
IB Partition
Use IB Partitions.
Partition Key
Use the partition (fabric domain) in which the underlying port device is a member. The partition key (pkey) is found on and configured by the subnet manager. The pkey may be defined before configuring the subnet manager but the datalink will remain "down" until the subnet partition has been properly configured with the port GUID as a member. It is important to keep partition membership for HCA ports consistent with IPMP and clustering rules on the subnet manager.
IB Link Mode
Use the defined IB Link Mode. There are two modes: Unreliable Datagram and Connected. Unreliable Datagram lets a local queue pair communicate with multiple other queue pairs on any host and messages are communicated unacknowledged at the IB layer. Unreliable Datagram mode uses an MTU of 2044. Connected mode uses IB queue pairs and dedicates a local queue pair to communication with a dedicated remote queue pair. Connected mode uses an MTU of 65520 and can provides higher throughput than Unreliable Datagram.

Interfaces

These configure IP addresses via datalinks. They support:

The following interface settings are available:

Property
Description
Name
Custom name for the interface
Allow Administration
Allow connections to the appliance administration BUI or CLI over this interface. If your network environment included a separate administration network, this could be enabled for the administration network only to improve security
Enable Interface
Enable this interface to be used for IP traffic. If an interface is disabled, the appliance will no longer send or receive IP traffic over it, or make use of any IP addresses configured on it. At present, disabling an active IP interface in an IPMP group will not trigger activation of a standby interface.
IPv4 Configure with
Either "Static Address List" manually entered, or "DHCP" for dynamically requested
IPv4 Address/Mask
One or more IPv4 addresses in CIDR notation (192.168.1.1/24)
IPv6 Configure with
Either "Static Address List" manually entered, or "IPv6 AutoConfiguration" to use automatically generated link-local address (and site-local if an IPv6 router responds)
IPv6 Address/Mask
One or more IPv6 addresses in CIDR notation (1080::8:800:200C:417A/32)
IP MultiPathing Group
Configure IP multipathing, where a pool of datalinks can be used for redundancy

IP MultiPathing (IPMP)

IP MultiPathing groups are used to provide IP addresses that will remain available in the event of an IP interface failure (such as a physical wire disconnection or a failure of the connection between a network device and its switch) or in the event of a path failure between the system and its network gateways. The system detects failures by monitoring the IP interface's underlying datalink for link-up and link-down notifications, and optionally by probing using test addresses that can be assigned to each IP interface in the group, described below. Any number of IP interfaces can be placed into an IPMP group so long as they are all on the same link (LAN, IB partition, or VLAN), and any number of highly-available addresses can be assigned to an IPMP group.

Each IP interface in an IPMP group is designated either <i>active</i> or <i>standby</i>:

Multiple active and standby IP interfaces can be configured, but each IPMP group must be configured with at least one active IP interface. IPMP will strive to activate as many standbys as necessary to preserve the configured number of active interfaces. For example, if an IPMP group is configured with two active interfaces and two standby interfaces and all interfaces are functioning correctly, only the two active interfaces will be used to send and receive data. If an active interface fails, one of the standby interfaces will be activated. If the other active interface fails (or the activated standby fails), the second standby interface will be activated. If the active interfaces are subsequently repaired, the standby interfaces will again be deactivated.

IP interface failures can be discovered by either link-based detection or probe-based detection (i.e., a test address is configured).

If probe-based failure detection is enabled on an IP interface, the system will determine which target systems to probe dynamically. First, the routing table will be scanned for gateways (routers) on the same subnet as the IP interface's test address and up to five will be selected. If no gateways on the same subnet were found, the system will send a multicast ICMP probe (to 224.0.01. for IPv4 or ff02::1 for IPv6) and select the first five systems on the same subnet that respond. Therefore, for network failure detection and repair using IPMP, you should be sure that at least one neighbor on each link or the default gateway responds to ICMP echo requests. IPMP works with both IPv4 and IPv6 address configurations. In the case of IPv6, the interface's link-local address is used as the test address.

The system will probe selected target systems in round-robin fashion. If five consecutive probes are unanswered, the IP interface will be considered failed. Conversely, if ten consecutive probes are answered, the system will consider a previously failed IP interface as repaired. You can set the system's IPMP probe failure detection time from the IPMP screen. This time indirectly controls the probing rate and the repair interval -- for instance, a failure detection time of 10 seconds means that the system will send probes at roughly two second intervals and that the system will need 20 seconds to detect a probe-based interface repair. You cannot directly control the system's selected targeted systems, though it can be indirectly controlled through the routing table.

The system will monitor the routing table and automatically adjust its selected target systems as necessary. For instance, if the system using multicast-discovered targets but a route is subsequently added that has a gateway on the same subnet as the IP interface's test address, the system will automatically switch to probing the gateway. Similarly, if multicast-discovered targets are being probed, the system will periodically refresh its set of chosen targets (e.g., because some previously selected targets have become unresponsive).

Step-by-step instructions for building IPMP groups can be found in the Tasks section below.

Performance and Availability

IPMP and link aggregation are different technologies available in the appliance to achieve improved network performance as well as maintain network availability. In general, you deploy link aggregation to obtain better network performance, while you use IPMP to ensure high availability. The two technologies complement each other and can be deployed together to provide the combined benefits of network performance and availability.

In link aggregations, incoming traffic is spread over the multiple links that comprise the aggregation. Thus, networking performance is enhanced as more NICs are installed to add links to the aggregation. IPMP's traffic uses the IPMP interface's data addresses as they are bound to the available active interfaces. If, for example, all the data traffic is flowing between only two IP addresses but not necessarily over the same connection, then adding more NICs will not improve performance with IPMP because only two IP addresses remain usable.

Performance can be affected by the number of VNICs/VLANs configured on a datalink for a given device, as well as by using a VLAN ID. Configuring multiple VNICs over a given device may impact the performance of all datalinks over that device by up to five percent, even when VNICs are not in use. If more than eight VNICs/VLANs are configured over a given datalink, performance may degrade significantly. Also, if a datalink uses a VLAN ID, all datalink performance for that device may be impacted by an additional five percent.

Routing

The system provides a single IP routing table, consisting of a collection of routing table entries. When an IP packet needs to be sent to a given destination, the system selects the routing entry whose destination most closely matches the packet's destination address (subject to the system's multihoming policy -- see below). It then uses the information in the routing entry to determine what IP interface to send the packet on and -- if the destination is not directly reachable -- the next-hop gateway to use. If no routing entries match the destination, the packet will be dropped. If multiple routing entries tie for closest match (and are not otherwise prioritized by multihoming policy), the system will load-spread across those entries on a per-connection basis.

The system does not act as a router.

Routing Entries

The routing table is comprised of routing entries, each of which has the following fields:

Field
Description
Examples
Destination
Range of IP destination addresses (in CIDR notation) that can match the route
192.168.0.0/22
Gateway
Next hop (IP address) to send the packet to (except for "system" routes -- see below)
192.168.2.80
Family
Internet protocol
IPv4, IPv6
Type
Origin of the route
dhcp, static, system
Interface
IP interface the packet will be sent on
igb0

A routing entry with a "destination" field of 0.0.0.0/0 will match any packet (if no other route matches more precisely), and is thus known as a 'default' route. In the BUI, default routes are distinguished from non-default routes by an additional property:

Kind
Route kind
Default, Network

As above, a given packet will be sent on the IP interface specified in the routing entry's "interface" field. If an IPMP interface is specified, then one of the active IP interfaces in the IPMP group will be chosen randomly on a per-connection basis and automatically refreshed if the chosen IP interface subsequently becomes unusable. Conversely, if a given IP interface is part of an IPMP group, it cannot be specified in the "interface" field because such a route would not be highly-available.

Routing entries come from a number of different origins, as identified by the "type" field. Although the origin of a routing entry has no bearing on how it is used by the system, its origin does control if and how it can be edited or deleted. The system supports the following types of routes:

Type
Description
Static
Created and managed by the appliance administrator.
System
Created automatically by the appliance as part of enabling an IP interface. A system route will be created for each IP subnet the appliance can directly reach. Since these routes are directly reachable, the "gateway" field instead identifies the appliance's IP address on that subnet.
DHCP
Created automatically by the appliance part of enabling an IP interface that is configured to use DHCP. A DHCP route will be created for each default route provided by the DHCP server.
Dynamic
Created automatically by the appliance via the RIP and RIPng dynamic routing protocols (if enabled).

One additional type identifies a static route that cannot currently be used:

Inactive
Previously created static route associated with a disabled or offline IP interface.
Routing Properties
Property
Description
Multihoming model
Controls the system policy for accepting and transmitting IP packets when multiple IP interfaces are simultaneously enabled. Allowed values are "loose" (default), "adaptive", and "strict". See the discussion below.

If a system is configured with more than one IP interface, then there may be multiple equivalent routes to a given destination, forcing the system to choose which IP interface to send a packet on. Similarly, a packet may arrive on one IP interface, but be destined to an IP address that is hosted on another IP interface. The system's behavior in such situations is determined by the selected multihoming policy. Three policies are supported:

Policy
Description
Loose
Do not enforce any binding between an IP packet and the IP interface used to send or receive it: 1) An IP packet will be accepted on an IP interface so long as its destination IP address is up on the appliance. 2) An IP packet will be transmitted over the IP interface tied to the route that most specifically matches an IP packet's destination address, without any regard for the IP addresses hosted on that IP interface. If no eligible routes exist, drop the packet.
Adaptive
Identical to loose, except prefer routes with a gateway address on the same subnet as the packet's source IP address: 1) An IP packet will be accepted on an IP interface so long as its destination IP address is up on the appliance. 2) An IP packet will be transmitted over the IP interface tied to the route that most specifically matches an IP packet's destination address. If multiple routes are equally specific, prefer routes that have a gateway address on the same subnet as the packet's source address. If no eligible routes exist, drop the packet.
Strict
Require a strict binding between an IP packet and the IP interface used to send or receive it: 1) An IP packet will be accepted on an IP interface so long as its destination IP address is up on that IP interface. 2) An IP packet will only be transmitted over an IP interface if its source IP address is up on that IP interface. To enforce this, when matching against the available routes, the appliance will ignore any routes that have gateway addresses on a different subnet from the packet's source address. If no eligible routes remain, drop the packet.

When selecting the multihoming policy, a key consideration is whether any of the appliance's IP interfaces will be dedicated to administration (for example, for dedicated BUI access) and thus accessed over a separate administration network. In particular, if a default route is created to provide remote access to the administration network, and a separate default route is created to provide remote access to storage protocols, then the default system policy of "loose" may cause the administrative default route to be used for storage traffic. By switching the policy to "adaptive" or "strict", the appliance will consider the IP address associated with the request as part of selecting the route for the reply. If no route can be found on the same IP interface, the "adaptive" policy will cause the system to use any available route, whereas the "strict" policy will cause the system to drop the packet.

BUI

When using the BUI to reconfigure networking, the system makes every effort to preserve the current networking connection to your browser. However, some network configuration changes such as deleting the specific address to which your browser is connected, will unavoidably cause the browser to lose its connection. For this reason it is recommended that you assign a particular IP address and network device for use by administrators and always leave the address configured. You can also perform particularly complex network reconfiguration tasks from the CLI over the serial console if necessary.

The following icons are used in the Configuration->Network section:

icon
description
image:Add item
Add new datalink/interface/route
image:Edit
Edit datalink/interface/route settings
image:Image
Editing disabled
image:Destroy
Destroy datalink/interface/route
image:Image
Destruction disabled
image:Move
Drag-and-drop icon
image:Active network device (lights off)
connected network port
image:Active network device
connected network port with I/O activity
image:Network device (disabled)
disconnected network port (link down, cable problem?)
image:Image
active InfiniBand port
image:Image
active InfiniBand port with I/O activity
image:Image
inactive InfiniBand port (down, init, or arm state)
image:Status: On
InfiniBand partition device is up
image:Status: Off
InfiniBand partition device is down (subnet manager problem)
image:Network datalink
network datalink
image:Network datalink VLAN
network datalink VLAN or VNIC
image:Network datalink aggregation
network datalink aggregation
image:Network datalink aggregation VLAN
network datalink aggregation VLAN or VNIC
image:Image
network datalink IB partition
image:Status: On
interface is being used to send and receive packets (either up or degraded)
image:Status: Disabled
interface has been disabled by the user
image:Status: Off
interface is offline (owned by the cluster peer)
image:Status: Warning
interface has failed or has been configured with a duplicate IP address

At top right is local navigation for Configuration, Addresses and Routing, which display alternate configuration views.

Configuration

The Configuration page is shown by default, and lists Devices, Datalinks and Interfaces, along with buttons for administration. Mouse-over an entry to expose an additional image:Move icon, and click on any entry to highlight other components that are associated with it.

The Devices list shows links status on the right, as well as an icon to reflect the state of the network port. If ports appear disconnected, check that they are plugged into the network properly.

To configure an IP address on a network devices, first create a datalink, and then create an interface to use that datalink. The image:Add item icon may be used to do both, which will display dialogs for the Datalink and Interface properties.

There is more than one way to configure a network interface. Try clicking on the image:Move icon for a device, then dragging it to the datalink table. Then drag the datalink over to the interfaces table. Other moves are possible. This can be helpful for complex configurations, where valid moves are highlighted.

Addresses

This page shows a summary table of the current network configuration, with fields:

Field
Description
Example
Network Datalink
Datalink name and detail summary
datalink1 (via igb0)
Network Interface
Interface name and details summary
IPv4 DHCP, via datalink1
Network Addresses
Addresses hosted by this interface
192.168.2.80/22
Host Names
Resolved host names for the network addresses
caji.sf.example.com

Routing

This page provides configuration of the IP routing table and associated properties, as discussed above. By default, all entries in the routing table are shown, but the table can be filtered by type by using the subnavigation bar.

CLI

Network configuration is under the configuration net, which has sub commands for devices, datalinks, interfaces, and routing. The show command can be used with each to show the current configuration:

caji:> configuration net
caji:configuration net> devices show
Devices:
DEVICE      UP     SPEED         MAC                                            
igb0 true 1000 Mbit/s 0:14:4f:9a:b9:0
igb1 true 1000 Mbit/s 0:14:4f:9a:b9:1
igb2 true 1000 Mbit/s 0:14:4f:9a:b8:fe
igb3 true 1000 Mbit/s 0:14:4f:9a:b8:ff

caji:configuration net> datalinks show Datalinks: DATALINK CLASS LINKS LABEL igb0 device igb0 datalink1 caji:configuration net> interfaces show Interfaces: INTERFACE STATE CLASS LINKS ADDRS LABEL igb0 up ip igb0 192.168.2.80/22 caji caji:configuration net> routing show Properties: multihoming = loose Routes: ROUTE DESTINATION GATEWAY INTERFACE TYPE route-000 0.0.0.0/0 192.168.1.1 igb0 dhcp route-001 192.168.0.0/22 192.168.2.142 igb0 system

Type help in each section to see the relevant commands for creating and configuring datalinks, interfaces, and routes.

The following demonstrates creating a datalink using the device command, and interface using the ip command:

caji:configuration net> datalinks 
caji:configuration net datalinks> device caji:configuration net datalinks device (uncommitted)> set links=igb1 links = igb1 (uncommitted) caji:configuration net datalinks device (uncommitted)> set label=datalink2 label = datalink2 (uncommitted) caji:configuration net datalinks device (uncommitted)> set mtu=9000 mtu = 9000 (uncommitted) caji:configuration net datalinks device (uncommitted)> commit caji:configuration net datalinks> show Datalinks: DATALINK CLASS LINKS LABEL igb0 device igb0 datalink1 igb1 device igb1 datalink2 caji:configuration net datalinks> cd .. caji:configuration net> interfaces caji:configuration net interfaces> ip caji:configuration net interfaces ip (uncommitted)> set label="caji2" label = caji2 (uncommitted) caji:configuration net interfaces ip (uncommitted)> set links=igb1
links = igb1 (uncommitted)
caji:configuration net interfaces ip (uncommitted)> set v4addrs=10.0.1.1/8 v4addrs = 10.0.1.1/8 (uncommitted) caji:configuration net interfaces ip (uncommitted)> commit caji:configuration net interfaces> show Interfaces: INTERFACE STATE CLASS LINKS ADDRS LABEL igb0 up ip igb0 192.168.2.80/22 caji igb1 up ip igb1 10.0.1.1/8 caji2

The following demonstrates creating a default route via 10.0.1.2 over the new igb1 IP interface:

caji:configuration net routing> create
caji:configuration net route (uncommitted)> set family=IPv4
                   family = IPv4 (uncommitted)
caji:configuration net route (uncommitted)> set destination=0.0.0.0
                   destination = 0.0.0.0 (uncommitted)
caji:configuration net route (uncommitted)> set mask=0
                   mask = 0 (uncommitted)
caji:configuration net route (uncommitted)> set interface=igb1
                   interface = igb1 (uncommitted)
caji:configuration net route (uncommitted)> set gateway=10.0.1.2
                   gateway = 10.0.1.2 (uncommitted)
caji:configuration net route (uncommitted)> commit

Tasks

BUI

Creating a single port interface

  1. Click the Datalinks image:Add item icon.
  2. Optionally set name and select custom MTU radio button (typing 9000 in the text box).
  3. Choose a device from the Devices list.
  4. Click "APPLY". The datalink will appear in the Datalinks list.
  5. Click the Interface image:Add item icon.
  6. Set desired properties, and choose the datalink previously created.
  7. Click "APPLY". The interface will appear in the Interfaces list.
  8. The running appliance network configuration has not yet changed. When you are finished configuring interfaces, click "APPLY" at the top to commit the configuration.

Modifying an interface

  1. Click the edit icon on either the datalink or the interface.
  2. Change settings to desired values.
  3. Click "APPLY" on the dialog.
  4. Click "APPLY" at the top of the page to commit the configuration.

Creating a single port interface, drag-and-drop

  1. Mouse over a device and click the drag-and-drop icon (image:Move).
  2. Drag it to the Datalink list and release.
  3. Optionally set name and jumbo MTU.
  4. Click "APPLY".
  5. Now Drag the datalink over to the Interfaces list.
  6. Set desired properties, and click "APPLY".
  7. Click "APPLY" at the top of the screen to commit the configuration.

Creating an LACP aggregated link interface

  1. Click the Datalinks image:Add item icon.
  2. Optionally set the datalink name.
  3. Select LACP Aggregation.
  4. Select two or more devices from the Devices list, and click "APPLY".
  5. Click the Interfaces image:Add item icon.
  6. Set desired properties, choose the aggregated link from the Datalinks list, and click "APPLY".
  7. Click "APPLY" at the top to commit the configuration.

Creating an IPMP group using probe-based and link-state failure detection

  1. Create one or more "underlying" IP interfaces that will be used as components of the IPMP group. Each interface must have an IP address to be used as the probe source (see separate task to create a single-port interfaces above).
  2. Click the Interface image:Add item icon.
  3. Optionally change the name of the interface.
  4. Click the IP MultiPathing Group check box.
  5. Click the Use IPv4 Protocol or/and the Use IPv6 Protocol and specify the IP addresses for the IPMP interface.
  6. Choose the interfaces created in the fist step from the Interfaces list.
  7. Set each chosen interface to be either "Active" or "Standby", as desired.
  8. Click "APPLY".

Creating an IPMP group using link-state only failure detection

  1. Create one or more "underlying" IP interfaces with the IP address 0.0.0.0/8 to be used as the components of the IPMP group (see separate task to create a single-port interfaces above).
  2. Click the Interface image:Add item icon.
  3. Optionally change the name of the interface.
  4. Click the IP MultiPathing Group check box.
  5. Click the Use IPv4 Protocol or/and the Use IPv6 Protocol and specify the IP addresses for the IPMP interface.
  6. Choose the interfaces created in the first step from the Interfaces list.
  7. Set each chosen interface to be either "Active" or "Standby", as desired.
  8. Click "APPLY".

Extending an LACP aggregation

  1. Mouse-over a device in the Devices list.
  2. Click the image:Move icon, and drag the device onto an aggregation datalink, and release.
  3. Click "APPLY" at the top of the page to commit this configuration.

Extending an IPMP group

  1. Mouse-over an interface in the Interfaces list.
  2. Click the image:Move icon, and drag the device onto an IPMP interface, and release.
  3. Click "APPLY" at the top of the page to commit this configuration.

Creating an InfiniBand partition datalink and interface

  1. Click the Datalink image:Add item icon.
  2. Optionally set name.
  3. Click the IB Partition checkbox
  4. Choose a device from the Partition Devices list.
  5. Click "APPLY". The new partition datalink will appear in the Datalinks list.
  6. Click the Interface image:Add item icon.
  7. Set desired properties, and choose the datalink previously created.
  8. Click "APPLY". The interface will appear in the Interfaces list.
  9. The running appliance network configuration has not yet changed. When you are finished configuring interfaces, click "APPLY" at the top to commit the configuration.

Creating a VNIC without a VLAN ID for clustered controllers

This example is for an active-active configuration with half of the network ports on standby. This task creates an IP interface over a device datalink and assigns it to a head. A VNIC is built on top of the same datalink, and an IP interface is configured on top of the VNIC and assigned to the other head. Configuring one instead of multiple VNICs over a given datalink ensures peak performance. Traffic flows over the cable associated with the underlying active port on one head, as well as the underlying standby port on the other head. Thus, the otherwise idle standby port can be used with VNICs.

  1. When the cluster is in state AKCS_CLUSTERED, click the Datalinks image:Add item icon.
  2. Optionally set name and MTU.
  3. Choose a device from the Devices list and click "APPLY". The datalink appears in the Datalinks list.
  4. Click the Interface image:Add item icon.
  5. Set desired properties, choose the datalink previously created, and click "APPLY". The interface appears in the Interfaces list.
  6. Click the Datalinks image:Add item icon.
  7. Select the VNIC checkbox, optionally set name and MTU (equal to or less than the value in step 2), and click "APPLY". The new VNIC datalink appears in the Datalinks list.
  8. Click the Interface image:Add item icon.
  9. Set desired properties, choose the VNIC datalink previously created, and click "APPLY". The interface appears in the Interfaces list.
  10. The running appliance network configuration has not yet changed. When you are finished configuring interfaces, click "APPLY" at the top to commit the configuration.
  11. Click the Cluster tab. The two newly created interfaces appear in the Resource section with default owners.
  12. Use the Owner pull-down list to assign one of the two interfaces to the other head and click "APPLY".

Creating VNICs with the same VLAN ID for clustered controllers

This example is for an active-active configuration with half of the network ports on standby. This task creates two VNICs with identical VLAN IDs on top of the same device datalink. Each VNIC is configured with an interface, and each interface is assigned to a different head. Traffic flows over the cable associated with the underlying active port on one head, as well as the underlying standby port on the other head. Thus, the otherwise idle standby port can be used with VNICs.

  1. When the cluster is in state AKCS_CLUSTERED, click the Datalinks image:Add item icon.
  2. Select the VNIC checkbox, optionally set name and MTU, set the VLAN ID, choose a device from the Devices list, and click "APPLY". The new VNIC datalink appears in the Datalinks list.
  3. Click the Interface image:Add item icon.
  4. Set desired properties, choose the VNIC datalink previously created, and click "APPLY". The interface appears in the Interfaces list.
  5. Create another VNIC as described in steps 1 and 2 with the same Device and VLAN ID, and create an interface for it as described in steps 3 and 4.
  6. The running appliance network configuration has not yet changed. When you are finished configuring interfaces, click "APPLY" at the top to commit the configuration.
  7. Click the Cluster tab. The two newly created interfaces appear in the Resource section with default owners.
  8. Use the Owner pull-down list to assign one of the two interfaces to the other head and click "APPLY".

Adding a static route

  1. Go to Configuration->Network->Routing
  2. Click the add icon.
  3. Fill in the properties as described earlier.
  4. Click "ADD". The new route will appear in the table.

Deleting a static route

  1. Go to Configuration->Network->Routing
  2. Mouse-over the route entry, then click the trash icon on the right.

CLI

Adding a static route

  1. Go to configuration net routing.
  2. Enter create.
  3. Type show to list required properties, and set each.
  4. Enter commit.

Deleting a static route

  1. Go to configuration net routing.
  2. Type show to list routes, and route names (e.g., route-002).
  3. Enter destroy route name.

Changing the multihoming property to strict

  1. Go to configuration net routing
  2. Enter set multihoming=strict
  3. Enter commit