Networking
This chapter describes the networking components of a cluster. You need to understand how to configure networking components of the cluster during and after setting up the cluster.
The following topics are covered:
 
9.1 Networking components
In Clustered Data ONTAP, the physical networking components of a cluster are abstracted and virtualized into logical components to provide the flexibility and multi-tenancy in a storage virtual machine (SVM).
These are the various networking components in a cluster:
Ports:
 – Physical ports: Network interface cards (NICs) and HBAs provide physical (Ethernet and Fibre Channel) connections to the physical networks (management and data networks).
 – Virtual ports: VLANs and interface groups (ifgrps) constitute the virtual ports. While interface groups treat several physical ports as a single port, VLANs subdivide a physical port into multiple separate ports.
Logical interfaces (LIFs):
 – An LIF is an IP address and is associated with attributes such as failover rule lists, firewall rules. An LIF communicates over the network through the port (physical or virtual) it is currently bound to.
Different types of LIFs in a cluster are data LIFs, cluster management LIFs, node management LIFs, intercluster LIFs, and cluster LIFs. The ownership of the LIFs depends on the SVM where the LIF resides. Data LIFs are owned by data SVM, node management, and cluster LIFs are owned by node SVM, and cluster management LIFs are owned by admin SVM.
Routing groups:
 – A routing group is a routing table. Each LIF is associated with a routing group and uses only the routes of that group. Multiple LIFs can share a routing group. Each routing group needs a minimum of one route to access clients outside the defined subnet.
DNS zones:
 – DNS zone can be specified during the LIF creation, providing a name for the LIF to be exported through the cluster's DNS server. Multiple LIFs can share the same name, allowing the DNS load balancing feature to distribute IP addresses for the name according to load. An SVM can have multiple DNS zones.
Figure 9-1 shows the interaction of ports, VLANs, interface groups, and LIFs regarding the whole cluster.
Figure 9-1 Interaction of network objects
9.2 Network ports
Ports are either physical ports (NICs) or virtualized ports, such as interface groups (see 9.3, “Interface groups” on page 135) or VLANs (see 9.4, “VLANs” on page 136). An LIF communicates over the network through the port to which it is currently bound.
Network ports can have roles that define their purpose and their default behavior. Port roles limit the types of LIFs that can be bound to a port. Network ports can have four roles: node management, cluster, data, and intercluster. Each network port has a default role. You can modify the roles for obtaining the best configuration. See Table 9-1, which describes the port roles more precisely.
Table 9-1 Network port roles
Role
Description
Node management ports
The ports used by administrators to connect to and manage a node. These ports can be VLAN-tagged virtual ports where the underlying physical port is used for other traffic. The default port for node management differs depending on hardware platform.
 
Some platforms have a dedicated management port (e0M). The role of such a port cannot be changed, and these ports cannot be used for data traffic.
Cluster ports
The ports used for intracluster traffic only. By default, each node has two cluster ports on 10-GbE ports enabled for jumbo frames.
 
You cannot create VLANs or interface groups on cluster ports.
Data ports
The ports used for data traffic. These ports are accessed by NFS, CIFS, FC, and iSCSI clients for data requests. Each node has a minimum of one data port.
 
You can create VLANs and interface groups on data ports. VLANs and interface groups have the data role by default, and the port role cannot be modified.
Intercluster ports
The ports used for cross-cluster communication. An intercluster port should be routable to another intercluster port or the data port of another cluster. Intercluster ports can be on physical ports or virtual ports.
Modifying network port attributes
You can modify the MTU, autonegotiation, duplex, flow control, and speed settings of a physical network or interface group. You can modify only the MTU settings and not other port settings of a VLAN.
You should not modify the following characteristics of a network port:
The administrative settings of either the 10-GbE or the 1-GbE network interfaces.
The values that you can set for duplex mode and port speed are referred to as administrative settings. Depending on network limitations, the administrative settings can differ from the operational settings (that is, the duplex mode and speed that the port actually uses).
The administrative settings of the underlying physical ports in an interface group.
 
Note: Use the -up-admin parameter (available at advanced privilege level) to modify the administrative settings of the port.
The MTU size of the management port, e0M.
The MTU size of a VLAN cannot exceed the value of the MTU size of its base port.
See Example 9-1 about how to use the network port modify command to modify the attributes of a network port. The example shows how to disable the flow control on port e0b by setting it to none.
 
Note: Set the flow control of all ports to none. By default, the flow control is set to full.
Example 9-1 Network port modify
cdot-cluster01::> network port modify -node nodeA -port e0b -flowcontrol-admin none
9.3 Interface groups
An interface group is a feature in Clustered Data ONTAP that implements link aggregation on your storage system. Interface groups provide a mechanism to group together multiple network ports (links) into one logical interface (aggregate).
After an interface group is created, it is indistinguishable from a physical network interface. Clustered Data ONTAP connects with networks through physical interfaces (or links). The most common interface is an Ethernet port, such as e0a, e0b, e0c, and e0d.
IEEE 802.3ad link aggregation is supported by using interface groups. They can be single-mode or multimode. In a single-mode interface group, one interface is active while the other interface is on standby. In single mode, a failure signals the inactive interface to take over and maintain the connection with the switch.
In multimode all interfaces are active and share the same MAC address. Multimode operation has two types of operation:
Static: `multi'
Dynamic: `lacp'
 
Note: Interface groups cannot be created from other interface groups or VLANs.
9.3.1 Creating interface groups
Use the network port ifgrp create command to create an interface group (ifgrp).
Interface groups must be named using the syntax a<number><letter>. For example, a0a, a0b, a1c, and a2a are valid interface group names. For more information about this command, see the man page.
Example 9-2 shows how to create and add ports to an interface group named a0a with a distribution function of ip and a mode of multimode.
Example 9-2 Create interface group
cdot-cluster01::> net port show
cdot-cluster01::> network port ifgrp create -node nodeA -ifgrp a0a -distr-func ip -mode multimode
cdot-cluster01::> network port ifgrp add-port -node nodeA -ifgrp a0a -port e4a
cdot-cluster01::> network port ifgrp add-port -node nodeA -ifgrp a0a -port e4b
You can also use the IBM N series OnCommand System Manager to create and edit interface groups. See Figure 9-2 for an example. Follow these steps:
1. From the Home tab, double-click the appropriate storage system.
2. In the navigation pane, click Nodes   Choose the desired node  Configuration  Ports/Adapters.
3. Click the Create Interface Group button to create the interface group and add ports to it.
Figure 9-2 Configure interface groups in system manager
9.3.2 Deleting interface groups
You can delete interface groups if you want to configure LIFs directly on the underlying physical ports or if you decide to change the interface group mode or distribution function. You cannot delete an interface group that has an LIF bound to it.
Use the network port ifgrp delete command to delete an interface group as shown in Example 9-3.
Example 9-3 Delete interface group
cdot-cluster01::> network port ifgrp delete -node cdot-cluster01-02 -ifgrp a0a
9.4 VLANs
A VLAN, also as in 7-Mode, is a virtual port that receives and sends VLAN-tagged (IEEE 802.1Q standard) traffic. VLAN port characteristics include the VLAN ID for the port. The underlying physical port or interface group ports are considered to be VLAN trunk ports, and the connected switch ports must be configured to trunk the VLAN IDs.
 
You can configure an IP address for an interface with VLANs. Any untagged traffic goes to the base interface and the tagged traffic goes to the respective VLAN.
You can configure an IP address for the base interface (physical port) of the VLAN. Any tagged frame is received by the matching VLAN interface. Untagged traffic is received by the native VLAN on the base interface.
 
Note: You should not create a VLAN on a network interface with the same identifier as the native VLAN of the switch. For example, if the network interface e0b is on native VLAN 10, you should not create a VLAN e0b-10 on that interface.
You cannot bring down the base interface that is configured to receive tagged and untagged traffic. You must bring down all VLANs on the base interface before you bring down the interface. However, you can delete the IP address of the base interface.
9.4.1 Creating a VLAN
You can create a VLAN for maintaining separate broadcast domains within the same network domain by using the network port vlan create command. Before you begin, make sure that the following requirements are met:
The switches deployed in the network either comply with IEEE 802.1Q standards or have vendor-specific implementation of VLANs.
For supporting multiple VLANs, an end-station is statically configured to belong to one or more VLANs.
 
Note: You cannot create a VLAN on cluster management and node management ports. If you want to use a cluster management LIF on a VLAN port, that should have the data role.
Example 9-4 shows how to create a VLAN a0a-1051 attached to network port a0a on the node nodeA.
Example 9-4 Create VLAN
cluster1::> network port vlan create -node nodeA -port a0a -vlan-id 1051
cluster1::> net port vlan show -node nodeA -port a0a
(network port vlan show)
Network Network
Node VLAN Name Port VLAN ID MAC Address
------ --------- ------- -------- -----------------
nodeA
a0a-1051
a0a 1051 02:a0:98:1a:2a:48
You can also use the IBM N series OnCommand System Manager to create VLANs. See Figure 9-3 for an example. Follow these steps:
1. From the Home tab, double-click the appropriate storage system.
2. In the navigation pane, click Nodes  Choose the desired node  Configuration  Ports/Adapters.
3. Click the Create VLAN button to create the VLAN interface.
Figure 9-3 Create VLANs in system manager
9.4.2 Deleting a VLAN
You can delete a VLAN with the network port vlan delete command. When you delete a VLAN, it is automatically removed from all failover rules and groups that use it. You cannot delete a VLAN that has an LIF bound to it.
Example 9-5 deletes the VLAN e0a-1065 from network port e0a on node cdot-cluster01-02.
Example 9-5 Delete VLAN
cdot-cluster01::> network port vlan delete -node cdot-cluster01-02 -vlan-name e0a-1065
9.5 Failover groups
LIF failover in Clustered Data ONTAP refers to the automatic migration of an LIF in response to a link failure on the LIF's current network port. When such a port failure is detected, the LIF is migrated to a working port.
A failover group contains a set of network ports (physical, VLANs, and interface groups) on one or more nodes. An LIF can subscribe to a failover group. The network ports that are present in the failover group define the failover targets for the LIF.
You can manage failover groups by adding ports to them, removing ports from them, renaming them, and displaying information about them.
Failover groups for LIFs can be system-defined or user-defined. Additionally, a failover group called clusterwide exists and is maintained automatically. See Table 9-2, which explains the different types.
Table 9-2 Failover group types
Failover group type
Notes
system-defined
Failover groups that automatically manage LIF failover targets on a per-LIF basis.
This is the default failover group for data LIFs in the cluster.
For example, when the value of the failover-group option is system-defined, the system will automatically manage the LIF failover targets for that LIF, based on the home node or port of the LIF.
user-defined
Failover groups that automatically manage LIF failover targets on a per-LIF basis.
This is the default failover group for data LIFs in the cluster.
For example, when the value of the failover-group option is system-defined, the system will automatically manage the LIF failover targets for that LIF, based on the home node or port of the LIF.
clusterwide
Failover group that consists of all the data ports in the cluster.
This is the default failover group for the cluster management LIFs only.
For example, when the value of the failover-group option is cluster-wide, every data port in the cluster will be defined as the failover targets for that LIF.
 
Note: It is preferred practice to create user-defined failover groups for every network type that is existing in the cluster. Create a failover-group for all ports, VLANs, or interface groups that are connected for example to the accounting network and create another failover group that contains all ports, VLANs, or interface groups that are connected to the storage network. Make sure that in a case of failover, each interface that is part of the same failover group can access the same network segment in order to serve data to the clients. Failover groups do not apply in a SAN iSCSI or FC environment.
9.5.1 Creating failover groups
Use the network interface failover-groups create command to create a failover group or add a port to an existing failover group like shown in Example 9-6.
Example 9-6 Create failover groups
cluster1::> network interface failover-groups create -failover-group storage-lan -node nodeA -port e1b
cluster1::> network interface failover-groups create -failover-group storage-lan -node nodeA -port e1b
cluster1::> network interface failover-groups show
 
Tip: You might have to check whether the failover rules of an LIF are configured correctly. In order to prevent mis-configuration of the failover rules, you can view the failover target for an LIF or all LIFs.
Use the failover option of the network interface show command to view the failover targets of an SVMs LIFs as shown in Example 9-7.
Example 9-7 Display information about failover targets
cdot-cluster01::> net int show -failover -vserver vs_cifs_01
(network interface show)
Logical Home Failover Failover
Vserver Interface Node:Port Policy Group
-------- --------------- --------------------- --------------- ---------------
vs_cifs_01
vs_cifs_01_cifs_lif1 cdot-cluster01-02:e0a
nextavail storage-lan
Failover Targets: cdot-cluster01-02:e0a,
cdot-cluster01-02:e0b,
cdot-cluster01-01:e0a,
cdot-cluster01-01:e0b
9.5.2 Deleting failover groups
To remove a port from a failover group or to delete an entire failover group, you use the network interface failover-groups delete command.
Example 9-8 shows how to delete port e0b of node cdot-cluster01-02 from a failover group named storage-lan.
Example 9-8 Delete port from failover group
cdot-cluster01::> net int failover-groups delete -failover-group storage-lan -node cdot-cluster01-02 -port e0b
You can also delete the whole failover group by using wildcards as shown in Example 9-9.
Example 9-9 Delete whole failover group
cdot-cluster01::> net int failover-groups delete -failover-group storage-lan [-node | -port] *
9.6 Logical interfaces
A logical interface (LIF) is an IP address with associated characteristics, such as a role, a home port, a home node, a routing group, a list of ports to fail over to and a firewall policy. You can configure multiple LIFs on ports over which the cluster sends and receives communications over the network.
If there is any component failure, an LIF can fail over to or be migrated to a different physical port, thereby continuing to communicate with the cluster.
LIFs can be hosted on the following ports:
Physical ports that are not part of interface groups
Interface groups
VLANs
Physical ports or interface groups that host VLANs
While configuring SAN protocols such as FC on an LIF, it will be associated with a WWPN.
9.6.1 LIF types
An LIF role determines the kind of traffic that is supported over the LIF, along with the failover rules that apply and the firewall restrictions that are in place. An LIF can have any one of the five roles: node management, cluster management, cluster, intercluster, and data.
Node management LIF:
The LIF that provides a dedicated IP address for managing a particular node and gets created at the time of creating or joining the cluster. These LIFs are used for system maintenance, for example, when a node becomes inaccessible from the cluster. Node management LIFs can be configured on either node management or data ports.
The node management LIF can fail over to other data or node management ports on the same node.
Sessions established to SNMP and NTP servers use the node management LIF. AutoSupport requests are sent from the node management LIF.
Cluster management LIF:
The LIF that provides a single management interface for the entire cluster. Cluster management LIFs can be configured on node management or data ports.
The LIF can fail over to any node management or data port in the cluster. It cannot fail over to cluster or intercluster ports.
Cluster LIF:
The LIF that is used for intracluster traffic. Cluster LIFs can be configured only on cluster ports.
Cluster LIFs must always be created on 10-GbE network ports and can fail over between cluster ports on the same node, but they cannot be migrated or failed over to a remote node. When a new node joins a cluster, IP addresses are generated automatically.
 
Note: If you want to assign IP addresses manually to the cluster LIFs, you must ensure that the new IP addresses are in the same subnet range as the existing cluster LIFs.
Data LIF:
The LIF that is associated with an SVM and is used for communicating with clients. Data LIFs can be configured only on data ports.
You can have multiple data LIFs on a port. These interfaces can migrate or fail over throughout the cluster.
Sessions established to NIS, LDAP, Active Directory, WINS, and DNS servers use data LIFs.
Intercluster LIF:
The LIF that is used for cross-cluster communication, backup, and replication.
Intercluster LIFs can be configured on data ports or intercluster ports. You must create an intercluster LIF on each node in the cluster before a cluster peering relationship can be established.
9.6.2 LIF limitations
There are limits (see Table 9-3) on each type of LIF that you should consider when planning your network. Also be aware of the effect of the number of LIFs in your cluster environment.
The maximum number of LIFs that are supported on a node is 262. You can create additional cluster, cluster management, and intercluster LIFs, but creating these LIFs requires a reduction in the number of data LIFs.
Table 9-3 LIF limits
LIF type
Min
Max
Data LIFs
1 per SVM
128 per node with failover enabled
256 per node with failover disabled
Cluster LIFs
2 per Node
-
Node management LIFs
1 per Node
1 per port and per subnet
Cluster management LIFs
1 per cluster
-
Intercluster LIFs
0 without cluster peering
1 per node with cluster peering
-
9.6.3 Creating an LIF
There are certain guidelines that you should consider before creating an LIF. Consider the following points while creating an LIF:
In data LIFs used for file services, the default data protocol options are NFS and CIFS.
FC LIFs can be configured only on FC ports. iSCSI LIFs cannot coexist with any other protocols.
NAS and SAN protocols cannot coexist on the same LIF.
You can create both IPv4 and IPv6 LIFs on the same network port.
To create an LIF use the network interface create command as shown in Example 9-10. See man network interface create for further information.
Example 9-10 Create data LIF
cdot-cluster01::> network interface create -vserver vs_cifs_01 -lif vs_cifs_01_lif1 -role data -home-node cdot-cluster01-01 -home-port e0b -address 9.155.66.26 -netmask 255.255.255.0
You can display information about all LIFs in the cluster with the network interface show command (see Example 9-11).
Example 9-11 Network interface show
cdot-cluster01::> net int show
(network interface show)
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
cdot-cluster01
cluster_mgmt up/up 9.155.66.34/24 cdot-cluster01-02
e0a false
cdot-cluster01-01
cdot-cluster01-01_intercluster_lif1
up/up 9.155.66.65/24 cdot-cluster01-01
e0a true
clus1 up/up 169.254.216.146/16 cdot-cluster01-01
e2a true
clus2 up/up 169.254.67.99/16 cdot-cluster01-01
e2b true
mgmt1 up/up 9.155.90.168/24 cdot-cluster01-01
e0M true
cdot-cluster01-02
cdot-cluster01-02_intercluster_lif2
up/up 9.155.66.66/24 cdot-cluster01-02
e0a true
clus1 up/up 169.254.45.229/16 cdot-cluster01-02
e2a true
clus2 up/up 169.254.250.11/16 cdot-cluster01-02
e2b true
mgmt1 up/up 9.155.90.169/24 cdot-cluster01-02
e0M true
vs_cifs_01
vs_cifs_01_cifs_lif1
up/up 9.155.66.31/24 cdot-cluster01-02
e0a true
10 entries were displayed.
 
Note: You can use the ping command from a client or network ping command from a node in the cluster to verify if the configured addresses are reachable. Every LIF should be pingable.
9.6.4 Modifying an LIF
You can modify an LIF by changing the attributes such as the home node or the current node, administrative status, IP address, netmask, failover policy, or the firewall policy. You can also modify the address family of an LIF from IPv4 to IPv6. However, you cannot modify the data protocol that is associated with an LIF when the LIF was created.
Use the network interface modify command to modify an LIF's attributes. See man page for further information.
Example 9-12 shows how to modify the LIF vs_cifs_01_cifs_lif1 that is owned by SVM vs_cifs_01 in order to change it‘s IP address.
Example 9-12 Modify network interface
cdot-cluster01::> net int modify -vserver vs_cifs_01 -lif vs_cifs_01_cifs_lif1 -address 9.155.66.41 -netmask 255.255.255.0
You can also use the IBM N series OnCommand System Manager to modify the LIF. See Figure 9-4 for an example. Follow these steps:
1. From the Home tab, double-click the appropriate storage system.
2. In the navigation pane, click Vservers  Choose the desired SVM  Configuration  Network Interfaces.
3. Select the LIF you want to modify and click Edit to edit the LIF.
Figure 9-4 Modify LIF in system manager
9.6.5 Migrating an LIF
You might have to migrate an LIF to a different port on the same node or a different node within the cluster, if the port is either faulty or requires maintenance.
Before you migrate the LIF, you should ensure that the destination node and ports are operational and able to access the same network as the source port. Also failover groups must have been set up for the LIFs. See 9.5, “Failover groups” on page 138 for further information about failover groups.
 
Note: You cannot migrate iSCSI LIFs from one node to another node. VMware VAAI copy offload operations fail when you migrate the source or the destination LIF.
You can either migrate a specific LIF or migrate all data and cluster management LIFs away from one node.
Example 9-13 shows how to migrate an LIF named vs_cifs_01_cifs_lif1 on the SVM vs_cifs_01 to the port e0a on node cdot-cluster01-01.
Example 9-13 Migrate specific LIF
cdot-cluster01::> net interface migrate -vserver vs_cifs_01 -lif vs_cifs_01_cifs_lif1 -dest-node cdot-cluster01-01 -dest-port e0a
Example 9-14 shows how to migrate all LIFs away from node cdot-cluster01-01.
Example 9-14 Migrate all LIFs away from specific node
cdot-cluster01::> network interface migrate-all -node cdot-cluster01-01
9.6.6 Reverting an LIF
You can revert an LIF to its home port after it fails over or is migrated to a different port either manually or automatically. If the home port of a particular LIF is unavailable, the LIF remains at its current port and is not reverted.
You can use the network interface show command to find LIFs that are not on their home-port and have a Is Home state of false. These LIFs need to be reverted (see Example 9-15).
Example 9-15 Display LIFs that are not on their home-port
cdot-cluster01::> net int show -is-home false
(network interface show)
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
vs_cifs_01
vs_cifs_01_cifs_lif1
up/up 9.155.66.31/24 cdot-cluster01-01
e0a false
Revert the interface with the network interface revert command as shown in Example 9-16.
Example 9-16 Revert LIFs
cdot-cluster01::> net interface revert -vserver vs_cifs_01 -lif vs_cifs_01_cifs_lif1
You can also use the IBM N series OnCommand System Manager to revert the LIF. See Figure 9-5 for an example. Follow these steps:
1. From the Home tab, double-click the appropriate storage system.
2. In the navigation pane, click Vservers  Choose the desired SVM  Configuration  Network Interfaces.
3. Select the LIF you want to revert and click Send to Home to revert the LIF.
Figure 9-5 Revert LIF in system manager
9.6.7 Deleting an LIF
You can delete an LIF that is not required.
Use the network interface delete command to delete the LIF. You can specify * as a wildcard in order to delete all LIFs.
Example 9-17 shows how to delete an LIF named vs_cifs_01_cifs_lif1 on the SVM vs_cifs_01.
Example 9-17 Delete LIF
cdot-cluster01::> network interface delete -vserver vs_cifs_01 -lif vs_cifs_01_cifs_lif1
9.7 Routing groups
You can control how LIFs in an SVM use your network for outbound traffic by configuring routing groups and static routes. A set of common routes are grouped in a routing group that makes the administration of routes easier.
When an LIF is created, an associated routing group is automatically created. You cannot modify or rename an existing routing group; therefore, you might have to create a routing group.
9.7.1 Creating routing groups
When you create a new routing group, observe the following rules:
The routing group and the associated LIFs should be in the same subnet.
All LIFs sharing a routing group must be on the same IP subnet.
All next-hop gateways must be on that same IP subnet.
An SVM can have multiple routing groups, but a routing group belongs to only one SVM.
The routing group name must be unique in the cluster and should not contain more than 64 characters.
You can create a maximum of 256 routing groups per node.
To create a routing group, use the network routing-groups create command. Example 9-18 shows how to create a routing group named d9.155.66.0 for the SVM vs_cifs_01 and the subnet 9.155.66.0/24. See man network routing-groups create for further information.
Example 9-18 Create routing group
cdot-cluster01::> network routing-groups create -vserver vs_cifs_01 -routing-group d9.155.66.0 -subnet 9.155.66.0/24 -role data
9.7.2 Deleting routing groups
When you delete a routing group, observe the following rules:
There must be no LIF that is using the routing group.
The routing group must not contain any routes.
To delete an existing routing group, use the network routing-groups delete command as shown in Example 9-19.
Example 9-19 Delete routing group
cdot-cluster01::> network routing-groups delete -vserver vs_cifs_01 -routing-group d9.155.66.0
9.7.3 Creating a static route
Use the network routing-groups route create command to create a route within the routing group.
Example 9-20 shows how to create a default gateway route for the routing group named d9.155.66.0 for the SVM vs_cifs_01 and the subnet 9.155.66.0/24.
Example 9-20 Create route within routing group
cdot-cluster01::> network routing-groups route create -vserver vs_cifs_01 -routing-group d9.155.66.0 -destination 0.0.0.0/0 -gateway 9.155.66.1
9.7.4 Deleting a static route
You can delete an unneeded static route from a routing group.
Example 9-21 shows how to delete a static route for the routing group named d9.155.66.0 for the SVM vs_cifs_01 and the subnet 9.155.66.0/24.
Example 9-21 Delete static route
cdot-cluster01::> network routing-groups route delete -vserver vs_cifs_01 -routing-group d9.155.66.0 -destination 0.0.0.0/0
 
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.138.134.188