|
Routable RPD Provisioning System
A cheaper way to handle Motorola's return data path and managing
RPDs
By: Bruce Bahlmann - Contributing Author (your
feedback
is important to us!)
Created: September 10, 2000
Note: For help designing your provisioning system or developing tools to help test, automate, and deploy your system contact Birds-Eye.Net.
DV6000-Based System
Part of the Motorola digital video delivery
system includes a mechanism to receive data from set top boxes (also called DCTs). This
system requires the use of a Return Path Demodulator (RPD) to convert this data (received
from set top boxes) over to Ethernet to enable it to flow freely across a small Ethernet
segment. The RPD is provisioned onto the Motorola digital video system through the use of
a Headend Configuration Tool (HCT) or a Headend Management System (HMS) as shown in Figure
1.0.
Figure 1.0 Motorola Digital Return Path
Right out of the box, the HCT/HMS can
provision/maintain multiple RPDs via the use of the Bootstrap Protocol (BOOTP) and Trivial
File Transfer Protocol (TFTP). The HCT/HMS use BOOTP to provide each RPD with an IP
address and subnet mask and use TFTP to provide each RPD with one or more boot
(configuration) files. Upon this configuration, the RPD is accessible on the
network.
Unfortunately, the HCT/HMS and RPDs are not
always located in the same facility. This happens when fiber nodes are not terminated in a
central facility (or master headend) but rather in one or more remote distribution hubs.
In this case, RPDs must be located in the distribution hubs that are distant from the
master headend. When this occurs it becomes more difficult (and costly) to maintain the
simplicity of Figure 1.0 (i.e. to keep all RPDs on a subnet local to the HCT/HMS).
Figure 2.0 provides one method of
maintaining the simplicity of Figure 1.0. Here all the RPDs remain on the same subnet as
the HCT/HMS through the use of a 3rd party solution (ADC’s DV6000 network
gear). This equipment, which costs about $20,000 per distribution hub, provides a
transport for remote site data traffic to join data traffic within the master headend.
Figure 2.0 DV6000 Networking gear using multiple Hub sites
Although the DV6000 gear maintains some of
the benefits of Figure 1.0, it has several drawbacks as well. Among those:
·
DV6000 gear is not inherently
fault tolerant – thus any hardware failure in this point-to-point link would cause it
to fail where by disconnecting the remote facility data connection. To make the DV6000
gear fault tolerant requires something called a SAS (which is also made by ADC). The SAS
costs about ~$250,000 and can maintain a limited number of redundant loops (~8).
·
Support -- Most regional
operators use SONET to transport their critical services to the distribution hubs. SONET
therefore receives top priority in terms of maintenance and outage response. Therefore use
of anything but SONET would limit (or further complicate) the care and feeding of this
video service.
·
Cost -- This connectivity method
is more than twice the cost of alternative methods.
·
Broadcast domain – the
DV6000 gear places all the equipment on the same broadcast domain that increases the
number of collisions possible. On a network that uses a lot of User Datagram Protocol
(UDP) traffic this can cause some hard to find network problems.
·
Resource intensive – The
DV6000 gear requires dedicated dark fiber to connect each remote facility. When this dark
fiber is used to create a 100Mb data circuit for a service that uses no more than 10% of a
T1 it would seem the DV6000 gear is overkill. Especially since any the RPDs will never use
more than 1% of the allocated bandwidth. This DV6000 transport must be dedicated to the
RPDs, thus any additional traffic added to this system would require its own dedicated
data path. Therefore any number of RPDs will waste around 99.8464% of the allocated 100Mb
data channel.
Router-Based System
Another way to connect RPDs in remote
distribution hubs is through the use of routers and SONET (see Figure 3.0). Using low cost
routers to connect to the SONET enables one to build a fully redundant data transport.
Each component of this transport is either inherently fault tolerant (has dual power
supplies, and or processors) or has a mirror image of it connected in parallel. The
combination of these can withstand the failure of nearly any one component – this
enables the overall data network to be very reliable, stable, and provide a much needed
foundation on which to build interactive services.
Figure 3.0 Router-Based
System for Interactive Applications
Figure 4.0 shows a slightly scaled back version of Figure 3.0 in that
there are no redundant 2621 routers in the distribution hubs. These have been left out to
save money.
Figure 2.1 Router-Based
System that is Fault Tolerant
The sacrifice for leaving out the second 2621 router in the
distribution hub allows the region to save money and yet easily upgrade to Figure 3.0 as
the need for interactive services places further requirements on the reliability of the
data network.
This system begins with use of Cisco’s
flagship switch product the Catalyst 5500 switch. This unit has dual DC power supplies
connected to both the A & B sides of the headend power source. Failure of one side of
the power source will not cause this switch to halt operation. In addition, the 5500 runs
with two switch processor engines (one running live and the other running stand-by).
Failure of the live switch processor is immediately taken over by the stand-by processor
with no interruption of service. There are only two types of failures that can cause any
amount of downtime on this switch. They are the loss of the chassis or the loss of an
Ethernet interface card. Spreading the connectivity of various devices across several
cards reduces the impact of an interface card failure. Replacement interface cards are
kept on-site to speed the recovery of such a failure*. These cards as will all others
associated with the switch are hot swappable.
*Note
that this is an unavoidable risk, as the devices connecting to the switch do not support a
dual interface. Had they supported a dual interface, two switches could be cross connected
to provide redundant connectivity to each device.
The other type of failure that could be
associated with a 5500 switch would be a chassis failure. This would cause the whole
network to halt*. In the event of a chassis failure a replacement chassis is kept on site.
This chassis could also be installed above the existing (working) chassis to speed the
correction of this type of failure.
*Note
the mean time between failure (MTBF) for this chassis is stated as being 7 years –
which exceeds industry standards.
The 5500 switch provides the foundation of all network
interconnectivity within the headend. Within the switch are three high-speed back planes
capable of moving up to 3.6 Gbs of data traffic. The switch processors manage the path
each packet takes as the interfaces talk to one another. The switch also customizes the
connectivity of each end-point providing whatever bandwidth (10 or 100 Mbs), duplex (half
or full) connectivity is supported by the device.
In this system there are two key components that provide
configuration, management, and observation to the RPDs. They are the HCT/HMS and the IP
Server. While both of these do essentially the same thing, in that they can talk BOOTP and
TFTP to devices. The HMS can only configure devices on its local subnet. Therefore any
devices residing on networks distant from the HCT/HMS cannot be managed – however
they can be polled, pinged, etc. from the HCT/HMS. Equipment that is on separate networks
from that of the HCT/HMS requires a smarter BOOTP server to configure them. The separate
IP Server serves this purpose. It provides BOOTP and TFTP for all RPDs on subnets other
than HCT/HMS. The configuration and management of this separate application will be
discussed in a later section. From a redundancy standpoint, the IP server is much more
robust platform than the HCT/HMS. For example, it has dual power supplies, dual disks
(that utilize RAID mirroring). While redundancy is helpful the RPDs do not require a
configuration at startup. This is because the RPDs commit their configurations to
Non-Volatile Read-Only Memory (NVRAM) after booting off a properly configured BOOTP/TFTP
server. Having these settings in NVRAM allow the RPD to successfully boot on startup in
the event a qualified BOOTP/TFTP server is not available.
The twin 7206 routers provide the core routing functionality of this
system. They connect to the switch via 2 bundled pairs of 100Mb interfaces that are
trunked together. By trunking these interfaces together all routing responsibilities
between virtual local area networks (VLANs) do not require any one router interface card.
This also provides redundant connectivity between the switch and the routers incase the
switch were to loose an interface card that is used to connect with the router. Through
the use of trunking the twin routers can support multiple sub interfaces, each of which is
fully redundant.
The twin 7206 routers connect to the SONET via their own canalized
DS3 card. This enables the system to support up to 28 hubs* (one for each T1 supported in
the DS3). With a single DS3 card residing on each of the 7206 routers, this system
provides redundant connectivity to the SONET. The SONET in turn is also redundant. Each of
the DS3s on the 7206 is connected to a unique fiber shelf that houses two DS3 SONET cards.
One of these SONET cards operates in an “active” mode and other operates in a
“protect” mode. Together they provide redundant DS3 connectivity to their
respective DS3 circuit. In other words, there are two unique DS3 circuits leaving the
headend. Each of these DS3s are broken down into 28 T1s that serve a specific distribution
hub. Therefore, each distribution hub receives two T1 circuits each of which is unique in
that it is served by different 7206 routers, Channalized DS3 cards, SONET DS3 cards, SONET
T1 cards, T1/WAN cards, and 2621 routers.
*Note that systems with more than 28 hubs require something larger
than a DS3 (like OC3). Since an OC3 would exceed the capacity of the 7206, such a system
would require a larger router (perhaps something like a 7500 series). However the same
distribution hub architecture would be compatible with both systems.
The distribution hubs receive their portion of this DS3 circuit
leaving the headend in the form of two unique T1 circuits. These T1s are unique because
they share nothing (hardware or shelf) in common. These T1 feed individual T1/WAN cards on
two unique 2621 routers. Cisco has a technology called express forwarding that allows it
to optimize traffic destine for a distribution hub. The two 2621 routers provide full
redundancy of distribution hub routing while allowing one to double the bandwidth
allocated to each hub. These routers utilize hot standby routing protocol (HSRP) to create
a highly available gateway for the RPDs in the distribution hub.
These routers are joined through a 2924 catalyst switch that provides
high-speed connectivity to the 2621 routers (and enabling HSRP) while also providing a
highly available connectivity to each RPD. The 2924 provides this high-availability via a
dual DC power supply that can be connected to both the A and B power supplies in the
distribution hub. This system is also capable of providing redundant switching should
future RPDs come in a highly available package with dual Ethernet ports.
IP Server
Since the HCT/HMS cannot provide BOOTP/TFTP configuration for RPDs
located on distant subnets a smarter IP server must be used. This server (which consists
of standard off-the-shelf software) supports what is known as a relay agent. The relay
agent is something configured in the router that relays (or helps) the User Datagram
Packet (UDP) broadcast that signifies the start of a BOOTP process. This broadcast is
intercepted and forwarded to a specific host by the router on the RPDs’ local subnet
(the specific host is user configurable). A configuration in the router (called a
helper-address) relays the broadcast(s) of type BOOTP to a specified address that is a
BOOTP server. Note the router does an important thing during the relay in that it stamps
its address in the packet. This process allows the BOOTP server to handle BOOTP requests
on its local subnet differently from those relayed to it via a router. It also allows the
BOOTP server to send its response back to the requesting RPD (via the relay agent IP
address) as the requesting RPD does not yet have a IP address and is not local to the
BOOTP server so it cannot communicate with it directly.
In this system, the IP server integrates seamlessly with the running
HCT/HMS and only pertains to RPDs. This is permitted thanks to the fact that the HCT/HMS
can perform their necessary tasks to remote RPDs via its configured gateway address.
Although this allows the Motorola system to operate identically to that of a totally
HCT/HMS controlled system the setup and maintenance of this system differs as
follows:
- HCT/HMS cannot
control what information RPDs receive from the IP server. Since the RPDs do not interact
with the HCT/HMS during the boot process they cannot configure the RPD in this way. Any
required changes of this information must be performed on the IP server.
- Any boot process
initiated by the HCT/HMS is supported only with the exception of the above bullet.
- Any system wide
changes regarding RPDs must be configured on the IP server. These changes should be
mirrored on the HCT/HMS for consistency.
- The IP address
entered for an RPD in the HCT/HMS work with any RPD no matter what its media access
control (MAC) address. This is because the HCT/HMS required the MAC address to service
RPDs via its own BOOTP/TFTP server. Since this design does not use the HCT/HMS to provide
boot files to the RPDs, the next RPD boot will overwrite configuration changes made on the
HCT/HMS.
- The IP server’s default configuration is to
force the download of all its configuration files. This ensures that any new/old RPD
provisioned on the IP server will assume its default configuration whereby overwriting any
previously saved configuration stored in the RPDs NVRAM.
IP Server Configuration
The IP server can consist of one two supported platforms (Windows NT,
and Sun Solaris). These platforms are summarized below:
- The Windows NT
platform consists of an industrial grade PC with dual power supplies, dual disk drives,
and some kind of RAID controller to provide mirroring. Two applications provide the IP
services on this platform. The first is BG BOOTP. This is simple application that can be
set up to run at startup. BG BOOTP is configured via a text file called bootp.ini located
in the C:\WinNT\ directory. A TFTP server is also required with this configuration. TFTP
services are provided either by a BG TFTP server or a shareware version called TFTPD32.
The BG TFTP server is preferred as the TFTPD32 is a non-commercial product. In addition,
using both BG products allows one to use a DiviCom set up CD to build a new machine and
just copy in the necessary files rather than build a separate setup disk. The DiviCom
setup CD has everything including the OS, BOOTP & TFTP server software, and the RAID
controller configuration.
- The Sun Solaris
platform consists of an enterprise class server (220r) series with dual power supplies and
dual disk drives. This hardware platform actually less costly than the above WinNT
platform as many features including the RAID are built into this system. Two applications
provide the IP services on this platform. The first is a product called Join
(www.join.com) which handles the BOOTP services. Note Solaris actually has a DHCP server
included with the operating system that could also be used but it is not as straight
forward to set up as Join’s DHCP server. However it is difficult to setup and may not
have the same amount of support as a commercial product. Until the Sun/Solaris (i.e. UNIX)
platform is fully developed it should be consider trial until it is sufficiently tested.
However this would provide the most robust platform for the IP server along with a feature
rich scripting environment. One should not under estimate the importance being able to
script creation of reports, gathering health information, alerting potential problems,
even correcting some problems before they become customer impacting.
These two applications work together to deliver the correct
configuration files to booting RPDs. Essentially the process goes as follows:
- RPD boots
sending broadcast of type BOOTP
- A router (2621)
that is attached the subnet where the RPD resides, recognizes this broadcast and forwards
(relays) it to a host specified in the helper-address configuration (this is address of
the IP server).
- IP server
receives BOOTP request (which is now a directed broadcast packet from the 2621 router) and
checks in its bootptab file if it is instructed to respond to a request from this host
(determined by its MAC address).
- If the IP server
has information to give to this host, the BOOTP application running on the IP server sends
IP address info to RPD via relay agent (router).
- RPD receives
BOOTP response, initializes IP address, and performs TFTP
- TFTP server
responds to TFTP request with desired file (if exists or is readable)
- RPD assimilates
all the info to gain network access.
IP Server BOOTP Setup
The IP server’s BOOTP server setup depends on the type of BOOTP
server your using and which platform your running. At the time of this writing, the SUN
(UNIX) BOOTP server is in testing and will be added to this document as this information
becomes available. In the mean time, the following settings are for BG BOOTP.
The BG BOOTP server starts automatically when the server is booted.
This server is exclusively controlled via a bootptab like file (which is a standard
configuration file for BOOTP servers) located at C:\WiNT\bootp.ini. This file educates
which devices the BOOTP server is supposed to respond to and what information will be
contained in these responses. Essentially, the bootp.ini file maps each specific device to
a set of key value pairs of information. This information will provide the RPD with
exactly what it needs to connect to the network and conduct its follow on TFTP. Below is
an example bootp.ini entry of two RPDs in a distribution hub site called Afton.
[00:02:20:50:21:AD]
IP
Address=10.3.163.101
Subnet
Mask=255.255.255.0
Gateway
Address=10.3.163.1
Bootfile
Name=/tftpboot/rpd/aft/rpd.fof
[00:02:20:50:21:AE]
IP
Address=10.3.163.102
Subnet
Mask=255.255.255.0
Gateway
Address=10.3.163.1
Bootfile
Name=/tftpboot/rpd/aft/rpd.fof
The MAC address for the RPD is in [] which tells the BOOTP server that
what is to follow should be given to any BOOTP requests coming from the MAC address listed
in []. The next set of [] indicate the end of the previous BOOTP configurations (if any)
and the beginning of a new device’s BOOTP parameters.
Note that during the BOOTP process the RPD is redirected to a file
to gather more configuration information. This file is always the file of files (rpd.fof).
Since this is located in the network specific directory the bootfile name provided to all
RPDs in any one-network location should all be the same (as the above two RPDs located in
the Afton hub). The ONLY things that differentiate each RPD entries from the same
distribution hub in the bootp.ini file is the MAC address and the IP address assigned. The
bootfile name MUST be the same for every RPD in any one-network.
IP Server TFTP Setup
The IP server’s TFTP setup leverages a unique file structure to
simplify the handling of RPDs in the distribution hubs. This file structure utilizes a
technique common in cable modem provisioning servers called boot file sharing. The basic
idea behind sharing is that if a number of devices have several configurations in common
there is no need to make separate instances of these configurations. Instead, make the
devices share these configurations. This technique has been deployed in networks with
hundreds of thousands of devices sharing the same file with tremendous success. Once more,
the entire system is simplified by the fact that in order to make global changes all one
needs to do is modify a single or handful of files. This has a tremendous operational
advantage over traditional unique file methods and results in dramatic simplification of
the configuration management. The boot files in the TFTP “sharing” method are
divided into three categories.
- Device specific
– Files that must be associated with specific devices. This capability provides
backward compatibility with traditional TFTP services that house a boot files for specific
devices.
- Network specific
– Shared files that are associated with a specific location on the network. These
files likely contain some network specific information that is unique to that location
(e.g. a gateway).
- Default –
Files that are associated with system defaults. These files contain global parameters that
all devices require.
An implementation of sharing method with RPDs yields the following
configuration. Note this configuration is an example of an actual production running
system. There may be operational reasons beyond the knowledge of the developer why certain
files should or should not be shared. One should keep in mind however, that any files that
are not shared create additional administrative load and complexity to the overall
system.
/tftpboot
/rpd
rpd.adb
rpd.hst
rpd.htm
rpd.ini
rpd.img
rpd.msg
rpd.svc
rpd.tsk
/aft
rpd.fof
rpd.gtw
/ank
rpd.fof
rpd.gtw
In this file structure [/] represents a directory. For example on a
PC /tftpboot would actually be C:\tftpboot – note that C:\ is optional. Likewise, the
/rpd on a PC is a child of /tftpboot and thus the path to this child would be
C:\tftpboot\rpd. In this file system, configuration files located in the /tftpboot/rpd
(i.e. rpd.abd, rpd.hst, etc…) are the default configuration files or the global
configuration files.
A child of the /tftpboot/rpd directory are other directories
designated for each distribution hub (e.g. aft [afton], ank [anoka], etc…). These
directories house the network specific configuration files for a remote network location.
RPDs at these locations must be configured with files located in these directories (e.g.
rpd.fof, rpd.gtw, etc…) in order to work properly on a routed network. The rpd.fof
file has special significance, as it is the first configuration file that a RPD downloads
as part of its startup process. This file tells the RPD where (file system path) certain
configuration files are located and which of these files it MUST download. The rpd.fof (or
file of files configuration for the RPD) can instruct RPDs to FORCE it to reload* these
configuration files.
*Note a reload is necessary in most cases as the RPD has
persistence of its configuration. This persistence happens when an RPD successfully boots
off some server (whether it is an HCT/HMS or an IP server). After a successful boot, the
RPD commits the configuration learned from the boot process to NVRAM. If one were NOT to
FORCE a reload on an RPD with every boot, any newly installed RPDs would not be able to
join the network. This is because they may have either the wrong gateway information
loaded or no gateway information loaded. Forcing the reload also ensures that the RPD
acquires its new IP address, subnet mask, and all the defined global parameters.
RPD Configuration File Customization
Once the TFTP server has been set up, the RPD configuration files
distributed from Motorola must be slightly modified to enable the boot file sharing. Below
is an example rpd.fof for an actual distribution hub called afton (aft). The afton hub has
its own file directory (i.e. /tftpboot/rpd/aft/ ) where this file is stored. These changes
(which can all be made with any standard text editor such as wordpad, vi, etc…)
include adapting the directory to the /tftpboot which is a standard named directory used
with TFTP. Motorola for some reason chose not to use /tftpboot and this needs to be
changed to migrate to the boot file sharing model (it also allows this configuration to
hold for both PCs and SUN platforms).
The second change involves the removal of the versioning information
in the directory structure provided by Motorola (e.g. /bootdir/rpd/03_02.000/rpd.img
now becomes /tftpboot/rpd/rpd.img).
This is actually unnecessary and can be handled in a different way that will be shown in
the next section.
The third change involves the mapping of the location specific
gateway file. Since this file cannot be a global configuration, it must be placed in
network specific directory and then appropriately mapped to that directory’s rpd.fof.
For the afton hub example the gateway configuration file is mapped to /tftpboot/rpd/aft/rpd.gtw
(notice the additional /aft) over other global configurations mapped in the rpd.fof.
The last change involves the forcing RPDs to reload these
configuration files (or overwrite their existing configurations). This is done by adding
an “F” on the end of each file mapping defined in the rpd.fof file. PLEASE NOTE
that removing the F from various lines in the rpd.fof file for a hub that is working will
have no adverse effect on the RPDs. However, any changes made to the global files will not
be forced down when RPDs in a hub are rebooted. Removing the F will also prevent any new
or replacement RPDs from being activated in that hub. So, be careful not to remove these
Fs without informing operations as it could be a difficult problem to troubleshoot.
#------------------------------------------------------------
#
Application, OS and Symbol File
#------------------------------------------------------------
/tftpboot/rpd/rpd.img /boot/gi360
F
#------------------------------------------------------------
#
Dynamic Configuration Files
#------------------------------------------------------------
/tftpboot/rpd/rpd.ini /config/config.ini
F
#------------------------------------------------------------
#
Static Configuration Files
#------------------------------------------------------------
/tftpboot/rpd/rpd.hst /boot/hosts
F
/tftpboot/rpd/aft/rpd.gtw /boot/gateways F
/tftpboot/rpd/rpd.svc /boot/services
F
/tftpboot/rpd/rpd.tsk /boot/task.cfg
F
/tftpboot/rpd/rpd.msg /boot/msgq.cfg
F
#------------------------------------------------------------
#
SNMP Files
#------------------------------------------------------------
/tftpboot/rpd/rpd.adb /boot/agentdb.cfg
F
#------------------------------------------------------------
#
HTTP Files
#------------------------------------------------------------
/tftpboot/rpd/rpd.htm /boot/default.htm
F
The above file is an rpd.fof configuration file for the afton
distribution hub. This file shows actual working file path names and can be used as a
reference to build a completely new system.
The second file that is distribution hub (or network) specific is the
rpd.gtw configuration file. This file educates the RPD as to what network it resides. All
RPDs who are off a particular distribution hub router MUST be configured with the rpd.gtw
file or they will not configure their Ethernet interface with an appropriate gateway and
consequently be only reachable from that local subnet (i.e. will not respond to pings from
remote subnets). The rpd.gtw file MUST contain a single line as below:
net
0 gateway 10.3.163.1 metric 1 passive
This entire line must be UNCOMMENTED and the only part of this line
that should be different among distribution hubs is the IP address stated in this line.
For example, the IP address 10.3.163.1 represents the afton distribution hub’s router
interface – other distribution hubs WILL have a different gateway address that can be
obtained from the IP plan for your site. Since all RPDs connected in the afton hub MUST
utilize this gateway to communicate to the rest of the digital video network they require
this gateway configuration. Again, failure to provide a correct gateway or changing this
line by anything other than the IP address may render the RPD in accessible to the rest of
the digital video network.
Since both the rpd.fof and the rpd.gtw files are particular to the
distribution hub network they should rarely (if ever) need changing. In fact, as you roll
out new hubs, you can easily create new directories for these hubs by just copying one of
the existing distribution hub directories and then renaming the copied directory with the
name of the new distribution hub. One this is completed, merely change the distribution
hub name of the rpd.gtw path in the rpd.fof and edit the IP address of the distribution
hub’s router in the rpd.gtw.
RPD Software Upgrade Process
When the time comes that a new RPD software upgrade is available, it
can be very easily deployed using the shared boot file method. This is because each and
every RPD is mapped to the same image file. If there is a new image available, simply
create a new directory for the existing image file – this provides you with fall-back
capability. Note that it is important to name this directory so as to help you identify
exactly what is stored in this directory as it could become confusing if you don’t
follow this procedure. First of all create a new directory in the /tftpboot/rpd/
directory. Name this directory as follows:
<version>-original
This will serve you well as it allows you to keep a back up copy of
working image files for RPDs. You can even do this before you receive an updated software
image file as it allows you to ensure that you have a readily available copy of current
software image version. When your finished your /tftpboot/rpd/ directory should look
something like this:
/tftpboot/rpd/
rpd.adb
rpd.hst
rpd.htm
rpd.ini
rpd.img
rpd.msg
rpd.svc
rpd.tsk
/03_02.000-original/
rpd.img
/aft
rpd.fof
rpd.gtw
Note the rpd.img in /tftpboot/rpd/ is an exact copy of the rpd.img
located in /tftpboot/rpd/03_02.000/ only the later one is NOT in production (or not being
provided to currently running RPDs). When a new software image is desired, one MUST follow
this procedure to upgrade the rpd.img file your RPDs. It is assumed that the rpd.img file
provided has been tested. To add this software image file, repeat the previous process of
creating a directory for a software image version. Once this is complete, copy the NEW
software image file into this directory (note that it may not be named exactally rpd.img
but rather <version>.img – if this is the case rename the file to rpd.img AFTER
it has been copied to the newly created directory). Once complete, your new file structure
should look something like:
/tftpboot/rpd/
rpd.adb
rpd.hst
rpd.htm
rpd.ini
rpd.img
rpd.msg
rpd.svc
rpd.tsk
/03_02.000-original/
rpd.img
/03_03.000-original/
rpd.img
/aft
rpd.fof
rpd.gtw
Note that at this point, your RPDs are still pointed to the old
version. The only thing you have done is make the new rpd.img software image file readily
available. To move this new software image file into production, simply copy this new
rpd.img file over the production image file located at /tftpboot/rpd/rpd.img and reboot
your RPDs. You can remotely force RPDs to reboot via SNMP from HCT/HMS or you can go to
the distribution hubs and power cycle them. If for some reason you’ve determined
there is a problem with the NEW rpd.img file, simply go to the previous release directory
and copy the old rpd.img file over the production rpd.img file. ALWAYS double check your
copy commands when doing this so as to ensure that you are positively copying previous
releases rpd.img file over the production rpd.img file. If you unsure, double check which
directory your in as a wrong move here could require you to obtain a backup copy of the
previous release of rpd.img file which may not be handy.
Note that each time one installs an upgrade to the RPD software
image as described above they should verify that that there are no changes to the file of
files. It may be possible (however unlikely) that a upgrade to the software image may
usher in a new configuration file definition in the file of files. It is advised that one
do a side-by-side comparison of the file of files to make sure there are no new entries
(which would indicate the presence of an additional configuration file).
Additionally, there may be further changes necessary to the global
parameters necessary during an upgrade. If this is necessary, one should copy the existing
configuration file where changes are needed to the previous release directory so as to
provide a way to recover in the event the new changes don’t work out as planned. For
example, lets say that changes are needed to the rpd.ini file for some software image
upgrade. Using the previous file system structure, your new one would like the
following:
/tftpboot/rpd/
rpd.adb
rpd.hst
rpd.htm
rpd.ini
rpd.img
rpd.msg
rpd.svc
rpd.tsk
/03_02.000-original/
rpd.img
rpd.ini
/03_03.000-original/
rpd.img
/aft
rpd.fof
rpd.gtw
In the above example, the rpd.ini file was added to the previous
software image release directory.
Setting RPD Operating Parameters
The addition of the IP server disables the use of the HCT/HMS as a
control point for managing RPD operational parameters. These parameters include setting
the demodulator frequency, demodulator node, etc. When the IP server is used, the HCT/HMS
has access to all the RPDs for reporting, data collection, etc. ONLY -- they are not used
to deploy, maintain, and configure (other than via SNMP sets) RPDs. Therefore, any
settings that were previously configured in the RPDs via SNMP by the HCT/HMS will be
cleared by the next reboot of the RPD. To make any permanent changes to the RPD, the
settings for these RPDs must be made to the configuration files on the IP server.
Can Birds-Eye.Net help you or your Company?
Receive your Birds-Eye.Net articles and white
papers hot off
the presses by adding our RSS feed to your reader.
|