|
IP Address Provisioning Migration Strategy
The key to a successful deployment is a well constructed plan
By: Bruce Bahlmann - Contributing Author (your
feedback
is important to us!)
Created: May 6, 1997
Note: For help designing your DHCP network
or developing tools to help
you audit/test the performance your applications contact Birds-Eye.Net.
Overview:
The goal of the following document is to provide some direction
for the upcoming transitions of address provisioning. Each transition will represent
changes in functionality and or hardware/software. Address provisioning is defined as the
process of dispensing and administrating IP addresses. IP address provisioning systems
provide initial activation of customer centric network hardware that permits high speed
Internet access.
Figure 1. Current
Provisioning Configuration
Current Status:
The current provisioning system used for high speed Internet
access is represented by Figure 1. In this system, Remedy provides customer specific
information (hostname and the mac address of computer, modem) and a mechanism to interface
with the provisioning server. The communication between Remedy and the provisioning server
is by means of a command line interface that utilizes the remote shell capabilities of the
UNIX operating system.
The webserver in Figure 1 provides distributed administration of the
provisioning process and the devices (headend nodes) statically configured within it.
Through the use of the webserver, multi-level access to the various configurable
parameters of the provisioning server are managed and repetitive tasks (e.g. swapping out
headend nodes) are simplified and streamlined. The webserver also provides troubleshooting
tools for installation and desktop support. Through the troubleshooting tools, support
staff are capable of looking up server specific information (e.g. IP address, client
server interaction, or health of device) over a universal web interface.
The provisioning server in Figure 1 is both a single point of failure
and a single source of information for IP address consumption. On this machine resides
BOOTP and DHCP services that are bundled in the Join product by Competitive Automation and
TFTP services using standard tftpd that comes with Solaris. This combination of
applications along with some creative configuration tricks (all devices on a network share
the same MD5 file) enables dynamic BOOTP for modems (which permits modems to roam
networks). Although through various watchdog and administration scripts the current
provisioning server have worked nicely, the application is single threaded and does
un-explicably shut down.
A PC-based application by LANCity actually creates the MD5 files that
modems download to receive their operational parameters (frequencies, bandwidth, etc.).
This piece of software is not integrated into the creation of new networks and must be
performed separately on some PC and with the resulting files uploaded to the provisioning
server for organization (to the appropriate directory for TFTP downloads).
Limitations:
The system is limited to provisioning a single service level (MD5
file with bandwidth parameters) for all customers. It is desirable to support many
different service levels to allow for pricing options and customer needs.
Also limited is the ability to perform automated DNS updates of the
customer base. Since IP addresses change somewhat frequently as a result of using DHCP and
renumbering the network, an automated process of DNS updates would eliminate visual
inspection and manual update. Note that the process still relies on the accuracy of data
in Remedy.
To address with some of the unreliable features surrounding the
provisioning process a level of redundancy is needed for the provisioning server. This
redundancy is especially needed for headend nodes which in the absence of a BOOTP server
can force all the customer modems behind them to loose block-sync amplifying impact of the
outage.
Additionally, shortages of IP addresses require that we introduce net
10 addressing for modems. The single server configuration that is currently in use does
not support multiple addressing in terms of handing out certain addresses based on the
type of clients (BOOTP vs. DHCP). The single server configuration treats both client types
the same (gives addresses to both from the same pool). Adding a second server as shown in
Figure 2 enables provisioning of net 10 addresses to different clients based on clients
are registered on each machine.
Figure 2. Phase One of
migration (adding a second servers to divide BOOTP & DHCP)
Phase 1:
The second server will run only BOOTP and will hand out only net 10
addresses. Any clients that require a net 10 address will be registered on this machine
and any clients that require a 24 net address (valid Internet address) will be registered
on the DHCP machine (existing server).
Since all clients are currently registered on the DHCP server the
BOOTP clients will need to be migrated over to the BOOTP server. There are
effectively two ways of accomplishing this:
- Activate idle functionality in
Remedy to provision on two different servers. This functionality permits BOOTP
clients to be provisioned on a second server. The following steps would
need to be accomplished to achieve this transition:
- Enable secondary address net 10 on all subnets
- Configure routers to route net 10 and add a helper address for
new server
- Open new port in the firewall to enable Remedy to server
communication
- Build new BOOTP server and configure it with net 10 addresses
- Enable web tools and administration for the new server (support
staff cannot ping net 10 addresses from the corporate network).
- Write a replacement script for jdbreg on BOOTP server that will forward deprovisioning commands
to DHCP server if client is not provisioned locally.
- Test the provisioning/deprovisioning process on the second server using the Remedy development
server.
- Type in the new server’s IP address into the production Remedy
server
- Rewrite existing register command
on the main provisioning server to divide the provisioning of modems and PCs on the
correct machine. To accomplish this the following steps are needed to accomplish this
transition:
- 1-5 are
the same as above
- Write a replacement script for jdbreg on the DHCP server that will forward provisioning of new
BOOTP clients to the BOOTP server. Deprovisioning will check if the client exists on DHCP
server and if not forward this as well to the BOOTP server.
- Test the provisioning/deprovisioning process with the staging server.
- Move the existing jdbreg command to a different directory and
replace it with the script.
Once the above method is selected and the underlying steps are
competed the migration would commence by freezing the BOOTP entries in the DHCP server and
place all new registrations of BOOTP clients on the BOOTP server. BOOTP clients that are
deprovisioned (de-registered) will continue to hold a lease (IP address) on the DHCP
server. Their lease can only be recaptured once that client receives an address from the
BOOTP server (some nightly script will run that compares leases on both machines and
releases DHCP addresses of BOOTP clients that have successfully retrieved a net 10
address.
Tied into the phase 1 migration is the installation of headend BOOTP
servers. Headend BOOTP servers will be configured through the use of the customized
bootptab file that is downloaded to them upon changes through the web administration
server. The bootptab file received by these headend servers will only contain the
information pertinent to their headend. In other words, only those networks, headend
groups, and headend node clients supported out of a particular headend will be represented
in the bootptab file received by these headend servers. Headend servers will neither have
knowledge of nor the ability to answer requests from clients requesting dynamic
information.
This migration also includes the integration of LCn into the web
administration server. In this manner a network configured through the web administration
server will have its MD5 files generated on the same machine. The use of the LANCity
software will be discontinued. The MD5 file creation tool will be created with intentions
of using the same tool to dynamically create MD5 files based on customer options.
Limitations:
Building redundancy into the headend provisioning process will add
additional reliability to the system and provide a means for reducing the size and scope
of various service interruptions. The key to this migration becomes the web server
administration and its ability to intelligently update the servers with correct and timely
information across the network. The Headend servers will have the ability to operate in
the absence of the web server administrator once they receive a correct bootptab file.
However, what is missing from this functionality is a reliable means of updating DNS. To
achieve a reliable means of dynamically updating DNS the existing Join server must be
replaced with to one that can update DNS names as DHCP address transitions occur. Figure 3
introduces the next generation provisioning server produced by American Internet.
Figure 3. Phase 2 of
migration (replacing Join with American Internet product that adds DNS)
Phase 2:
Phase 2 represents a major change in the software currently used to
provide address provisioning. During this phase the current Join server is phased out and
replaced with the new server application from American Internet (AI). Changing out these
servers will be a major undertaking because the IP address of the DHCP server must also be
changed so both servers will reside on the front side of the High Availability (HA)
cluster. It is important to note that this phase will not include moving the AI software
to a NFS mounted directory and enable HA for the provisioning process. HA for the address
provisioning will be discussed in the “Limitations” section below.
Migrating from one server to another will involve the following
steps:
1.
Build
replacement AI address provisioning servers for BOOTP and DHCP (including log and
/var/adm/messages administration)
2.
Activate
these servers on new IP addresses on the front network.
3.
Configure
routers to helper new IP addresses of these servers.
4.
Open
up two new ports on the firewall to handle communication for each machine from Remedy.
5.
Configure
Remedy development server with new server’s IP addresses and test provisioning and
deprovisioning of modems on the network (need to test each network with the a modem).
6.
Update
Remedy computer schema to include “service class”, “hostname”, and
“filtering” fields.
7.
Rewrite
remedy provisioning interface to send the fields above (including mac address) with each
register/deregister command.
8.
Rewrite
web interface to administer these servers.
9.
Rewrite
tools interface for new servers.
10.
Migrate registered modems
over to new BOOTP server and activate Remedy link to this server.
11.
Migrate registered computers
over to new DHCP server and activate Remedy link. This will cause a un-avoidable service
outage for customers with PCs, Macintosh customers should not experience any service
interruption.
12.
Re-purpose previous
Join-based DHCP and BOOTP servers as backups (configure identically to new servers and
place on stand-by).
This phase will be painful many support scripts will need to be
re-written and from a support standpoint we begin a new learning curve in terms of
application support & troubleshooting.
The new AI server represents a value add of dynamic updatable DNS,
multi-threaded processing of requests, and elimination of reporting consumed licenses to
Competitive Automation.
The capability of multiple service requests is possible with the AI
server and this functionality will be rolled into this phase. The service levels, will be
limited only to those canned MD5 files set up for each frequency. The actual service
levels must be researched by marketing and engineering to address market needs for this
service.
Limitations:
Because of a limitation in DHCP and BOOTP address provisioning a HA
version of these services will not be possible until either a server to server protocol is
developed for this application or a non-conflicting method of interleaving dynamic address
pools is devised. Regardless, the HA version of BOOTP and DHCP is not currently in this
migration strategy.
It will not be possible encode customer specific information into the
MD5 file until phase 3 when dynamic MD5 file creation is introduced. Dynamic file creation
is dependent on an additional technology (LDAP) that will introduce another layer of
database storage and retrieval and require an Application Program Interface (API) from
American Internet to make possible. Figure 4 represents the architecture that phase 3 will
involve.
Figure 4. Phase 3 migration
(introduction of LDAP and dynamic MD5 creation).
Phase 3 represents a move toward full customization of BOOTP files
and presents some challenges in terms of hardware support and software administration.
This will provide us with the capability for such things as loading mac addresses and IP
addresses into MD5 files.
LDAP enables on-the-fly MD5 file creation thanks to its fast lookups
and its ability to store customer information close to address provisioning systems.
(need more...)
Figure 5. Dynamic MD5 file
creation process
The goal of this phase is dynamic MD5 file creation. This process,
which is shown in Figure 5, creates MD5 files based on a set of service and filtering
options that have been stored in LDAP for a particular mac address. The fields required in
LDAP for this process are the following:
<modem mac address> <directory > <service level
option> <filtering option> <modified flag>
These fields enable the creation process to build the MD5 file from
data that is associated with a mac address’s record.
Migrating from canned static service levels type MD5 files to dynamic
MD5 file creation involves the following steps.
1.
Write
a program that creates a MD5 file based on a set of options given and moves that file to a
specific directory. This program is also used to create headend node files by the
webserver and is already completed.
2.
Write
a program that given a mac address and gateway, the program determines the MD5 file
creation options and launching the program in step one if the modified flag has been set.
3.
Write
a program that listens for BOOTP requests and calls the program in step 2 for each
request. Note that the program may have to call the program for every other request to
avoid creating to two identical files for a request simultaneously.
4.
Build
LDAP server and load the configuration file (containing the object classes)
5.
Open
a port in the firewall for Remedy to talk to LDAP.
6.
Send
test data to LDAP using Remedy development server.
7.
Test
previous programs for modems on all networks.
8.
Load
all the mac addresses and service levels from AI BOOTP server over to LDAP.
9.
Configure
the AI BOOTP server to assign BOOTP file names dynamically based on mac addresses (e.g. on
every BOOTP request the client will be instructed to TFTP the a file named that same as
its mac address from a directory based on the subnet the client resides).
Limitations:
Once a LDAP API is ready for the AI server it will simplify some of
the above steps. The API would enable the AI server to communicate directly with LDAP and
perform lookups based on BOOTP requests. This would eliminate needs for a separate program
to listen for BOOTP requests.
The addition of triggers in LDAP would enable automation of the MD5 file
creation process and the modified file process. Further detail on these
process is described below:
- The LDAP creation trigger would
be activated when ever a BOOTP requests was received by the AI BOOTP server which
proceeded with a LDAP query for the mac address. The mac address query trigger would need
to be isolated to the BOOTP server (as other processes [webserver, etc.] perform mac
address queries) as the source of the query and as a result call a
shorter version of the MD5 file creation program (in step 2 if the
modified flag is set) that deciphers the Remedy options and converts
them into real MD5 options and calls the MD5 file creation program.
- The LDAP modification trigger would need to be activated each time
the modified flag was set. This trigger would call a new program that
would simply perform an SNMP reset of the cable modem. The reset action
would enable the modem to option a new configuration file based on the
new options set by remedy.
The above API would also be useful for the DHCP server for the
hostname and various other parameters (e.g. WINS, etc.) will be loaded in LDAP. However,
because DHCP clients can not be told to re-read their configuration a separate
modification flag should not be needed for these clients. In this case updating the AI
DHCP server with every update should be sufficient. Unless Remedy data is continued to
directly update the AI DHCP server, another trigger would be needed to update the AI DHCP
server on every update of DHCP parameters. This API would require the following fields in
LDAP:
<pc mac address> <hostname> <server options>
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.
|