User guide

Provisioning the iMG/RG Installation Procedures
808
AlliedView NMS Administration Guide
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:
• If the user moves an already provisioned iMG/RG from one iMAP port to another in the same Access Island, the
AlliedView will treat the iMG/RG as new hardware and will de provision and re-provision the RG, using data for that new
port.
• If the user moves the already provisioned iMG/RG from one iMAP port to another in a different Access Island, the
AlliedView NMS won’t see the RG because it is not the correct RGMgmt VLAN (and IP address) for that Access Island.
In this scenario, the user should telnet to the iMG/RG before removing the iMG/RG and set the iMG/RG back to its
factory settings. Then, when moving the iMG/RG to the new port in the different Access Island, DHCP discovery will
start with the RG’s default VLAN and go through the process of finding and then using the RGMgmt VLAN for that new
Access Island.
7.10.3 Pre-provision Future Customer (Provision iMAP Port, no Services)
7.10.3.1 When to use this Procedure
• The administrator wishes to provision the iMAP port with the iMG/RG, and not provision any specific services. (An
example would be for a vacant residence.)
• Services will be added later.
7.10.3.2 Pre-requisite Procedures
Before performing this procedure, the administrator should have already done the following: