Docu48205 - Avamar Post Installation Network Configuration Technical Note
Docu48205 - Avamar Post Installation Network Configuration Technical Note
EMC® Avamar®
Post-Installation Network Configuration
Avamar 5.x, 6.x, or 7.x Server Software
Technical Note
P/N 300-015-091
REV 03
This technical note describes how to change the networking configuration of an existing
EMC Avamar system after installation and implementation is complete, including IPv6
considerations introduced in Avamar 7.0. Topics include:
◆ Revision history ........................................................................................................ 2
◆ Purpose .................................................................................................................... 2
◆ Avamar, IPv4, and IPv6 ............................................................................................. 2
◆ Supported Avamar networking configurations ........................................................... 3
◆ IPv4 and IPv6 Subnets .............................................................................................. 5
◆ Changing IP address, hostname of an Avamar System ............................................... 6
◆ Adding, updating VLANs or NAT on an existing Avamar system ................................ 64
◆ Configuring an Avamar System as Dual Stack .......................................................... 70
Revision history
Revision history
The following table presents the revision history of this document:
Purpose
This technical note provides the background information and steps to change the
networking configuration of an existing Avamar system after installation and
implementation is complete.
The procedures that follow include methods for changing the IP address and hostname of
a system, setting up VLANs and NAT, and understanding how IPv4 and IPv6 address
formatting affect Avamar configuration.
For more reference information about applicable subnets in IPv4 and IPv6 notation, see
IPv4 and IPv6 Subnets (page 5).
In the Avamar user interface, an IP address may be displayed in either IPv4 or IPv6
notation. The notation type you see is dependent on how that particular component was
initially configured.
IPv4 and IPv6 are not interoperable. They operate in separate stacks (that is, parallel,
independent networks).
Avamar can be set up in a dual stack configuration. In that case, an individual Avamar
component may have an IPv4 address, an IPv6 address, or both (one primary and the
other secondary). Any part of the Avamar user interface may display a component's
primary address or both dual stack addresses. The following IP address for a particular
device indicates it is configured as dual stack: 10.99.99.99/24,2001:db8:abcd:12::/64
Determination of whether Avamar 7.x supports the use of particular network configuration
features depends upon the timing of the configuration -- during the installation and
implementation process or post-installation.
IMPORTANT
Assume that use cases not mentioned in the following sections are not supported.
Descriptions for configuring these use cases, except as noted in #4, are not included in
this document, but rather are contained in Avamar Procedure Generator and workflow
installation and implementation documentation.
The following tables place this same information in a matrix format for easy
consideration.
* Use the dpnnetutil utility and then run the installation workflow.
** Run only the installation workflow.
*** Special case: An IPv4-only installation with VLANs or NAT, followed by the addition of an IPv6
stack post-installation (no VLANs or NAT associated with IPv6).
Existing System
Migrate to IPv6 No No NA X
Migrate to IPv4 NA NA No X
IPv4
/8 255.0.0.0
/9 255.128.0.0
/10 255.192.0.0
/11 255.224.0.0
/12 255.240.0.0
/13 255.248.0.0
/14 255.252.0.0
/15 255.254.0.0
/16 255.255.0.0
/17 255.255.128.0
/18 255.255.192.0
/19 255.255.224.0
/20 255.255.240.0
/21 255.255.248.0
/22 255.255.252.0
/23 255.255.254.0
/24 255.255.255.0
/25 255.255.255.128
/26 255.255.255.192
/27 255.255.255.224
/28 255.255.255.240
/29 255.255.255.248
/30 255.255.255.252
/31 255.255.255.254
/32 255.255.255.255
IPv6
/16 ffff:0000:0000:0000:0000:0000:0000:0000
/32 ffff:ffff:0000:0000:0000:0000:0000:0000
/48 ffff:ffff:ffff:0000:0000:0000:0000:0000
/64 ffff:ffff:ffff:ffff:0000:0000:0000:0000
/80 ffff:ffff:ffff:ffff:ffff:0000:0000:0000
/96 ffff:ffff:ffff:ffff:ffff:ffff:0000:0000
/112 ffff:ffff:ffff:ffff:ffff:ffff:ffff:0000
A note about changing the IP address or hostname of an Avamar Virtual Edition (AVE)
system. For the most part, AVE is treated like an Avamar single node server. The major
difference between the two is that AVE does not have bond[0,1,2,3] devices due to the
fact that it has only one eth0 network interface.
Prerequisites
Your Avamar server must be running Avamar 5.x, 6.x, or 7.x server software.
IMPORTANT
Before starting this procedure, ensure the Avamar system you intend to reconfigure is a
healthy one, that is, it is in a known good controlled state. This includes ensuring that a
validated (hfschecked) checkpoint is present. If not, take a checkpoint and validate it
before proceeding any further. Refer to EMC KnowledgeBase article 163733 for more
details (search for it on http://support.emc.com).
If the hostnames for other network components, such as the smtp mail server or
authentication servers, have changed, you must update the Avamar server with the
correct information. Refer to Configuring the Avamar Downloader Service (page 63) for
more information.
Server Preparation
This section applies only when you are using this technical note to manually change the
networking configuration of an Avamar system. Do not perform the following if you initially
used the Change Network Settings workflow on an Avamar 7.1.1 system.
1. Open a command shell.
2. Log into the server as user admin.
3. When prompted for a password, type the admin password and press ENTER.
4. Load the admin OpenSSH key by entering:
ssh-agent bash
ssh-add ~admin/.ssh/admin_key
How to proceed
The configuration procedure you must follow varies depending on several factors.
For Avamar 7.1.1, a limited number of use cases support the use of the Change Network
Settings workflow for performing many reconfiguration changes on Gen4/Gen4S systems.
Even after using the workflow, some manual steps might be required to complete the
reconfiguration. For those instances in which you have used the workflow to modify IP and
hostname settings, follow the procedure in Post-Change Network Settings workflow
configuration procedure (Avamar 7.1.1 only) (page 32).
In all other cases in which the Change Network Settings workflow is not used, this
technical note describe the manual steps required to reconfigure your system. Choose the
configuration procedure you must follow depending on the server platform and whether
the existing system is configured to use IPv4, IPv6, or dual stack addressing:
◆ For Avamar software running on an RHEL server (Gen1, Gen2, Gen3, and
customer-provided hardware), follow the procedure in Configuration procedure for
RHEL platforms (page 8).
◆ For Avamar 6.x/7.x software on Gen4/Gen4S hardware with IPv4 addressing, follow
the procedure in Configuration procedure for SLES platforms using only IPv4
addressing (Avamar 6.x/7.x) (page 11).
◆ For Avamar 6.x/7.x software on Gen4/Gen4S hardware with IPv6 addressing, follow
the procedure in Configuration procedure for SLES platforms using only IPv6
addressing (Avamar 7.x only) (page 19).
◆ For Avamar 6.x/7.x software on Gen4/Gen4S hardware with dual stack addressing,
follow the procedure in Configuration procedure for SLES platforms using dual stack
addressing (Avamar 7.x only) (page 25).
◆ For Avamar Virtual Edition, follow the RHEL or SLES procedure, as appropriate to which
operating system is running on the AVE.
IMPORTANT
When configuring multi-node systems,
/etc/hosts and /etc/resolv.conf should be identical on all nodes in the system.
a. /etc/resolv.conf
domain local.example.com
search local.example.com company.com
nameserver 127.0.0.1
Set the Avamar server IP address. Change the corresponding name if it is being
changed.
Set the Avamar server IP address. Change the corresponding name if it is being
changed.
d. /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=HOSTNAME
Edit the IP of the system, and set the gateway (if present), netmask and so forth, if
they are being changed.
IMPORTANT
If network interface bonding was previously configured, you must modify two separate
ifcfg-ETH files as well as the ifcfg-bond0 file. The three files must have the same IP address
and netmask information.
5. In order to properly apply the new network settings, you must reboot the server by
entering:
touch /fastboot
reboot
13. Verify network connectivity with the new settings by entering the following for each
node:
ping HOSTNAME
where HOSTNAME is the hostname of each node rebooted in step 5 of this procedure.
14. Change the following Avamar files:
a. Modify the probe.xml file to update node IP addresses by typing the following
command for each changed node:
nodedb update if --addr=OLD-IP --new-addr=NEW-IP
where OLD-IP and NEW-IP are the old and new IP addresses for the node.
Repeat for each node for which the IP address was changed.
b. To verify these changes, type the following command:
nodedb print
c. Modify the probe.xml file to update the hostname of the node by typing the
following command:
nodedb update module --index=0 --new-name=NEWNAME
where NEWNAME is the hostname for either the single node server or the utility
node of a multi-node server.
d. If the interface configured in step (a) was configured for NAT and NAT information
has changed, go to step (e). Otherwise, go to step 15.
e. Remove the existing INITIAL/TARGET IP address pair to be updated by typing the
following command:
nodedb delete nat --nat=INITIAL=TARGET
If you have more than one NAT rule for the interface, append as many
"INITIAL=TARGET" options to this command as required.
f. To verify these changes, type the following command:
nodedb print
g. Update the specific interface with an updated pair by typing the following
command:
nodedb update if --addr=IP --new-nat=INITIAL=TARGET
where IP is the same as NEW-IP in step (a). If you have more than one NAT rule for
the interface, append as many ",INITIAL=TARGET" options to this command
as required.
Configuration procedure for SLES platforms using only IPv4 addressing (Avamar
6.x/7.x)
For Avamar 6.x/7.x software running on Gen4/Gen4S hardware, there are several
configuration options. Networking files that require modification will vary depending on
the specific configuration. The networking files are located in
/etc/sysconfig/network/. Configuration options include:
◆ Single node or AVE systems
◆ Multinode systems
• eth0 and eth2 configured as slaves to bond0
Reserved for backup.
• eth1 and eth3 configured as slaves to bond1
For internal traffic.
• eth4 and eth6 configured as slaves to bond2
Reserved for optional replication on the utility node.
IMPORTANT
When configuring multi-node systems,
/etc/hosts and /etc/resolv.conf should be identical on all nodes in the system.
a. /etc/resolv.conf
domain local.example.com
search local.example.com company.com
nameserver 127.0.0.1
Set the Avamar server IP address. Change the corresponding name if it is being
changed.
Set the Avamar server IP address. Change the corresponding name if it is being
changed.
Note: Due to space constraints on this page, lines in the above example wrap to the next
line. They should not wrap in the actual file.
Note: If the hostname of the server is changing, you must preserve the naming scheme of
HOST_NAME-internal, where HOST_NAME is the new hostname.
d. /etc/HOSTNAME
HOST_NAME
e. /etc/sysconfig/network/ifcfg-ETH
Note: The following example assumes that the interface ETH is a slave of bond0, as
indicated with the MASTER entry. The value for this entry will vary depending on the
bond-id. If bonding is configured and characteristics of the bond are not changing, the
ifcfg-ETH files should not need modification.
where ETH can be eth0, eth1, eth2, eth3, or bond0 (two ports bonded for
failover redundancy).
STARTMODE=onboot
BOOTPROTO=none
USERCONTROL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
f. /etc/sysconfig/network/ifcfg-bond0
STARTMODE=onboot
BOOTPROTO=static
IPADDR=IP-ADDR
NETMASK=NETMASK-IP
BONDING_MASTER=yes
BONDING_SLAVE0=ETH0
BONDING_SLAVE1=ETH2
BONDING_MODULE_OPTS="mode=active-backup miimon=100 updelay=2000
primary=eth0"
where IP-ADDR is the IP address associated with this bond, NETMASK-IP is the
netmask associated with the IP address, and ETH0 and ETH2 are the slaves of this
bond.
Depending on Avamar software version, "BONDING_MODULE_OPTS=" may be
either of the following in the above example:
BONDING_MODULE_OPTS="mode=active-backup miimon=100 updelay=2000
primary=eth0"
BONDING_MODULE_OPTS="primary=eth0"
Note: If you have additional bonds, as described in Configuration procedure for SLES
platforms using only IPv4 addressing (Avamar 6.x/7.x) (page 11), you need to repeat steps
e and f for their respective configuration files.
g. If you are changing the names or ip addresses on a VLAN, you must also configure
the VLAN-specific ifcfg files in /etc/sysconfig/network/ifcfg-bond0.VLAN-ID, where
VLAN-ID is the id of the VLAN, for example:
/etc/sysconfig/network/ifcfg-bond0.123
/etc/sysconfig/network/ifcfg-bond0.222
/etc/sysconfig/network/ifcfg-bond0.333
The following is example content of the ifcfg-bond0.123 file:
STARTMODE=onboot
BOOTPROTO=static
IPADDR=IP-ADDR
NETMASK=NETMASK-IP
ETHERDEVICE=bond0
VLAN_ID=123
where IP-ADDR is the IP address of bond0 for this particular VLAN, and NETMASK-IP
is the netmask associated with the IP address.
5. Set the default gateway in the /etc/sysconfig/network/routes file:
default GATEWAY-IP - -
where GATEWAY-IP is the IP address of the default gateway associated with the
primary bond or network interface.
Note: The above example only shows a default gateway. Besides the mandatory default,
the /routes file may contain additional static destination network routes. For example:
2000::13 2620:0:170:588::1 - -
10.12.12.0/24 10.6.98.1 - -
6. In order to properly apply the new network settings, you must reboot the server by
entering:
touch /fastboot
reboot
14. Verify network connectivity with the new settings by entering for each node:
ping HOSTNAME
where HOSTNAME is the hostname of each node rebooted in step 6 of this procedure.
15. Change the following Avamar files:
a. Modify the probe.xml file to update node IP addresses by typing the following
command for each changed node:
nodedb update if --addr=OLD-IP --new-addr=NEW-IP
where OLD-IP and NEW-IP are the old and new IP addresses for the node.
Repeat for each node for which the IP address was changed.
b. To verify these changes, type the following command:
nodedb print
c. Modify the probe.xml file to update node hostname by typing the following
command:
nodedb update module --index=0 --new-name=NEWNAME
where NEWNAME is the hostname for either the single node server or the utility
node of a multi-node server.
d. If the interface configured in step (a) was configured for NAT and NAT information
has changed, go to step (e). Otherwise, go to step (h).
e. Remove the existing INITIAL/TARGET IP address pair to be updated by typing the
following command:
nodedb delete nat --nat=INITIAL=TARGET
If you have more than one NAT rule for the interface, append as many
",INITIAL=TARGET" options to this command as required.
f. To verify these changes, type the following command:
nodedb print
g. Update the specific interface with an updated pair by typing the following
command:
nodedb update if --addr=IP --new-nat=INITIAL=TARGET
where IP is the same as NEW-IP in step (a). If you have more than one NAT rule for
the interface, append as many ",INITIAL=TARGET" options to this command
as required.
h. To verify these changes, type the following command:
nodedb print
IMPORTANT
Use steps 15i through 15k for Avamar 7.x systems only. Otherwise, skip to step 16.
i. As user admin, check if you have a probe.xml consistent with a new install of
version 7 by running:
nodedb print | grep userinput | wc -l
If the value returned is greater than 0 attributes, you must further modify the
probe.xml by continuing with step (j). Otherwise, skip to step 16.
j. With a text editor, modify module attributes in probe.xml (located in
/usr/local/avamar/var/) for the entire Avamar system. Use the following as an
example of an object with module attributes:
<dpn>
<module name="a4ipn600" userinput_domain="example.com"
userinput_gateway="10.110.227.1" userinput_pns="10.110.195.11"
userinput_sns="10.110.188.5" userinput_summary="24 storages, 1
utility">
where:
Attribute Definition
k. Modify each additional node object defined in the probe.xml and its attributes.
Use the following as an example of a node object and its attributes:
<node type="utility" userinput_hostname="a4ipn600">
<network-interface id="1" userinput_bonded="eth0,eth2"
userinput_ifname="eth0">
<address newuserinput_value="10.110.227.147"
userinput_customhostname="a4ipn600.example.com"
userinput_netmask="255.255.255.0" value="10.110.227.147"/>
<uses allow="replication,management,backup"/>
</network-interface>
<network-interface id="2" userinput_bonded="eth1,eth3"
userinput_ifname="eth1">
<address newuserinput_value="192.168.255.1"
userinput_customhostname="a4ipn600.example.com"
userinput_netmask="255.255.255.0" value="192.168.255.1"/>
<uses allow="internal"/>
</network-interface>
</node>
where:
Attribute Definition
Skip to Post Configuration Procedure (page 52). Afterwards, if the IP address of the
internal network switches must be changed, go to Procedure for changing the IP address
on Allied Telesis internal network switches (Gen4 and Gen4S only) (page 41) or Procedure
for changing the IP address on Brocade internal network switches (Gen4S only) (page 46),
depending on the switch type.
Configuration procedure for SLES platforms using only IPv6 addressing (Avamar 7.x
only)
For Avamar 7.x software running on Gen4/Gen4S hardware, there are several
configuration options. Networking files that require modification will vary depending on
the specific configuration. The networking files are located in /etc/sysconfig/network/.
Configuration options include:
◆ Single node or AVE systems
◆ Multinode systems
• eth0 and eth2 configured as slaves to bond0
Reserved for backup.
• eth1 and eth3 configured as slaves to bond1
For internal traffic.
• eth4 and eth6 configured as slaves to bond2
Reserved for optional replication on the utility node.
• eth5 and eth7 configured as slaves to bond3
Reserved for optional management on utility node.
IMPORTANT
When configuring multi-node systems,
/etc/hosts and /etc/resolv.conf should be identical on all nodes in the system.
a. /etc/resolv.conf
domain local.example.com
search local.example.com company.com
nameserver NAMESERVERIP
where SINGLENODEIP is a valid IPv6 address. Set the Avamar server IP address.
Change the corresponding name if it is being changed.
c. /etc/hosts on multi-node servers
UTILITYIP avamar1.example.com avamar1
#utility
DATA1IP avamar2.example.com avamar2
#data
DATA2IP avamar3.example.com avamar3
#data
DATA3IP avamar4.example.com avamar4
#data
DATA4IP avamar5.example.com avamar5
#data
SPAREIP avamar6.example.com avamar6
#spare
UTILITYINTIP avamar1-internal.example.com avamar1-internal
#utility
internal
DATA1INTIP avamar2-internal.example.com avamar2-internal
#data
internal
DATA2INTIP avamar3-internal.example.com avamar3-internal
#data
internal
DATA3INTIP avamar4-internal.example.com avamar4-internal
#data
internal
DATA4INTIP avamar5-internal.example.com avamar5-internal
#data
internal
SPAREINTIP avamar6-internal.example.com avamar6-internal
#spare
internal
127.0.0.1 localhost
# special IPv6 addresses
::1 localhost ipv6-localhost ipv6-loopback
fe00::0 ipv6-localnet
ff00::0 ipv6-mcastprefix
ff02::1 ipv6-allnodes
ff02::2 ipv6-allrouters
ff02::3 ipv6-allhosts
where each token IP is a valid IPv6 address for each component. Set the Avamar
server IP address. Change the corresponding name if it is being changed.
Note: Due to space constraints on this page, lines in the above example wrap to the next
line. They should not wrap in the actual file.
Note: If the hostname of the server is changing, you must preserve the naming scheme of
HOST_NAME-internal, where HOST_NAME is the new hostname.
d. /etc/HOSTNAME
HOST_NAME
Note: The following example assumes that the interface ETH is a slave of bond0, as
indicated with the MASTER entry. The value for this entry will vary depending on the
bond-id. If bonding is configured and characteristics of the bond are not changing, the
ifcfg-ETH files should not need modification.
where ETH can be eth0, eth1, eth2, eth3, or bond0 (two ports bonded for
failover redundancy).
STARTMODE=onboot
BOOTPROTO=none
USERCONTROL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
f. /etc/sysconfig/network/ifcfg-bond0
STARTMODE=onboot
BOOTPROTO=static
IPADDR=IP-ADDR
BONDING_MASTER=yes
BONDING_SLAVE0=ETH0
BONDING_SLAVE1=ETH2
BONDING_MODULE_OPTS="primary=eth0"
where IP-ADDR is the IPv6 address (including the /64 netmask suffix) associated
with this bond, and ETH0 and ETH2 are the slaves of this bond.
Note: If you have additional bonds, as described in Configuration procedure for SLES
platforms using only IPv6 addressing (Avamar 7.x only) (page 19), you need to repeat
steps e and f for their respective configuration files.
where GATEWAY-IP is the IP address of the default gateway associated with the
primary bond or network interface.
Note: The above example only shows a default gateway. Besides the mandatory default,
the /routes file may contain additional static destination network routes. For example:
2620:0:170:59a::/64 2620:0:170:58f::1 - -
2620:0:170:570::/60 2620:0:170:58f::1 - -
6. Ensure that you are still logged into the Avamar server as root.
7. Switch to admin user by typing the following:
su - admin
10. In order to properly apply the new network settings, you must reboot the server by
entering:
touch /fastboot
reboot
17. Verify network connectivity with the new settings by entering the following for each
node:
ping6 HOSTNAME
a. Modify the probe.xml file to update node IP addresses by typing the following
command for each changed node:
nodedb update if --addr=OLD-IP --new-addr=NEW-IP
where OLD-IP and NEW-IP are the old and new IP addresses for the node.
Repeat for each node for which the IP address was changed.
b. To verify these changes, type the following command:
nodedb print
c. Modify the probe.xml file to update node hostname by typing the following
command:
nodedb update module --index=0 --new-name=NEWNAME
where NEWNAME is the hostname for either the single node server or the utility
node of a multi-node server.
d. To verify these changes, type the following command:
nodedb print
where:
Attribute Definition
f. Modify each additional node object defined in the probe.xml and its attributes.
Use the following as an example of a node object and its attributes:
<node type="utility" userinput_hostname="a4ipn600">
<network-interface id="1" userinput_bonded="eth0,eth2"
userinput_ifname="eth0">
<address newuserinput_value="10.110.227.147"
userinput_customhostname="a4ipn600.example.com"
userinput_netmask="255.255.255.0" value="10.110.227.147"/>
<uses allow="replication,management,backup"/>
</network-interface>
<network-interface id="2" userinput_bonded="eth1,eth3"
userinput_ifname="eth1">
<address newuserinput_value="192.168.255.1"
userinput_customhostname="a4ipn600.example.com"
userinput_netmask="255.255.255.0" value="192.168.255.1"/>
<uses allow="internal"/>
</network-interface>
</node>
where:
Attribute Definition
Skip to Post Configuration Procedure (page 52). Afterwards, if the IP address of the
internal network switches must be changed, go to Procedure for changing the IP address
on Allied Telesis internal network switches (Gen4 and Gen4S only) (page 41) or Procedure
for changing the IP address on Brocade internal network switches (Gen4S only) (page 46),
depending on the switch type.
Configuration procedure for SLES platforms using dual stack addressing (Avamar 7.x
only)
For Avamar 7.x software running on Gen4/Gen4S hardware, there are several
configuration options. Networking files that require modification will vary depending on
the specific configuration. The networking files are located in
/etc/sysconfig/network/. Configuration options include:
◆ Single node or AVE systems
◆ Multinode systems
• eth0 and eth2 configured as slaves to bond0
Reserved for backup.
• eth1 and eth3 configured as slaves to bond1
For internal traffic.
• eth4 and eth6 configured as slaves to bond2
Reserved for optional replication on the utility node.
• eth5 and eth7 configured as slaves to bond3
Reserved for optional management on utility node.
◆ VLAN configuration (for IPv4 stack only)
• bond0.VLAN-IDs
Optional multiple-tagged backup networks.
IMPORTANT
When configuring multi-node systems,
/etc/hosts and /etc/resolv.conf should be identical on all nodes in the system.
a. /etc/resolv.conf
domain local.example.com
search local.example.com company.com
nameserver NAMESERVERIP
where SINGLENODEIP is either a valid IPv4 or IPv6 address. Set the Avamar server
IP address. Change the corresponding name if it is being changed.
IMPORTANT
When changing IP addresses in dual-stack configurations, EMC strongly recommends you
also provide a unique hostname too for each changed IPv6 IP address. This can be
accomplished by creating unique hostnames or subdomains like the following examples:
hostname.domain.local (IPv4)
hostname6.domain.local (IPv6)
hostname.domain.local (IPv4)
hostname.ipv6.domain.local (IPv6)
where each token IP is either a valid IPv4 or IPv6 address for each component. Set
the Avamar server IP address. Change the corresponding name if it is being
changed.
IMPORTANT
When changing IP addresses in dual-stack configurations, EMC strongly recommends you
also provide a unique hostname too for each changed IPv6 IP address. This can be
accomplished by creating unique hostnames or subdomains like the following examples:
hostname.domain.local (IPv4)
hostname6.domain.local (IPv6)
hostname.domain.local (IPv4)
hostname.ipv6.domain.local (IPv6)
Note: Due to space constraints on this page, lines in the above example wrap to the next
line. They should not wrap in the actual file.
Note: If the hostname of the server is changing, you must preserve the naming scheme of
HOST_NAME-internal, where HOST_NAME is the new hostname.
d. /etc/HOSTNAME
HOST_NAME
Note: The following example assumes that the interface ETH is a slave of bond0, as
indicated with the MASTER entry. The value for this entry will vary depending on the
bond-id. If bonding is configured and characteristics of the bond are not changing, the
ifcfg-ETH files should not need modification.
where ETH can be eth0, eth1, eth2, eth3, or bond0 (two ports bonded for
failover redundancy).
STARTMODE=onboot
BOOTPROTO=none
USERCONTROL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
f. /etc/sysconfig/network/ifcfg-bond0
STARTMODE=onboot
BOOTPROTO=static
IPADDR=IP-ADDR
IPADDR_0=IP-ADDR_0
NETMASK=NETMASK-IP
BONDING_MASTER=yes
BONDING_SLAVE0=ETH0
BONDING_SLAVE1=ETH2
BONDING_MODULE_OPTS="primary=eth0"
where IP-ADDR is the IPv6 address (including /64 netmask suffix) associated with
this bond, IP-ADDR_0 is the IPv4 address associated with this bond, NETMASK-IP is
the IPv4 netmask associated with the IPv4 address, and ETH0 and ETH2 are the
slaves of this bond.
Note: If you have additional bonds, as described in Configuration procedure for SLES
platforms using dual stack addressing (Avamar 7.x only) (page 25), you need to repeat
steps e and f for their respective configuration files.
g. If you are changing the names or IP addresses on a VLAN (in the IPv4 stack only),
you must also configure the VLAN-specific ifcfg files in
/etc/sysconfig/network/ifcfg-bond0.VLAN-ID, where VLAN-ID is the id of the VLAN,
for example:
/etc/sysconfig/network/ifcfg-bond0.123
/etc/sysconfig/network/ifcfg-bond0.222
/etc/sysconfig/network/ifcfg-bond0.333
The following is example content of the ifcfg-bond0.123 file:
STARTMODE=onboot
BOOTPROTO=static
IPADDR=IP-ADDR
NETMASK=NETMASK-IP
ETHERDEVICE=bond0
VLAN_ID=123
where IP-ADDR is the IP address of bond0 for this particular VLAN, and NETMASK-IP
is the netmask associated with the IP address.
5. Set the default gateway in the /etc/sysconfig/network/routes file:
default GATEWAY-IP - -
where GATEWAY-IP is the IP address (either IPv4 or IPv6) of the default gateway
associated with the primary bond or network interface.
Note: The above example only shows a default gateway. Besides the mandatory default,
the /routes file may contain additional static destination network routes. For example:
2000::13 2620:0:170:588::1 - -
10.12.12.0/24 10.6.98.1 - -
6. Ensure that you are still logged into the Avamar server as root.
7. Switch to admin user by typing the following:
su - admin
10. In order to properly apply the new network settings, you must reboot the server by
entering:
touch /fastboot
reboot
where HOSTNAME is the hostname of each node rebooted in step 6 of this procedure.
18. Change the following Avamar files:
a. Modify the probe.xml file to update node IP addresses by typing the following
command for each changed node:
nodedb update if --addr=OLD-IP --new-addr=NEW-IP
where OLD-IP and NEW-IP are the old and new IP addresses for the node.
Repeat for each node for which the IP address was changed.
b. To verify these changes, type the following command:
nodedb print
c. Modify the probe.xml file to update node hostname by typing the following
command:
nodedb update module --index=0 --new-name=NEWNAME
where NEWNAME is the hostname for either the single node server or the utility
node of a multi-node server.
d. If the interface configured in step (a) was configured for NAT and NAT information
has changed, go to step (e). Otherwise, go to step 16.
IMPORTANT
If applicable to the system you are reconfiguring, do steps e through g that follow only for
the IPv4 stack.
If you have more than one NAT rule for the interface, append as many
",INITIAL=TARGET" options to this command as required.
f. To verify these changes, type the following command:
nodedb print
g. Update the specific interface with an updated pair by typing the following
command:
nodedb update if --addr=IP --new-nat=INITIAL=TARGET
where IP is the same as NEW-IP in step (a). If you have more than one NAT rule for
the interface, append as many ",INITIAL=TARGET" options to this command
as required.
h. To verify these changes, type the following command:
nodedb print
Skip to Post Configuration Procedure (page 52). Afterwards, if the IP address of the
internal network switches must be changed, go to Procedure for changing the IP address
on Allied Telesis internal network switches (Gen4 and Gen4S only) (page 41) or Procedure
for changing the IP address on Brocade internal network switches (Gen4S only) (page 46),
depending on the switch type.
The Change Network Settings workflow supports a limited number of use cases related to
network reconfiguration in three general scenarios:
◆ In-place without a physical move
◆ Prior to a physical move
◆ After a physical move
Factor Supported
Factor Unsupported
For each use case the workflow does not support, you must use the manual procedures
described in this technical note. Begin with How to proceed (page 7).
Replication
If you reconfigured network settings on an Avamar server that is a replication source, you
must reregister replication under /MC_SYSTEM. See Replication-related post
configuration procedure (Avamar 7.x only) (page 60) for instructions.
If you reconfigured network settings on an Avamar server that is a replication target, you
must update the IP address of the target on the source Avamar server. For instructions,
see “Editing a replication destination” in the EMC Avamar Adminstration Guide.
Backup Clients
If you used the workflow to reconfigure only backup IP addresses (not hostnames) on an
Avamar server and all clients backing up data to the server were originally registered via
server hostname, no further steps are required. The same is true for the opposite
scenario: You reconfigured only hostnames on the server and all clients were originally
registered via server IP address.
Any scenario in which a) the method for originally registering clients (IP address or
hostname of the Avamar server) and b) the aspect of the Avamar server you reconfigured
with the workflow match, you must update all clients backing up data to the Avamar
server with the new IP address or hostname of the Avamar server. For client-side
registration instructions for each supported operating system, see the EMC Avamar
Backup Clients User Guide.
Note: In large enterprises with many clients, the customer instead might consider doing an
IP/hostname redirect function on the DNS resolver between clients and Avamar server.
Since the topology of any given customer site is unknowable, the customer system
administrator is responsible for knowing how to do this.
If EMS is used to manage multiple Avamar systems, you must update the EMS with the
changed IP address of the server. For instructions, see “Adding an Avamar system in
Avamar Enterprise Manager” in the EMC Avamar Adminstration Guide.
If ADS was originally installed, you must update the hosting Windows computer with the
new IP address of the Avamar server. For instructions, see “Configuring the Avamar
Downloader Service” in the EMC Avamar Adminstration Guide.
Mail Server
If the reconfigured Avamar system was not moved or was moved to a location that uses
the same mail server, no futher steps are required.
If the reconfigured Avamar system was moved to a new location that requires a mail
server hostname change, you must reconfigure ConnectEMC and EmailHome to use the
new hostname of the mail server. For instructions, see “Automatic notifications to EMC
Customer Support” in the EMC Avamar Adminstration Guide.
Accelerator Node
If the Avamar server probe.xml file did not contain an accelerator node object before
running the Change Network Settings workflow, no further steps are required.
If the probe.xml file did contain an accelerator node object pre-workflow, you must add
that object back in the file with the following command (as root user):
To confirm the addition in probe.xml, use the nodedb print command and search for
information similar to the following sample screen output (should appear near the bottom
of the file):
<node type="accelerator">
<network-interface id="1">
<address value="10.471.2.5"/>
</network-interface>
</node>
If reconfiguration of the internal switches is required, see either Procedure for changing
the IP address on Allied Telesis internal network switches (Gen4 and Gen4S only) (page
41) or Procedure for changing the IP address on Brocade internal network switches (Gen4S
only) (page 46), whichever is appropriate.
Interface Deletion
If you did not use the workflow to delete any interfaces, no further steps are required.
If you used the workflow to delete a management interface on a single node Avamar
server, some configuration cleanup is required.
Also, as noted above, the workflow does not support removal of a dedicated replication
interface on a single node Avamar server. This requires a manual process.
See the appropriate subsection below for multi-node replication and management
interface clean up, single node management interface clean up, or single node replication
removal.
To clean up after running the workflow to remove a replication interface, you must perform
the following manual steps:
Files to be modified
◆ /etc/sysconfig/network/ifcfg-bond2
◆ /etc/sysconfig/network/ifcfg-eth4
◆ /etc/sysconfig/network/ifcfg-eth6
◆ /etc/modprobe.conf.local
1. As root user, remove the /etc/sysconfig/network/ifcfg-bond2 file if it still exists.
a. Confirm whether it still exists by typing:
ls /etc/sysconfig/network/ifcfg-bond2
5. Remove the alias line for bond2 bonding and change max_bonds (if it appears in the
file) to reflect new number of bonds.
The resulting file content would be similar to the following:
#
# please add local extensions to this file
#
options bonding max_bonds=3 mode=active-backup miimon=100
updelay=2000
alias bond0 bonding
alias bond1 bonding
alias bond3 bonding
6. Save changes.
7. Restart network by typing:
service network restart
To clean up after running the workflow to remove a management interface, you must
perform the following manual steps:
Files to be modified
◆ /etc/sysconfig/network/ifcfg-bond3
◆ /etc/sysconfig/network/ifcfg-eth5
◆ /etc/sysconfig/network/ifcfg-eth7
◆ /etc/modprobe.conf.local
1. As root user, remove the /etc/sysconfig/network/ifcfg-bond3 file if it still exists.
a. Confirm whether it still exists by typing:
ls /etc/sysconfig/network/ifcfg-bond3
3. Save changes.
b. Save changes.
5. To ensure bond3 is removed, open the /etc/modprobe.conf.local file with a text editor.
The file contains content similar to the following:
#
# please add local extensions to this file
#
options bonding max_bonds=4 mode=active-backup miimon=100
updelay=2000
alias bond0 bonding
alias bond1 bonding
alias bond2 bonding
alias bond3 bonding
6. Remove the alias line for bond3 bonding and change max_bonds (if it appears in the
file) to reflect new number of bonds.
The resulting file content would be similar to the following:
#
# please add local extensions to this file
#
options bonding max_bonds=3 mode=active-backup miimon=100
updelay=2000
alias bond0 bonding
alias bond1 bonding
alias bond2 bonding
7. Save changes.
8. Restart network by typing:
service network restart
Single node server management interface clean up
To remove a replication interface on a single node server, you must perform the following
manual steps:
Note: This section relies on the following sample data: hostname - replication-test, IP
address - 1.2.3.4.
Files to be modified
◆ /etc/hosts
◆ /etc/ssh/sshd_config
◆ /etc/sysconfig/network/ifcfg-eth1
◆ /usr/local/avamar/var/probe.xml
◆ /usr/local/avamar/var/dpnnetutil.xml
1. As root user, stop the Avamar subsystem by typing:
dpnctl stop
• /etc/ssh/sshd_config
Remove the IP address that corresponds to the replication interface (1.2.3.4 in the
example below) in a line similar to the following and then save changes:
Match Address ::1,10.20.5.4,1.2.3.4
• /etc/sysconfig/network/ifcfg-eth1
Remove all entries except "STARTMODE=onboot". If "STARTMODE=onboot" is not in
the file, add it. Save changes.
• /usr/local/avamar/var/probe.xml
Example:
...
<uses allow="management,internal,backup"/>
</network-interface>
<network-interface id="2" userinput_bonded=""
userinput_ifname="eth1">
<address value="1.2.3.4" userinput_netmask="255.255.255.0"
newuserinput_value="1.2.3.4"
userinput_customhostname="replication-test.example.com"/>
<uses allow="replication"/>
</network-interface>
Search for an instance of "network-interface" that contains a "uses allow" value set to
"replication" and remove the entire entry (see below) from the file.
<network-interface id="2" userinput_bonded=""
userinput_ifname="eth1">
<address value="1.2.3.4" userinput_netmask="255.255.255.0"
newuserinput_value="1.2.3.4"
userinput_customhostname="replication-test.example.com"/>
<uses allow="replication"/>
</network-interface>
Add "replication" to the “uses allow” element of bond0 (see example below).
<?xml version="1.0" encoding="UTF-8"?>
<dpn>
<module name="example" userinput_gateway="10.20.5.4"
userinput_domain="example.com" userinput_search="example.com"
userinput_pns="10.10.10.10" userinput_sns="10.10.10.11">
<node type="single-node server" userinput_gateway="10.20.5.1">
<network-interface id="1" userinput_ifname="bond0"
userinput_bonded="eth0,eth2">
<address value="10.20.5.4" userinput_netmask="255.255.255.0"
newuserinput_value="10.20.5.4"
userinput_customhostname="example.example.com"/>
<uses allow="internal,backup,management,replication"/>
</network-interface>
</node>
</module>
Save changes.
• /usr/local/avamar/var/dpnnetutil.xml
Example:
...
<uses allow="management,internal,backup"/>
</network-interface>
<network-interface id="2" userinput_bonded=""
userinput_ifname="eth1">
<address value="1.2.3.4" userinput_netmask="255.255.255.0"
newuserinput_value="1.2.3.4"
userinput_customhostname="replication-test.example.com"/>
<uses allow="replication"/>
</network-interface>
...
Search for an instance of "network-interface" that contains a "uses allow" value set to
"replication" and remove the entire entry (see below) from the file.
<network-interface id="2" userinput_bonded=""
userinput_ifname="eth1">
<address value="1.2.3.4" userinput_netmask="255.255.255.0"
newuserinput_value="1.2.3.4"
userinput_customhostname="replication-test.example.com"/>
<uses allow="replication"/>
</network-interface>
Add "replication" to the “uses allow” element of bond0 (see example below).
<?xml version="1.0" encoding="UTF-8"?>
<dpn>
<module name="example" userinput_gateway="10.20.5.4"
userinput_domain="example.com" userinput_search="example.com"
userinput_pns="10.10.10.10" userinput_sns="10.10.10.11">
<node type="single-node server" userinput_gateway="10.20.5.1">
<network-interface id="1" userinput_ifname="bond0"
userinput_bonded="eth0,eth2">
<address value="10.20.5.4" userinput_netmask="255.255.255.0"
newuserinput_value="10.20.5.4"
userinput_customhostname="example.example.com"/>
<uses allow="internal,backup,management,replication"/>
</network-interface>
</node>
</module>
</dpn>
Save changes.
3. Restart eth1 by typing:
ifdown eth1; ifup eth1
Procedure for changing the IP address on Allied Telesis internal network switches
(Gen4 and Gen4S only)
IMPORTANT
Use the steps in this section only if you wish to change the IP address on an internal
Avamar network switch, and only if that switch is an Allied Telesis model. For Brocade
switches, see Procedure for changing the IP address on Brocade internal network switches
(Gen4S only) (page 46). This section is only applicable to Avamar systems running the
SLES operating system on Avamar Data Store Gen4 or Gen4S hardware. Also, the Avamar
internal switches accept only IPv4 addresses.
This section relies on the internal Avamar network having been configured by default
during installation and using subnet 192.168.255.0/24.
Switch A IP address: 192.168.255.200
Switch B IP address: 192.168.255.201
Switches use default login: manager, password: friend
This is important because, during this procedure, the internal network is intermittent
and goes down completely at times.
3. Consult with the customer network administrator for the new subnet for internal
network.
Example: 172.16.0.0/16 (netmask 255.255.0.0), new Switch A IP address
172.16.0.200/16, new Switch B IP address 172.16.0.201/16, utility node IP address
172.16.0.1/16.
4. Install atftpd on the utility node by typing the following:
rpm -ivh /usr/local/avamar/src/atftp-0.7.0-135.6.x86_64.rpm
Preparing... ###########################################
[100%]
package atftp-0.7.0-135.6.x86_64 is already installed
5. Use scp to copy the default switch configuration files (avg4_swa.cfg, avg4_swb.cfg) to
/usr/local/avamar/src/ on the utility node.
6. Modify both switch configuration files, updating the IP address and netmask in the
files.
Example for switch B:
set system name=avg4_swb
create switch trunk=1 port=21-22 speed=1000m
enable ip
add ip int=vlan1 ip=172.16.0.201 netmask=255.255.0.0
Best practice, as shown in the example, is to include the current IP address in the
filename.
10. Load the new switch config file.
Example for switch B:
load meth=tftp server=192.168.255.1 destfile=avg4_swb.cfg
file=avg4_swb.cfg
BONDING_MODULE_OPTS="primary=eth0"
18. Follow instructions in Reconfiguring the Avamar firewall (Avamar 7.x only) (page 61)
and then return to step 19.
19. Ensure you can ping internal switches again with the new IP addresses by typing the
following:
ping 172.16.0.201
20. Repeat steps 16 through 19 for all nodes of the system, sequentially incrementing IP
addresses.
IPADDR=172.16.0.2, IPADDR=172.16.0.3, IPADDR=172.16.0.4 ... etc.
To ssh to the nodes of the Avamar system, use the corresponding backup IP addresses
from /etc/hosts file because internal IP addresses are not available at this point.
Using /usr/local/avamar/var/probe.xml
(0.s) ssh -x [email protected] 'date'
Thu Feb 16 10:12:28 PST 2012
(0.0) ssh -x [email protected] 'date'
Warning: Permanently added '172.16.0.2' (RSA) to the list of known
hosts.
Thu Feb 16 18:12:28 UTC 2012
(0.1) ssh -x [email protected] 'date'
Warning: Permanently added '172.16.0.3' (RSA) to the list of known
hosts.
Thu Feb 16 18:12:28 UTC 2012
(0.2) ssh -x [email protected] 'date'
Warning: Permanently added '172.16.0.4' (RSA) to the list of known
hosts.
Thu Feb 16 18:12:29 UTC 2012
27. Copy the file /etc/hosts to the same location on all nodes of the Avamar system.
28. Type the following command with no wrapping or modifications:
for a in `nodedb print --nodes=all+ --addr --internal`; do tar -cz
/etc/hosts | ssh root@$a 'tar --overwrite -xzf - -C /'; done;
Procedure for changing the IP address on Brocade internal network switches (Gen4S
only)
IMPORTANT
Use the steps in this section only if you wish to change the IP address on an internal
Avamar network switch, and only if that switch is a Brocade model. For Allied Telesis
switches, see Procedure for changing the IP address on Allied Telesis internal network
switches (Gen4 and Gen4S only) (page 41). This section is only applicable to Avamar
systems running the SLES operating system on Avamar Data Store Gen4S hardware. Also,
the Avamar internal switches accept only IPv4 addresses.
This section relies on the internal Avamar network having been configured by default
during installation and using subnet 192.168.255.0/24.
Switch A IP address: 192.168.255.200
Switch B IP address: 192.168.255.201
Switches use default login: manager, password: ally24X7
This is important because, during this procedure, the internal network is intermittent
and goes down completely at times.
3. Consult with the customer network administrator for the new subnet for internal
network.
Example:
Switch A: 10.10.10.200/24
Switch B: 10.10.10.201/24
Utility node internal IP address: 10.10.10.1
4. Telnet to the switch A (192.168.255.200), password default is ally24X7.
telnet 192.168.255.200
c. Set the ip address by typing the following (new IP address used is an example):
ip address 10.10.10.200/24
If this freezes, use "CTRL" + "}" then “CTRL” + “D” to exit the connection.
5. Telnet to switch B (192.168.255.201), password default is ally24X7
telnet 192.168.255.201
c. Set the ip address by typing the following (new IP address used is an example):
ip address 10.10.10.201/24
If this freezes, "CTRL" + "}" then “CTRL” + “D” to exit the connection.
BONDING_MODULE_OPTS="primary=eth1"
e. Save changes
f. Run "nodedb print" to ensure no tags/brackets were accidentally removed
If "nodedb print" fails, either debug and relook at probe.xml to locate any missing
tags/brackets, or start with a fresh copy by copying
/usr/local/avamar/var/ORIG.probe.xml back to /usr/local/avamar/var/probe.xml
and repeat step 10.
8. Modify the entries in dpnnetutil.xml to reflect new IP address' subnet:
a. Make a copy of the original dpnnetutil.xml by typing the following all on one
command line:
cp /usr/local/avamar/var/dpnnetutil.xml
/usr/local/avamar/var/ORIG.dpnnetutil.xml
e. Save changes.
9. Ensure the mapall command works with the new internal IP addresses by typing the
following:
ssh-agent bash
ssh-add /home/dpn/.ssh/dpnid
mapall --all+ date
Using /usr/local/avamar/var/probe.xml
(0.s) ssh -x [email protected] 'date'
Mon Dec 1 08:29:24 PST 2014
(0.0) ssh -x [email protected] 'date'
Warning: Permanently added '10.10.10.2' (RSA) to the list of known
hosts.
Mon Dec 1 16:29:24 UTC 2014
(0.1) ssh -x [email protected] 'date'
Warning: Permanently added '10.10.10.3' (RSA) to the list of known
hosts.
Mon Dec 1 16:29:24 UTC 2014
(0.2) ssh -x [email protected] 'date'
Warning: Permanently added '10.10.10.4' (RSA) to the list of known
hosts.
Mon Dec 1 16:29:24 UTC 2014
10. With a text editor, edit /etc/hosts file on the utility node.
Update the IP addresses in the rows related to internal network hostnames and save
changes. Example:
10.10.10.1 avamarsrv-internal
10.10.10.2 avamarsrvd1-internal
10.10.10.3 avamarsrvd2-internal
10.10.10.4 avamarsrvd3-internal
11. Copy the /etc/hosts file from the utility node to the same location on all the nodes of
the Avamar system by typing the following all on one line:
`nodedb print --nodes=all+ --addr --internal`; do tar -cz /etc/hosts
| ssh root@$a 'tar --overwrite -xzf - -C /'; done;
12. Telnet to Switch A using its new IP address (example: 10.10.10.200), password
default is ally24X7.
telnet 10.10.10.200
Example output:
Switch IP address: 10.10.10.200
Subnet mask: 255.255.255.0
Default router address: None
TFTP server address: None
Configuration filename: None
Image filename: None
IP MTU: 1500
13. Telnet to Switch B using its new IP address (ex: 10.10.10.201), password default is
ally24X7.
telnet 10.10.10.201
Example output:
Switch IP address: 10.10.10.201
Subnet mask: 255.255.255.0
Default router address: None
TFTP server address: None
Configuration filename: None
Image filename: None
IP MTU: 1500
7. When prompted for a password, type the password and press ENTER.
8. Type the following command:
asktime
Note: The following example asktime prompts and user responses are the suggested
ones for most sites. However, some customer configurations might require different
responses. Contact EMC Technical Support for additional information. Also, for those
asktime prompts calling for an IP address, either IPv4 or IPv6 addresses are valid.
If you are upgrading an existing Avamar server, asktime detects the previous NTP
settings and prompts you as follows:
Do you want to make use of your previous answers?
(You will be given the chance to review and to change them.) y(es),
n(o), q(uit/exit):
a. Type y and press ENTER to accept the previous settings as default settings for the
remainder of this asktime session.
The following appears in your command shell:
Are external time servers available?
If Do this
IMPORTANT
The Microsoft Windows W32Time service (the NTP service on domain controllers) does not
meet the multi-node system requirement that all times must be within one second of one
another. For that reason, W32Time cannot be used for NTP purposes. For more
information, see the Microsoft knowledgebase article in the following location:
http://support2.microsoft.com/kb/939322
then the lockbox is in use and you need to update your lockbox passphrase. Proceed
to step 12.
IMPORTANT
If the command does not return any files, then the lockbox is not in use. Proceed to step
14.
16. Modify the systemname parameter after starting the server by entering:
avmaint config --avamaronly systemname="NEWNAME"
where SERVER-IP-ADDR is the Avamar utility node or server IP address for multi-node
and single-node servers, respectively. If an internal network has been configured,
then SERVER-IP-ADDR is the internal IP address of the utility node.
For single node Avamar servers, the SERVER-IP-ADDR is always 127.0.0.1 no matter
whether the server is configured for IPv4 or IPv6 use.
IMPORTANT
If the Avamar system is configured as dual stack (IPv4 and IPv6 addressing),
SERVER-IP-ADDR must be the IPv4 address.
This step asks for the most recent hostname of the Avamar server.
This step also updates the system address in the mcserver.xml file.
20. Type the Avamar server hostname or IP address and press ENTER.
The following appears in your command shell:
Enter the Avamar Server IP port to restore from [27000]:
Note: In the steps that follow, replace NODENAME with the name of the Avamar server (for
single-node servers) or the utility node (for multi-node servers).
22. Type the correct MCUser account password (MCUser1 on new systems) for the original
Avamar server and press ENTER.
The following appears in your command shell:
Select the Avamar server IP address or fully qualified host name to
be used by backup clients:
1) NODENAME.example.com
2) Enter another address
Note: Steps 23 through 24 ask for the hostname and IP address of the new Avamar server.
If Do this
The Avamar server will use a Type the number of the specified hostname (for
specified hostname. example, 1) and press ENTER.
The Avamar server will use a Type the number that corresponds to the option
hostname that is not specified "Enter another address" (for example, 2) and press
as a pre-defined choice. ENTER.
24. If you are configuring an Avamar system that uses an internal network, type the utility
node’s internal network hostname and press ENTER. Otherwise, type the Avamar
server IP address or fully qualified hostname to be used for Avamar Administrator
server and press ENTER.
The following appears in your command shell:
'NODENAME.example.com' resolvable and pingable from MCS node.
Enter the IP port used to communicate with the Avamar Server [27000]:
Enter the Avamar server accounting system root user password for
Avamar server NODENAME.example.com:
27. Type the Avamar server accounting system root user password (8RttoTriz on new
systems) and press ENTER.
The following appears in your command shell:
mcserver.xml file updated.
Performing restore administrative tasks...
Enter the Avamar server accounting system MCUser user password for
Avamar server NODENAME.example.com:
28. Type the Avamar server accounting system MCUser user password (ask the system
administrator for this) and press ENTER.
Output similar to the following appears in your command shell:
mcserver.xml file updated.
encrypting passwords for (MCUSERAP|rootAP) in file
/usr/local/avamar/var/mc/server_data/prefs/mcserver.xml ...
encrypting preferences (MCUSERAP|rootAP) for mask
/usr/local/avamar/var/mc/server_data/prefs ...
see MCCipher log for details:
/usr/local/avamar/var/mc/server_log/mccipher.log.0
Performing restore administrative tasks...
restore : Closing DB Connections
Restore administrative tasks complete.
Timestamp of flush restored: 2014-12-05 17:27:40 PST
34. Reinitialize the Avamar Administrator command line interface tool by entering:
avsetup_mccli
35. Press ENTER each time the user is prompted for a response.
36. For Avamar 4.x or 5.0.x, remove the following files by entering:
rm /root/.avamardata/var/mc/cli_data/prefs/mcclimcs.xml
rm /data01/home/dpn/.avamardata/var/mc/cli_data/prefs/mcclimcs.xml
rm
/data01/home/admin/.avamardata/var/mc/cli_data/prefs/mcclimcs.xml
41. All clients must be reactivated with the new Avamar server name.
If possible, connect to the network and run the Avamar Administrator in order to locate
and verify the active (or not active) status of these clients. If they show active,
de-activate them.
42. Start desktop/laptop by entering:
dpnctl start dtlt
IMPORTANT
Do the following procedure on all Avamar systems running Avamar 7.x for all re-IP and
re-hostname scenarios, and for systems using either cron-based or policy-based
replication.
To re-enable replication:
1. In Avamar Administrator, click the Administration launcher button.
The Administration window appears.
2. Click the Account Management tab.
3. Select the MC_SYSTEM domain in the top left panel.
4. Select the replication client in the bottom left panel.
5. Select Actions > Account Management > Edit Client.
The Edit Client dialog box appears.
6. Change the client name to the new fully-qualified domain name.
7. Click OK.
8. Click the Policy launcher button at bottom left.
The Policy window appears.
9. Click the Clients tab.
10. Select the MC_SYSTEM domain in the left panel.
11. Select the replication client in the right pane.
Firewall hardening was introduced as an optional feature in Avamar 7.0, and it was made
mandatory for Avamar 7.1 installations. Use the following procedure as appropriate for
the version of Avamar software on the system whose IP addressing has been
reconfigured.
1. Open a command shell on the utility node or single node Avamar server.
2. Log into the server as user admin.
3. When prompted for a password, type the admin password and press ENTER.
4. Load the admin OpenSSH key by entering:
ssh-agent bash
ssh-add ~admin/.ssh/admin_key
7. On Avamar 7.0.x systems (otherwise, continue with step 8), enter the following:
rpm –q avfwb
If avfwb is installed, continue with step 8 (otherwise, skip to Configuring the Avamar
Downloader Service (page 63)):
8. Update the firewall IP tables on each node (utility and storage, or single node server)
by entering the following:
sh /usr/local/avamar/lib/admin/security/sec_create_nodeips.sh
If the script fails to operate, edit the /etc/firewall-ips file manually in a text editor. The
following is an example of the file contents.
UTILITY=10.25.92.30
OTHER_IPS="10.25.92.31 10.25.92.32 10.25.92.33"
INTERNAL_IPS="192.168.255.1 192.168.255.2 192.168.255.3
192.168.255.4"
11. Replace the IP address (10.241.238.240 in the example) with the server’s new IP
address.
12. Save the file and close the editor.
13. Load the admin OpenSSH key by entering:
ssh-agent bash
ssh-add ~admin/.ssh/dpnid
16. Restart the sshd service on all nodes by entering the following:
mapall --all --noerror --user=root service sshd restart
IMPORTANT
Do not make any changes to the FTP username and password credentials. If you make
changes to the FTP username or password, you must reinstall the Avamar Downloader
Service to recover these credentials.
3. Accept the default FTP username and password, and then click Next.
The Avamar Systems page appears.
4. Click Add.
The Avamar Downloader Service - Add Known System dialog box appears.
5. Complete the settings as described in the following table:
Setting Description
6. Click OK.
Click Next.
Click Finish.
Other Considerations
Mail server
If the hostname of your mail server has changed, you need to reconfigure ConnectEMC
and Email Home to use the new hostname of the mail server. Refer to the EMC Avamar
Administration Guide for procedures to change the hostname of the mail server for
ConnectEMC and Email Home.
Client access for DDBOOST is configured in the Data Domain Command Line Interface, via
ssh, or from the Data Domain Enterprise Manager, via HTTP. A resolvable client name or IP
address must be provided. Best practice is to use the fully-qualified domain name for the
client, or an asterisk can be used to allow any client to access the /backup/ost path. If the
name of the Avamar server has changed and the previous name is configured as a client
on the Data Domain server, you will need to change this information using either the Data
Domain Command Line Interface or the Data Domain Enterprise Manager. The Data
Domain documentation provides details.
Procedure
First, you must prepare the server by shutting down the Avamar software as follows:
1. As user admin, open a command shell.
2. Log into the server as user admin.
3. When prompted for a password, type the admin password and press ENTER.
where IP-ADDR is the IP address of bond0 for this particular VLAN, and NETMASK-IP is
the netmask associated with the IP address.
3. If adding more than one VLAN interface, repeat steps 1 and 2 adjusting the VLAN_ID,
IPADDR, and NETMASK fields accordingly.
4. Restart network services:
service network restart
where IP-ADDR is the IP address of bond0 for this particular VLAN, and NETMASK-IP is
the netmask associated with the IP address.
3. If adding more than one VLAN interface, repeat steps 1 and 2 adjusting the VLAN_ID,
IPADDR, and NETMASK fields accordingly.
4. Add an entry to the /etc/hosts file for any new VLAN interfaces defined:
127.0.0.1 localhost.localdomain localhost
10.0.44.5 avamar1.example.com avamar1 #utility
10.0.44.6 avamar2.example.com avamar2 #data
10.0.44.7 avamar3.example.com avamar3 #data
VLAN-IP-ADDR1 avamar1-4000.example.com avamar1-4000 # utility VLAN
4000
VLAN-IP-ADDR2 avamar2-4000.example.com avamar2-4000 # data VLAN
4000
VLAN-IP-ADDR3 avamar3-4000.example.com avamar3-4000 # data VLAN
4000
10.0.55.10 avamar6.example.com avamar6 #spare
where VLAN-IP-ADDR 1-3 is the unique IP address associated with the specific data
node for the VLAN.
Note: Depending on the environment, hostname schemes may differ. The above example
uses the suffix "4000" to indicate a hostname associated with a VLAN with ID 4000.
IMPORTANT
When configuring multi-node systems, the
/etc/hosts file should be identical on all nodes in the system.
5. Load ssh keys and copy the modified /etc/hosts file to all other nodes in the Avamar
server.
For instance, use the following command:
scp /etc/hosts root@STORAGENODE1:/etc/hosts
Note: On a multi-node grid, the output will contain entries for each node and the defined
interfaces therein.
where:
Token Description
NODE_ID Is the physical node ID associated with the node being added.
Starting with version 5.0, some or all Avamar clients can access Avamar storage nodes by
using a set of addresses that undergo NAT. To make NAT information known to the Avamar
server, the probe.xml file must contain nat-address elements for storage nodes. After a
client makes initial contact with the Avamar server’s utility node, the Avamar server
provides a set of routable addresses for the storage nodes to each client. In the absence
of a nat-address element, a client uses a pre-configured “real” (untranslated)
network-interface address.
The following instructions explain how to set up the probe.xml file (node resource
database) to enable the Avamar server to use NAT. These instructions assume that each
Avamar node has a unique address (from the Avamar clients’ perspective), and that you
configure a router on the network to apply transparent one-to-one network address
translation. You can also use these instructions to enable NAT for use in a single-node
server configuration.
Note: Setting up the hardware for NAT is beyond the scope of this guide.
Procedure
To configure Avamar to use NAT:
1. Add NAT addresses to probe.xml with the nodedb command.
An example command using nodedb:
nodedb update if --addr=10.6.250.87 --new-nat=INITIAL=TARGET
where INITIAL is the NAT utility node IP address and TARGET is the NAT storage node IP
address.
• For multi-node Avamar servers, add an entry for each storage node (for instance,
for a 1x4 server, you must add four entries to probe.xml).
• For single node Avamar servers, add only one entry. Also, INITIAL and TARGET IP
addresses will be the same.
The nodedb command updates an existing network interface element in the probe.xml
file with NAT information that corresponds to the example diagram shown on the
previous page.
3. If the Avamar storage subsystem is currently running, re-read the probe.xml file by
typing:
avmaint networkconfig /usr/local/avamar/var/probe.xml --avamaronly
Problem Solution
Server/client connection fails. Use network diagnostic tools such as ping, traceroute, tracert,
or iperf to verify network connectivity.
For Avamar 7.x software running on Gen4/Gen4S hardware, there are several
configuration options. Networking files that require modification will vary depending on
the specific configuration. The networking files are located in
/etc/sysconfig/network/. Configuration options include:
◆ Single node or AVE systems
◆ Multinode systems
• eth0 and eth2 configured as slaves to bond0
Reserved for backup.
• eth1 and eth3 configured as slaves to bond1
For internal traffic.
• eth4 and eth6 configured as slaves to bond2
Reserved for optional replication on the utility node.
• eth5 and eth7 configured as slaves to bond3
Reserved for optional management on utility node.
◆ VLAN configuration (for IPv4 stack only)
• bond0.VLAN-IDs
Optional multiple-tagged backup networks.
Procedure
1. Shut down the Avamar software.
a. As user admin, open a command shell.
b. Log into the server as user admin.
c. When prompted for a password, type the admin password and press ENTER.
d. Load the admin OpenSSH key by entering:
ssh-agent bash
ssh-add ~admin/.ssh/admin_key
IMPORTANT
When configuring multi-node systems,
/etc/hosts and /etc/resolv.conf should be identical on all nodes in the system.
a. /etc/resolv.conf
domain local.example.com
search local.example.com company.com
nameserver NAMESERVERIP
Note: The above example only shows a single nameserver. The /resolv.conf file may
contain additional nameservers. For example:
domain local.example.com
search local.example.com company.com
nameserver 10.6.254.4
nameserver 10.6.254.5
nameserver 2620:0:170:58e::4
The first two are IPv4 addresses, the last one is IPv6.
IMPORTANT
Regarding step 3(b) and 3(c) below, when changing IP addresses in dual-stack
configurations, EMC strongly recommends you also provide a unique hostname for each
changed IPv6 IP address. This can be accomplished by creating unique hostnames or
subdomains like the following examples:
hostname.domain.local (IPv4)
hostname6.domain.local (IPv6)
hostname.domain.local (IPv4)
hostname.ipv6.domain.local (IPv6)
where each token IP is either a valid IPv4 or IPv6 address for each component.
c. /etc/hosts on multi-node servers
UTILITYIPV4 avamar1v4.example.com avamar1v4 #utility
DATA1IPV4 avamar2v4.example.com avamar2v4 #data
DATA2IPV4 avamar3v4.example.com avamar3v4 #data
DATA3IPV4 avamar4v4.example.com avamar4v4 #data
DATA4IPV4 avamar5v4.example.com avamar5v4 #data
SPAREIPV4 avamar6v4.example.com avamar6v4 #spare
UTILITYIPV6 avamar1v6.example.com avamar1v6 #utility
DATA1IPV6 avamar2v6.example.com avamar2v6 #data
DATA2IPV6 avamar3v6.example.com avamar3v6 #data
DATA3IPV6 avamar4v6.example.com avamar4v6 #data
DATA4IPV6 avamar5v6.example.com avamar5v6 #data
SPAREIPV6 avamar6v6.example.com avamar6v6 #spare
UTILITYINTIP avamar1-internal #utility internal
DATA1INTIP avamar2-internal #data internal
DATA2INTIP avamar3-internal #data internal
DATA3INTIP avamar4-internal #data internal
DATA4INTIP avamar5-internal #data internal
SPAREINTIP avamar6-internal #spare internal
127.0.0.1 localhost
# special IPv6 addresses
::1 localhost ipv6-localhost ipv6-loopback
fe00::0 ipv6-localnet
ff00::0 ipv6-mcastprefix
ff02::1 ipv6-allnodes
ff02::2 ipv6-allrouters
ff02::3 ipv6-allhosts
where each token IP is either a valid IPv4 or IPv6 address for each component.
Note: Due to space constraints on this page, lines in the above example wrap to the next
line. They should not wrap in the actual file.
Note: If the hostname of the server is changing, you must preserve the naming scheme of
HOST_NAME-internal, where HOST_NAME is the new hostname.
d. /etc/sysconfig/network/routes
cat /etc/sysconfig/network/routes
default GATEWAY-IP - -
where GATEWAY-IP is a valid IPv4 address for the default gateway associated
with the primary bond or network interface.
Note: The example above calls for an IPv4 GATEWAY-IP because that is the most likely
common case. Best practice is: do not change the default gateway protocol; that is, if it is
an IPv4 address before conversion, leave it as as the IPv4 address. This makes IPv4 the
"primary" protocol.
Note: The above example only shows a default gateway. Besides the mandatory default,
the /routes file may contain additional static destination network routes. For example:
2000::13 2620:0:170:588::1 - -
10.12.12.0/24 10.6.98.1 - -
e. /etc/sysconfig/network/ifcfg-bond0
cat /etc/sysconfig/network/ifcfg-bond0
STARTMODE='auto'
BOOTPROTO='static'
IPADDR='192.168.222.44/24'
IPADDR_0='2620:0:170:580::3:2/64'
The IPADDR and IPADDR_0 fields are IPv4 and IPv6 addresses with subnet suffixes
(/24 and /64, respectively). If the current ifcfg-bond0 file displays netmask in
NETMASK=xxx.xxx.xxx.xxx format, convert it to /24 and /64 format. See examples
above.
4. Repeat steps 1a through 1e and steps 2 and 3 for each node on the grid.
5. Using a Unix text editor, edit the probe.xml file.
The following is an example of the probe.xml before changing to dual stack:
<node type="utility" userinput_gateway="10.25.113.1">
<network-interface id="0" userinput_bonded="eth0,eth2"
userinput_ifname="bond0">
<address value="123.25.113.184"
userinput_netmask="255.255.255.0"
newuserinput_value="123.25.113.184"
userinput_customhostname="a4dpn62.default"/>
<uses allow="replication,management,backup"/>
</network-interface>
<network-interface id="1" userinput_bonded="eth1,eth3"
userinput_ifname="bond1">
<address value="192.168.255.1"
userinput_netmask="255.255.255.0"
newuserinput_value="192.168.255.1"
userinput_customhostname="a4dpn62-internal"/>
<uses allow="internal"/>
</network-interface>
</node>
<node type="storage" userinput_gateway="10.25.113.1">
<network-interface id="0" userinput_bonded="eth0,eth2"
userinput_ifname="bond0">
<address value="123.25.113.185"
userinput_netmask="255.255.255.0"
newuserinput_value="123.25.113.185"
userinput_customhostname="a4dpn62d1.default"/>
<uses allow="replication,backup"/>
</network-interface>
<network-interface id="1" userinput_bonded="eth1,eth3"
userinput_ifname="bond1">
<address value="192.168.255.2"
userinput_netmask="255.255.255.0"
newuserinput_value="192.168.255.2"
userinput_customhostname="a4dpn62d1-internal"/>
<uses allow="internal"/>
</network-interface>
</node>
The following is an example of the probe.xml after adding an IPv6 stack, thus creating
a dual stack:
<node type="utility" userinput_gateway="10.25.113.1">
<network-interface id="0" userinput_bonded="eth0,eth2"
userinput_ifname="bond0">
<address value="123.25.113.184"
userinput_netmask="255.255.255.0"
newuserinput_value="123.25.113.184"
userinput_customhostname="a4dpn62.default"/>
<address value="aa:bb:cc:123" userinput_netmask="/64"
newuserinput_value="aa:bb:cc:123"
userinput_customhostname="a4dpn62.v6.default"/>
<uses allow="replication,management,backup"/>
</network-interface>
<network-interface id="1" userinput_bonded="eth1,eth3"
userinput_ifname="bond1">
<address value="192.168.255.1" userinput_netmask="255.255.255.0"
newuserinput_value="192.168.255.1"
userinput_customhostname="a4dpn62-internal"/>
<uses allow="internal"/>
</network-interface>
</node>
<node type="storage" userinput_gateway="10.25.113.1">
<network-interface id="0" userinput_bonded="eth0,eth2"
userinput_ifname="bond0">
<address value="123.25.113.185"
userinput_netmask="255.255.255.0"
newuserinput_value="123.25.113.185"
userinput_customhostname="a4dpn62d1.default"/>
<address value="aa:bb:cc:124" userinput_netmask="/64"
newuserinput_value="aa:bb:cc:124"
userinput_customhostname="a4dpn62.v6.default"/>
<uses allow="replication,backup"/>
</network-interface>
<network-interface id="1" userinput_bonded="eth1,eth3"
userinput_ifname="bond1">
<address value="192.168.255.2" userinput_netmask="255.255.255.0"
newuserinput_value="192.168.255.2"
userinput_customhostname="a4dpn62d1-internal"/>
<uses allow="internal"/>
</network-interface>
</node>
where:
Attribute Definition
b. Modify each additional node object defined in the probe.xml and its attributes.
Use the following as an example of a node object and its attributes:
<node type="utility" userinput_hostname="a4ipn600">
<network-interface id="1" userinput_bonded="eth0,eth2"
userinput_ifname="eth0">
<address newuserinput_value="10.110.227.147"
userinput_customhostname="a4ipn600.example.com"
userinput_netmask="255.255.255.0" value="10.110.227.147"/>
<uses allow="replication,management,backup"/>
</network-interface>
<network-interface id="2" userinput_bonded="eth1,eth3"
userinput_ifname="eth1">
<address newuserinput_value="192.168.255.1"
userinput_customhostname="a4ipn600.example.com"
userinput_netmask="255.255.255.0" value="192.168.255.1"/>
<uses allow="internal"/>
</network-interface>
</node>
where:
Attribute Definition
Attribute Definition
IMPORTANT
Ensure all IPv6 addresses added to the probe.xml file are written in canonic and not full
notation. See examples below for the proper format:
Full: 2620:0000:0170:0588:0000:0000:0001:0024
Canonic: 2620:0:170:588::1:24
Copyright © 2014 EMC Corporation. All rights reserved. Published in the USA.
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without
notice.
The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any
kind with respect to the information in this publication, and specifically disclaims implied warranties of
merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this
publication requires an applicable software license.
EMC2, EMC, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United States and other countries.
All other trademarks used herein are the property of their respective owners.
For the most up-to-date regulatory document for your product line, go to the technical documentation and advisories
section on EMC Online Support.