Challenges in Day-to-Day Operations

IBN primarily describes how a campus network should be operated to meet the everincreasing number of connected devices and complexity. IBN can therefore also be seen as a new method of running network operations in the (campus) network. However, a number of challenges related to day-to-day operations can affect the success of a transformation to IBN.

Of course, all network engineers are familiar with the OSI layers of abstraction with the process of encapsulation and decapsulation that essentially form the basis of any network infrastructure. However, users and managers just view the network as a single element that is just as common as running water or electricity. Because users and managers only see a single network (users, for example, don’t know the difference between 4G and WiFi connections), an analogy can be used to explain that the network is actually a foundation for the applications.

Every organization can be seen as a building or a house, each uniquely built and designed. On the top of the building we see all the applications required for the business to be able to run. This could be Office 365, Google Mail, an ERP system like SAP, but also your office applications and a fileserver to store all your documents. It doesn’t matter whether these applications run on-premises, in the cloud, or a combination. It’s just the collection of applications that the organization uses in day-to-day operations. Figure 7-1 displays this enterprise building.

At the first layer of the building, where the employee or contractor resides who wants to get access to the enterprise applications, the physical connection to the corporate network is described. It is literally the physical cable (or wireless network) that is used to connect the endpoint to the corporate network. The second layer is the equipment to which the physical cable (or wireless connection) is connected. These are the network switches, wireless controllers, access points, and routers that comprise a campus location network. Although an endpoint can be connected to the network, there is still no access to the application. That is because four pillars are required to be able to access the applications.

The first required pillar is the Dynamic Host Configuration Protocol (DHCP). DHCP is used to dynamically assign IP addresses to connected endpoints. If DHCP is not working, there is no IP assigned to the endpoint and thus no connection to the applications. Often, DHCP is managed by the server team and not the network operations team.

The second pillar is the Domain Name System (DNS). This service translates domain names into the appropriate IP addresses, like a phone book. DNS is a service that runs on top of the IP network, but if DNS is not working, it is often blamed on the network. While the IP network is functioning and traffic can flow, it’s just that the phonebook is not working.

The third pillar is the WAN connection or Internet connectivity in the case of a cloud application. If the WAN or Internet is down, there is again no connection to the applications.

The last pillar is security, which should be integrated everywhere. Cisco Identity Services Engine (ISE), as network access control, or a firewall could block access to an application for any number of reasons. If these services are not available, again there is no connection to the network.

This explains, in a simplified way, that for users to connect so easily to the enterprise applications, many elements need to be in order. Today’s enterprise networks, however, despite their complexity, are so reliable (and invisible), most incidents are initially blamed on the network and specifically the campus network. Some examples of frequently reported incidents are

• “I cannot access application X, but I could access it yesterday. It is definitely the network.”

• “Application Y is slow; must be the network. It’s that uplink again that you mentioned three years ago.”

• “I cannot connect to the wireless network, and it’s not my computer because everything works at home.”

• “I can’t log on to the computer; it is the network’s fault.”

• “The wireless service is terrible. I only see 2 bars for 4G on my phone in the office. Please fix this.”

These and similar examples are quite common for many network operations teams. They face these types of issues frequently and probably spend quite a bit of time proving that not all incidents are network-related other teams should address the incidents related to application performance instead of the network operations team.

Besides the fact that the operations team spends quite some time disproving “it’s the network,” another aspect might play a role in the day-to-day operations. There has been a shortage of qualified staff for a long period of time (decades in the case of Europe). Besides a shortage of staff, the campus network has gradually grown in size and the connected devices. As the network is very invisible for many users and managers, chances are that the network operations team has not been growing in line with the growth of the network. The consequence is that the operations team is understaffed and trying to keep the network operational with too limited resources.

These two aspects together might indicate that the network operations team is under a lot of pressure and do not have time to look at alternatives, as they can be seen as firefighters continuously putting out fires in the foundation of the enterprise (refer back to Figure 7-1). They are too busy solving incidents and executing changes on the network (that take too long) and often must work overtime to update the switches because they are not allowed to do that during the day.

To determine whether IBN is a viable solution for a specific campus network, it is important to determine whether the preceding scenarios are applicable for the network operations team. If that is the case, then the network operations team will not have time available to perform extra changes or even consider changing the way they operate the network. This challenge (of being too busy) needs to be identified early on in the process so that appropriate actions can be taken to free up time within the operations team; otherwise, the network operations team will remain busy while the campus network continues to grow.

It is important to note that the network operations team should be engaged in the process of transformation to IBN as much as possible because most of IBN relates to their responsibilities.

Inventory

In most organizations the campus network is not being replaced very often. It is common to install the network equipment and keep it running for at least five years and for some network equipment even longer. Some enterprises, in fact, still operate with a wireless network that has not been changed since its initial operation, while the wireless access points have been superseded by three new versions. Other examples describe situations where switches were run in the default configuration. Determining the current state of the campus network requires performing a detailed inventory of the network infrastructure components within the campus network.

This inventory should be detailed and extensive and should also include information related to the capabilities for IBN. The output of this inventory should be registered with the help of the examples in Tables 7-1 and 7-2.

Table 7-1 is used to create a complete inventory of all campus network equipment and is validated against Cisco DNA and IBN readiness on both the software version as well as the hardware. For each device, an entry should be made and determined (in case of non-ready hardware) when the hardware is scheduled to be replaced. If there is no active lifecycle management (LCM) within the organization, that lack of LCM is a risk for the transformation, and a mitigation should be defined in cooperation with the appropriate stakeholders. If the campus network has multiple locations it can be convenient to add a column for the location name, as to be able to create an inventory impact overview per location.

Depending on the size of the campus network it is optional to aggregate the available data from Table 7-1 into an overview such as shown in Table 7-2.

The aggregated overview in Table 7-2 can be used to determine the impact of creating an IBN-ready infrastructure. Because some switches might have to be replaced, it is possible that some steps of the transformation to IBN will be delayed. The primary cause for this is that financial administrations dictate that investments need to be depreciated over multiple years. It means that an investment last year needs to last for at least two or often four years. It is possible to replace sooner, but it means that the organization is willing to accept a financial disinvestment of the previously made investment.

The inventory should be a “living” document, so as soon as a network device is replaced with other hardware, the inventory should be updated. Also, based on this inventory, it is recommended to get a strategic decision from stakeholders that if hardware is to be replaced, whether due to failure or in normal lifecycle management, the new hardware must be IBN ready.

Level of Standardization

Another element that needs to be identified is the level of standardization. One of the principles behind IBN is that the specifics for an application or policy are pushed onto the network when it is required using predefined blocks of configuration (either CLI or model-based). There is a direct relationship between the level of standardization in the existing campus network and the success factor for IBN. In other words, when there is no standardization, it is not possible to automate changes on the network and thus enable IBN, whereas if there is a high level of standardization using standardized components, these components can easily be configured using automation.

As such, the level of standardization needs to be determined for several aspects of the campus network. Only those elements of a network that are standardized can be automated and thus be deployed onto the network when the intent is required. As a campus network design and its implementation consist of several components, the identification of automation level should occur for those different components as well. The following sections briefly describe each component.

Maturity Level of an Organization

It might sound strange, but the maturity level of an organization can tell a lot about how successful any change will be. The maturity level has nothing to do with the age of an organization but is measured along aspects such as people, process, technology, and documentation. The maturity level of an organization provides insights into whether and how a network can be transformed to IBN. The maturity level namely provides information, at an abstract level, about how the organization is documented, whether it is working with or without procedures, how it embraces a vision, and other insights.

A number of frameworks are available that describe the level of maturity of an organization. Control Objectives for Information and related Technologies (COBIT) by ISACA is an extensive framework that provides control objectives for IT governance and IT management. The COBIT 4.1 version of the framework has a maturity model that is useful in this phase. Within this model are five levels of maturity defined that are used and referred to throughout the control framework. Without going into the details of this framework, these levels do provide a good view of how mature the IT within an organization can be. The following sections describe these levels.

Stakeholders

The transformation to an IBN-enabled campus network is a strategic decision. Chances are that the transformation to an IBN-enabled campus network will not only take a considerable amount of time but will probably also bring extra costs and downtime as required changes are implemented. Although the desire to transform might be initiated from a network operations or network design team, or an IT manager, it is important to identify the stakeholders who can and will support such a long-term strategy in transformation.

Stakeholders are all responsible persons (or departments) within an organization that have either an interest in this strategy or are affected by the execution of this transformation. As the campus network touches many aspects of the organization, it is important to identify stakeholders for business operations, technical, architectural (if applicable), and financial level.

It is important not only to identify those stakeholders but also involve them in the decisions that you need to make for the transformation. They should be informed, and preferably the key stakeholders should also support you in the process of this transformation of the campus network.

A method to register and document the identified stakeholders within the organization is the RACI (Responsible, Accountable, Consultative, Informed) matrix. A RACI matrix is commonly used to visualize for specific tasks (or business processes) who is responsible for executing the task, who is accountable (only one is accountable), who provides support to the task (Consultative), and who needs to be notified of the output of the task (Informed). The same principles can be used within this step to document the identified stakeholders, both formally and informally. Use the Consultative and Informative columns for identified influencers. Table 7-5 provides a sample matrix that can be used.

Besides identifying these stakeholders, it is important to communicate why the transformation to IBN is needed and how you want to achieve that transformation. Explain why a big-bang transformation might fail and inform them of your balanced choices.

You should not just inform them once, but inform them periodically about progress and decisions. Keep those decisions at the level of the stakeholders, so that they will feel that you understand their concerns, and they will appreciate the effort and will more likely become part of the process. Their involvement is important to getting and keeping support during the journey. The chances are that at some moment in time an unforeseen disruption might happen or extra funding might be required for a big step.

In conclusion, identifying and involvement of stakeholders will assist in a smoother journey and keep commitment and involvement as to why the transformation is required.

Prioritize

As Rome wasn’t built in a day, the same is applicable for this phase. At this stage all kinds of information and challenges have been identified, whether they are organizational, lack of IBN-ready hardware, or resource issues. It will be impossible to fix all challenges at the same time, so there is a need to prioritize the identified challenges.

Prioritizing the solutions for identified challenges can be very difficult as the priorities might also change over time. However, a valid strategy can be applied in the prioritization of identified challenges, when the challenges are measured over the hierarchical aspects: chance of success, time, commitment, and budget.

The chance of success aspect is used to determine how successfully the existing network can be transformed to IBN. If the chance of success is greatly reduced by the identified challenge, then those challenges should be solved first.

Commitment is the second aspect that can be used to prioritize the challenges. If the organization lacks commitment for a transformation to IBN, then no resources, time, or budget can be made available. Lack of commitment also decreases the chance for support in executing mandatory changes that could impact the business.

The factor time is another aspect. This aspect is not intended for the time required to solve a challenge, but the available time to solve any challenge. If no time or resources are available, then it will be impossible to solve any other identified challenge.

The last but not least aspect is that of budget. Budget can determine whether certain challenges can be solved quickly or not at all—for example, a premature replacement of hardware or hiring extra staff to relieve the workload on the network operations team.

These aspects can then be used to prioritize the identified challenges of the previous paragraphs. Table 7-6 provides an example of how this can be applied.

Action Plan

The last step of phase one is to bundle all collected information into an action plan. The information obtained from the previous paragraphs is not only the identified challenges; the information also is implicitly a readiness scan of the campus network infrastructure and the enterprise. The action plan is used as a guidebook for getting support and approval of actions to be executed in phase two of the process. The action plan is a deliverable for this phase. Therefore, it is recommended to use a fixed format for that action plan that will contain at least the following sections.

Summary

The first phase in the transformation to IBN is all about getting information about the state of the campus network and the organization. IBN places a number of requirements on the campus network as well as the organization, because IBN is based on the Cisco Digital Network Architecture. To be able to successfully transform, it is important to know how the current network relates to IBN and what challenges might need to be solved to successfully move toward IBN.

To achieve this, a number of steps need to be executed and challenges related to these steps need to be determined:

• Challenges in day-to-day operations: IBN is primarily a method for how a campus network can be operated. This is primarily a responsibility for the network operations team. Although it is common to have project teams execute changes on an infrastructure and at project delivery hand the changed situation over to operations, this does introduce the risk that the project will not be accepted by operations because the team is too busy or just will not accept that new tool or solution. IBN must become a true part of network operations, and to do so, the operations team needs to have time and resources available to make steps on the journey. It is therefore important to identify challenges in the day-to-day operations that can hinder that transformation.

• Inventory: An inventory needs to be executed on all existing network devices used in the campus network. It is important to know whether both the hardware and the software are capable of running an Intent-enabled network.

• Level of standardization: IBN is based on a high level of automation. Automation can only occur if the design and configuration of the campus network, both wired and wireless, are standardized. In this step, the level of standardization is determined.

• Maturity level of an organization: Although it might sound odd for a phase within a technical transformation, the maturity level of an organization can be used to determine whether a transformation to IBN is possible from an organizational perspective. It also provides insight into how mature the organization is in relation to processes, documentation, and quality in general. IBN is a perspective on the Cisco Digital Network Architecture, and that poses a certain expectation on the maturity of the organization.

• Stakeholders: Last but not least, it is important to identify the stakeholders. As the transformation to IBN will incur changes in configuration, potentially replacing hardware, there will be business-impacting changes. Identifying the correct stakeholders beforehand and obtaining their support are critical for the success of transformation.

Once all steps are executed, a number of challenges have been identified. It is impossible to solve all challenges at once; therefore, a prioritization process is used to determine the order in which these challenges need to be solved. The prioritization is based on aspects like chance of success, commitment, time, and budget.

All collected data will be bundled in an action plan. The action plan contains the collected data, the identified challenges with recommended solutions, a detailed action list, a planning of those actions, possibly a list for decisions to be made on the management level, and a management summary. The action plan is essentially the deliverable of this phase and provides insights into the current state of the campus network and which challenges need to be solved to transform the campus network into an Intent-Based Network. Once the action plan is adopted and approved by management, the action plan is used in the next phase.