Veritas Access Administrator's Guide
- Section I. Introducing Veritas Access
- Section II. Configuring Veritas Access
- Adding users or roles
- Configuring the network
- Configuring authentication services
- Section III. Managing Veritas Access storage
- Configuring storage
- Configuring data integrity with I/O fencing
- Configuring ISCSI
- Veritas Access as an iSCSI target
- Configuring storage
- Section IV. Managing Veritas Access file access services
- Configuring the NFS server
- Setting up Kerberos authentication for NFS clients
- Using Veritas Access as a CIFS server
- About Active Directory (AD)
- About configuring CIFS for Active Directory (AD) domain mode
- About setting trusted domains
- About managing home directories
- About CIFS clustering modes
- About migrating CIFS shares and home directories
- About managing local users and groups
- Configuring an FTP server
- Using Veritas Access as an Object Store server
- Configuring the NFS server
- Section V. Monitoring and troubleshooting
- Section VI. Provisioning and managing Veritas Access file systems
- Creating and maintaining file systems
- Considerations for creating a file system
- Modifying a file system
- Managing a file system
- Creating and maintaining file systems
- Section VII. Configuring cloud storage
- Section VIII. Provisioning and managing Veritas Access shares
- Creating shares for applications
- Creating and maintaining NFS shares
- Creating and maintaining CIFS shares
- Using Veritas Access with OpenStack
- Integrating Veritas Access with Data Insight
- Section IX. Managing Veritas Access storage services
- Compressing files
- About compressing files
- Compression tasks
- Configuring SmartTier
- Configuring SmartIO
- Configuring episodic replication
- Episodic replication job failover and failback
- Configuring continuous replication
- How Veritas Access continuous replication works
- Continuous replication failover and failback
- Using snapshots
- Using instant rollbacks
- Compressing files
- Section X. Reference
Swapping network interfaces
The Network> swap command can be used for swapping two network interfaces of a node in a cluster. This command helps set up the cluster properly in cases where the first node of a cluster cannot be pinged.
Figure: Scenario for using Network> swap for network interfaces describes a scenario whereby using the Network> swap command, you can use the more powerful 10G network interfaces to carry the public network load.
A System Administrator can use the Network> swap command in the following ways:
Multi-node cluster: You can swap one public interface with another.
Single-node cluster: You can swap a private interface with a public interface, swap two public interfaces, or swap two private interfaces.
If input to the Network> swap command contains one public and one private interface, and there are two separate switches for the private and the public network, then before you run the Network> swap command, the System Administrator has to exchange cable connections between these interfaces.
Running the Network> swap command requires stopping the given interfaces, which causes the following:
After you run the Network> swap command, all SSH connection(s) hosted on the input interfaces terminate.
If a public interface is involved when issuing the Network> swap command, all Virtual IP addresses (VIPs) hosted on that interface are brought down first, and are brought back up after Network> swap is complete.
If the Network> swap command is run remotely, due to SSH connection termination, its end status may not be visible to the end user. You can check the status of the Network> swap command under history, by reconnecting to the cluster.
Note:
Veritas Access recommends not to use the Network> swap command when active I/O load is present on the cluster.
To use the swap command
- To use the Network> swap command, enter the following:
Network> swap interface1 interface2 [nodename]
interface1
Indicates the name of the first network interface.
interface2
Indicates the name of the second network interface.
nodename
Indicates the name of the node. If nodename is not provided, the Network> swap command is executed on the current node in the cluster.