How many manual steps can I eliminate when attempting to enable an IP scope (address range) on a CMTS?
In my experience working with operators on IPAM projects, this process usually involves the following steps:
- Safely identify the address range that can be used for the scope
- Configure a CMTS (routing element) to have that range configured and an appropriate gateway address (GIADDR) is assigned
- Configure the DHCP to ensure the correct options are being used for the scope
These steps are generally completed manually, sometimes resulting in human errors that may cause service disruption in the fast and dynamic IP-services space. This is one area where automation can decrease the potential errors and in turn, reduce the risk of service disruption.
How many potential errors can be eliminated from node splits or renumbering scopes on the network?
Yet another example of an error-prone manual process that shouldn’t have to be this way. In most cable network cases that I’ve encountered, this process involves:
- The same steps as above to ensure subscribers can be allocated leases (dynamic IP addresses) from an alternative scope
- Deactivating the scope so that subscribers can gradually be pushed off the scope without negatively affecting the service they are using
- Ensuring that scope utilization has reached zero percent after it’s deactivated, before removing the scope from the routing element
Automated solutions can ensure these checks are done by the system and eliminate the risk of causing an outage for your customers. Decreasing manual processes also decreases project roll-out time or renumbering.
How many different teams are involved in the decision process to make changes to an IP scope on the network?
Some organizations may be smaller and involve one or two departments, but in larger communication service providers I’ve worked with, I’ve seen the following:
- The IP team makes a decision to increase the size of the scope in a particular location due to increased utilization and selects the appropriate IP ranges based on routing and fragmentation concerns
- A ticket is sent to the Network Operations team that manages the routing elements to add the scope (capacity) to the specific node (area). The configuration changes are applied to the routing element
- A ticket is sent to the DHCP Operations team to configure the DHCP scope and appropriate DHCP policies for those subscribers. The DHCP team performs the configuration change
- A ticket is sent to the Regional Engineer informing them that the larger scope is ready and active. Once the new scope is properly functioning, the engineer may begin the process to deactivate the smaller scope. This will require configuration changes from the DHCP team
As you can see, larger organizations need a solution that allows some form of request and approval process for the first stages of automation to begin. Over time, confidence in the automated steps may reduce the need for approvals and IPAM efficiency can increase drastically.
How many different pieces of technology must the solution integrate with?
Operators try to standardize their network, but acquisitions, demands to offer more services and the constant need to lower operational costs pressures them to manage networks that are not always heterogeneous. Challenges may include:
- Multiple routing element (CMTS unit) vendors, each with its own configuration style
- Various services and DHCP policies in use on the network
- Numerous network access technologies (Cable, DSL, GPON)
These various technologies and multiple access networks can cause major headaches when manual processes don’t align. That being said, it wouldn’t be impossible to create scripted parameterized flows or templates for each of these scenarios on the network. The values of many of these parameters are often documented in an IPAM system. For example, the network access technology is often captured by some service type or tag, the routing element vendor is captured in the device inventory data, and routing information can be collected by the hub or region that the routing element resides in. There is no reason why an automated IPAM solution couldn’t allow you to script these flows specifically to your network and trigger them based on a simple deployment lifecycle. Doing so can reduce the frustration of dealing with various technologies.
Implementing a solution that cuts down manual processes not only reduces errors caused by cumbersome grunt-work, but it also saves OPEX, reduces time-to-market for new services, and cuts down the risk of service disruptions.
Submit a Comment