User guide

Installation Procedures Overview
AlliedView NMS Administration Guide (Provisioning the iMG/RG)
7-168
7.10 Installation Procedures
7.10.1 Overview
With the use of the AlliedView NMS profiles and DHCP, the installation, reconfiguration, and de-installation of iMGs/RGs
does not involve complex (and therefore error-prone) procedures. These procedures can be grouped into two main areas:
1. Installing, reconfiguring, and removing the iMG/RG using AlliedView NMS
2. Changing an iMG/RG that was not configured using the AlliedView NMS to one that does
In the first area, the initial installation of an iMG/RG (out of the box) includes most of the steps that are needed when reconfig-
uring or removing the iMG/RG, in a different sequence.
A special procedure is the changing of the Customer ID, since certain steps must be followed to ensure the ID has been
changed. Refer to 7.10.10.
Note: The procedures here will assume that the user is performing these procedures for the Access Island.
Whenever there is a change in a step needed to accommodate the open Access model, this change will be
highlighted.
Note: In release 10.0, NMS supports translations on the iMAP ports. For all of the following procedures, if the
procedure includes adding a translation (or translations) to the iMG/RG configuration, the iMAP port profile
that includes the translation must be applied before changes are made to the iMG/RG profiles.
7.10.2 Installation Restrictions
7.10.2.1 Initial and Subsequent “push down” of Configuration Data
When provisioning the RG from the AlliedView NMS, there is the initial sequence of:
1. Pre-provisioning (ports, profiles)
2. Discovery (DHCP)
3. the “pushing down” of the initial configuration data.
It is important to note that once this data is pushed down, subsequent discoveries of the RG by the AlliedView NMS (usually
every 24 hours) do not include a subsequent pushing down of this data if there has been a change in the iMG/RG configuration
since the last discovery. If changes have been made to the iMG/RG configuration (such as a change in profile), the AlliedView
NMS will make only the changes to the iMG/RG necessary to reflect the new configuration.
Note: This is in contrast to other methods (ZTC) where the configuration server stored the iMG/RG configuration.
The iMG/RG would query the ZTC if there had been a change made on the ZTC server; if there had been a
change, the ZTC would reconfigure the iMG/RG and upon reboot the changes would take effect.
Moreover, the behavior of the AlliedView NMS is that if the pushing down of initial configuration data fails (perhaps due to a
network fault), the AlliedView NMS raises an alarm. The user can then:
• Wait 24 hours for the next discovery (or more if there are many devices)
• Perform a manual discovery
In either scenario, the AlliedView NMS will try to push down the configuration data.
The important concept is that the AlliedView NMS does not try to push down the configuration data unless this is for new
hardware. This leads to the next subsection.
7.10.2.2 Moving the iMG/RG to another Port (Re-provisioning)
As explained in 7.1, an administratively efficient way to provision the iMG/RG is by using Access Islands, with each Access
Island having its own unique set of VLANs. This makes moving an iMG/RG from one port to another behave as follows: