UNIT - II

THE NETWORK MANAGEMENT PROBLEM

INTRODUCTION
 It describes networks that must be managed, and discusses the size and scope of networks and
the complexity of the managementtask.
 Finally, it concludes by describing the need for automated network management systems.
WHAT IS NETWORK MANAGEMENT?
 Network management involves everything from monitoring and troubleshooting your network to
making necessary changes and upgrades.
 It includes the network’s physical components, such as routers, switches and cables, as well as the
software that runs on the network, such as networking protocols and networking services.
 The most important task of network management is ensuring the network runs smoothly and
efficiently.
 It means regularly monitoring the network for potential problems and taking steps to prevent or
resolve them.
 Additionally, it involves rolling out the latest software and firmware updates. Administrators must
ensure that only authorized users have network access and that all data on the network is protected
from unauthorized access or modification.
 Network management has many different aspects, but the specifics vary from network to network.
For small networks, a single administrator may be able to handle all of the tasks involved in network
management.
 For bigger networks, however, it is often necessary to divide the tasks among a team of
administrators.
 Implementing controls and best practices ensures that your network resources are utilized
efficiently and effectively.
THE SCOPE OF NETWORK MANAGEMENT
1. Monitor for problems
 Hosts and services
 Levels of status: up, minor, major, critical
 To reach SLA
2. Monitor for tune-up
 Should we add more network bandwidth? For how much?
3. Detect the intrusion
 Intrusion detection against the hackers.
VARIETY AND MULTI-VENDOR ENVIRONMENTS
 A multi-vendor environment refers to a computer network that supports tools from more than one
manufacturer, vendor or provider.
 This is often considered a hybrid approach where companies add applications and platforms to
their environment to solve for particular business problems.
 For example, a company may choose a cloud service to gather data from many different origins.
 A computer networking professional would then be asked to make sure that the cloud
implementation is using networking resources properly because the cloud service and the
networking resources come from different vendors.
Some of the decisions and organization makes when creating a network can be sum- marized:
 The set of underlying technologies
 A vendor for each piece of hardware
 A set of services that will be offered
 A hardware platform for each service
 The physical and logical network topologies
ELEMENT AND NETWORK MANAGEMENT SYSTEMS
 Element Management System (EMS), as name suggests, is a software tool that is generally used to
manage all network elements.
 Here element represent node i.e. device such as computer, router, etc.
 Network Management System (NMS), as name suggest, is a software tool that is generally used to
manage and control network i.e. interconnected nodes.
 Why have vendors concentrated on Element Management Systems? There are three reasons.
 First, as we will see, designing a network management system is a non- trivial intellectual challenge;
vendors have tried to design such systems, but have not been extremely successful.
 Second, by restricting attention to a single network element, a vendor can eliminate most of the
complexity and concentrate on straightforward tasks such as monitoring.
 Third, because networks often contain elements from multiple vendors, a network management
system must accommodate other vendors’ products and a given vendor is unlikely to create a
system that makes it easy to use competitors’ products.
SCALE AND COMPLEXITY
 Network management systems must contend with complexity that arises from large scale.
 Vendors recognize the differences, and design network elementsthat are appropriate for each size.
 For example, the smallest Ethernet hubs only accommodate four connections, and run all ports at
the same speed. The largest Ethernet switches accommodate hundreds of connections, allow each
port to negotiate a speed, and can be expanded by connecting multiple units together.
 The smallest networks that correspond to those found in a residence or small business usually
consist of one main network element plus wiring and a few supporting hardware items.
 For example, engineers use the term SOHO (Small Office, Home Office) to characterize network
elements intended for a network with only a few computers. Thus, one might refer to an IP router
intended for such an environment as a SOHO router.
 Intermediate size networks can be found in a business, university, or government organization that
has a single campus.
 For example, at one university, which has approximately 36,000 undergraduate students, the IT
organization manages a network that includes classrooms, administrative and faculty offices, and
residence halls.
Items in an example university campus network that are managed by the university’s IT staff.
Additional facilities in departments such as Computer Science are managed independently.

Although exceptions exist, organizations with a single site generally have network sizes that range up
to the following:
 500 IP Subnets
200 IP Routers
1200 Layer 2 switches
3000 Wireless access points

Companies with multiple sites usually have much larger networks than companies with one site. For
example, the network in one multi-national corporation includes:
8000 IP Subnets
1200 IP Routers
1700 Layer 2 switches
4000 Wireless access points

Interestingly, the network in an ISP does not typically employ a large variety of equipment.
For example, a network in an intermediate-size ISP (called a Tier-2 ISP) might include:
2000 IP Subnets
400 IP Routers
4000 Layer 2 switches

By comparison, the network in a small ISP (sometimes called a Mom and Pop shop or a Tier 3 ISP) might
contain:
2 IP Subnets
2 IP Routers
2 Layer 2 switches
1 DSLAM

 Large size increases the difficulty of network management for several reasons. First, large networks
have a greater variety of equipment and services.
 Large network spans multiple physical sites, management involves multiple individuals.
 Interrelations among Various Parts of a Large Network Mean That Significantly More Data must be
considered When Assessing Performance or Diagnosing Problems.
TYPES OF NETWORKS
To aid in discussions of management tasks, networks are often classified according to their main
purpose.
Four categories are typically used
1. Carrier
2. Service provider
3. Enterprise
4. Residence/Consumer
CARRIER NETWORK:
 A carrier is a long-distance phone company that owns and operates a very high capacity network
that is used to pass Internet traffic among other ISPs.
 Larger service providers connect to carriers; a carrier connects to other carriers at Internet peering
points.
 Carrier networks use data connections with very high throughput, and require equipment that can
switch the most packets per second.
SERVICE PROVIDER NETWORK:
 An Internet Service Provider (ISP) network is designed to provide transit between individual
customers’ networks and the Internet.
 A small ISP connects to a larger ISP; a large ISP connects to a carrier.
 Service provider networks focus on aggregation — data from many subscribers is multiplexed on to
a single high- capacity connection that leads toward the center of the Internet.
ENTERPRISE NETWORK:
 An enterprise network is designed to interconnect host computer systems within an organization
and to provide those systems with access to the Internet.
 Most traffic on an enterprise network arises from a computer within the organization (e.g., a desktop
computer in an office), and is destined to a computer within the organization (e.g., a server in the
data center).
 Instead of focusing on aggregation, an enterprise network is designed to permit multiple internal
conversations to proceed at the same time.
RESIDENCE/CONSUMER NETWORK:
 A residential network consists of one or two computers in a home that connect through a router to
an ISP, typically using DSL or cable modem technology.
CLASSIFICATION OF DEVICES
In addition to using the above terminology to characterize networks, managers sometimes classify
network elements and related hardware as belonging to one of three basic types
1. Core
2. Edge
3. Access
CORE ROUTER:
 A core router is designed to operate in the ‘‘center’’ of the Internet.
 A carrier or a large ISP designs core router for use.
 To handle a high traffic load, a core device operates at high speed, and is optimized to forward traffic
as quickly as possible.
 To achieve the highest possible speed, a core device does not inspect packet contents, check for
authorization, or report detailed statistics about traffic.
 Network must be designed to check packets before the packets arrive at a core device.
EDGE ROUTER:
 An edge router operates in the fringe areas of the Internet, far from the core.
 Typically, managers interpret edge as an enterprise or a residence.
 An enterprise might use an edge router in its data center to connect multiple subnets, or might use
an edge router to connect departments or floors of a building.
 Edge routers usually offer more functionality, but have lower speed than core routers.
 For example, an edge router might include a blade that provides the encryption and decryption
needed by a VPN connection.
ACCESS ROUTER:
 An access router provides the connection between the edge and the core.
 Access routers are typically found in ISPs, and are used to connect the ISP’s customers to the rest of
the Internet.
 Access routers often handle tasks such as authentication, intrusion detection, and accounting. Thus,
an access router unusually has lower overall throughput than a core router.
 ISP can use multiple access routers to connect to customers, and then aggregate traffic from the
access routers to a smaller set of (possibly one) core routers.

FCAPS: THE INDUSTRY STANDARD DEFINITION

Network management vendors often use the acronym FCAPS when discussing net- work management.

THE MOTIVATION FOR AUTOMATION

 The discussion above shows that network management is a broad topic that involves many aspects
and a myriad of details.
 One would expect, however, that much of the work can be automated, making it possible to manage
large networks without requiring manual intervention. Indeed, it seems that network management
is an ideal candidate for automation because the underlying network elements themselves are digital
devices inherently capable of computation and communication.
 Engineers who build network elements are familiar with automated control systems and already
design control mechanisms into products, it should be trivial to add the facilities for automated
network management.
 In addition to the apparent ease of adding automated network management to exist- ing products, a
strong economic motivation exists. From a
 Network operator’s point of view, current network management is labor-intensive, requires in-
house expertise, and because humans are involved, is prone to errors and slow. Human error has
become extremely important because the complexity of management tasks continues to increase.
 Consider a firewall configuration that includes hundreds of individual rules. In addition to errors
that arise from mistyping configurations, errors can occur because the rule set is too large for a
human to remember and understand. Humans also tend to introduce consistency errors.
 when a large set of devices is configured manually, chances are high that the configurations will be
inconsistent. Unfortunately, inconsistencies can remain hidden, and can be difficult to find when
 problems occur. Because network downtime incurs economic loss, problems that arise from human
error are especially important.
 In addition to eliminating inconsistencies, automation can reduce economic impact by reducing the
downtime needed for upgrades and other changes. In some cases, automated systems can make
changes on the fly.
 An intrusion detection sys- tem can automatically modify firewall rules to stop a problem that is in
progress. Finally, from a networking vendor’s point of view, automated network management will
in- crease sales because automation will allow customers to create larger, more complex networks.
WHY AUTOMATION HAS NOT OCCURRED
 Given the strong economic motivation and necessary mechanisms in place to make implementation
straightforward.
 As we will see in Part 2 of the text, both the networking industry and the open source community
have produced tools that automate some aspects of network management.
 The overall goal of a comprehensive automated system has remained elusive. The reason is
fundamental: a lack of abstractions and principles.
 Abstractions are needed that allow us to master the complexity without sacrificing understanding.
 The key does not merely arise from automating the way humans deal with current network
elements. Instead, we need new paradigms that permit managers to specify policies and use an
automated system to implement the policies.
 Currently a manager must manually configure the firewall rules in each of the routers that has an
Internet connection.
 It may seem that we can automate the task by having the manager specify the rules, give a list of
routers, and ask the network management system to install the rules in each ofthe routers on
the list.
 Although it alleviates some of the manual effort and is less prone to error than having a human
enter rules multiple times, having a manager specify rules and specific routers means the interface
is low-level.
 A more efficient approach has the network management system understand where external
connections occur, allows a manager to state policies for external communication, and arranges for
the network management system to translate policies into rules and install them automatically.
ORGANIZATION OF MANAGEMENT SOFTWARE
 Will we ever be able to create a single, fixed network management system that accepts high-level
policy statements and handles all tasks needed to implement arbitrary policies? Many managers
argue that such a system is impossible: as networks evolve, requirements change.
 A fixed system will never be sufficient, they argue, because new types of policies will be needed.
 A network management system in the 1980’s might have included some knowledge of security, but
network security has changed dramatically in the succeeding years.
 An automated network management system must be able to accommodate new types of policies as
well as new policies.
 To allow an automated system to remain flexible, a two-level approach has been proposed
 A low-level platform that offers a programmable interface and a level of software that uses the low-
level platform to translate policies into actions.

 The second layer, which implements policy, can be adapted as new types of policies arise.
 To make the approach flexible, the second level can be structured as a set of modules that each
handle one type of policy.
 When a manager makes a request, a user interface directs the request to the appropriate policy
module.
 Flexibility arises because implementation of a new type of policy can be handled without requiring
the underlying system to change
 New policy modules can be added and existing policy modules can be changed as needed.
 A detailed view of the two-level structure for an automated net- work management system. Policy
modules can be changed, and new policy modules can be added at any time.
 It has been pointed out that the two-level approach in Figure 3.4 is analogous to that of an operating
system. An operating system provides a fixed kernel that supplies basic functions, and application
software uses the operating system to implement more functionality that is complex.
 we can observe that network management systems are in approximately the same state as operating
systems were in the early 1960s. Coherent, practical operating systems only became possible after
computer scientists devised a new set of abstractions such as processes, files, and directories. In later
chapters, we will understand that although the ideas described above provide an overall framework,
before coherent, practical network management systems can be built, an analogous set of
abstractions must be defined.

SUMMARY
 The problem of network management is difficult for several reasons.
 In addition to a wide variety of network elements and services with a myriad of parameters, each
network is unique and there are few general patterns.
 Many networks are large, and networks needed by carriers, service providers, and enterprises differ
in purpose and functionality. Vendors have concentrated on Element Management Systems.
 Automated network management is desirable, and some general properties of an automated system
are understood.
 In particular, to keep an automated system flexible and accommodate future needs, a two-level
structure can be used in which a fixed underlying system provides a programmable interface to allow
a second level of software to implement policies.
 However, before an effective and practical automated network management system can be built,
new principles and abstractions are needed.
CONFIGURATION AND OPERATION
INTRODUCTION
Previous chapters introduce terminology and concepts from network management systems, and
give examples of network scale. Chapter 2 lists example network elements along with configuration
parameters for each, and Chapter 3 argues that the variety of network elements and services
contributes to the difficulty of network management. Finally, Chapter 3 introduces the FCAPS model
that divides management tasks into five main areas.
This chapter continues the discussion by focusing on one of the most important aspects of FCAPS
in more detail: configuration. The chapter explains why an apparently straightforward task such as
configuration is complex, and discusses some of the consequences for network management systems.
Succeeding chapters each examine one other aspect of the FCAPS model.
INTUITION FOR CONFIGURATION
 Because personal computer operating systems and most consumer application software allow a user
to configure operations, most computer users have an intuitive understanding of configuration.
 The operating system on a typical laptop computer allows a user to configure a timeout after which
the laptop hibernates to save the battery (e.g., turns off the screen), and a typical browser allows a
user to configure the URL of a web page that will be used whenever the user clicks the Home button.
Configuration of devices and services in a computer network.
We can characterize configuration by stating the general properties listed
1. Configuration is a step that occurs (i.e., must be performed) before a computer system or
application program is used.
2. Configuration requires a user (i.e., manager) to make a set of choices that will control the
operation of a computer system or the execution of software.
3. Although a configuration can be changed, modifications may require the underlying system to
be paused, or shut down and restarted.
 4. The interface used for configuration can differ entirely from the interface used when the system
runs. In a network, the running sys- tem that processes packets may not have a user interface.

CONFIGURATION AND PROTOCOL LAYERING

 Network elements and services along with examples of specific configuration parameters.
 Although the example parameters illustrate the wide variety of configurable items, they do not
capture the important conceptual abstractions that underlie configuration.
 Because configuration parameters are merely the mechanism used to achieve a desired result,
understanding configuration re- quires us to understand the ultimate goal.
 The next sections give examples of the conceptual relationship between configurable items in network
elements, layers of a proto- col stack, and results that the parameters are used to achieve.
1. TOPOLOGY AND LAYER 2:

 We said that network elements operating at Layer 2 have relatively few configurable parameters
because much of Layer 2 can be handled automatically.
 One key idea emerges when we consider a configurable VLAN switch: configuration can be used to
create a topology.
 In essence, VLAN configuration is a logical replacement for Layer 1 wiring instead of creating a
topology from a set of basic switches with wiring used to attach a computer to a specific switch, a
manager wires all computers to a large VLAN switch and configures the switch to act like a set of
separate switches.
 The chief advantage of using configuration is ease of change: moving a computer from one VLAN to
another can be accomplished with a few keystrokes.
2. LOGICAL SUBNETS AND LAYER 3:
 Configuration of IP addresses and address masks at Layer 3 is only a detail the ultimate goal consists
of establishing an IP subnet-addressing scheme that is correct and makes forwarding efficient.
 When configuring IP addresses and address masks in routers, a manager must guarantee that, each
network is assigned a unique address prefix (and each host is assigned a unique suffix).
 Although most networks configure a prefix for each network manually, DHCP protocol software can
be used to assign an address to each host automatically.
 Despite the use of DHCP, manual prefix configuration is needed before assignment because the prefix
assigned to a network appears in each address assigned to a host on the network.
 A DHCP server must itself be configured to know the network prefix before the server can assign
addresses to hosts on a network.
 We can view DHCP as only assigning host suffixes automatically; the prefix in each assigned address
is the prefix that was configured for the network.
3. ACCESS AND LAYER 4:
 Many of the parameters associated with Layer 4 of the protocol stack are assigned automatically.
 For example, when a client, such as a web browser, contacts a server, the TCP protocol software that
runs in the operating system on the client computer assigns the TCP port number that the client uses
automatically.
 In addition, network elements such as NAT boxes or load balancers use information found in the
Layer 4 protocol headers of packets to build a cache of connections.
 A network manager does not usually configure connection information in a NAT device.
 Despite automated configuration of items on the forwarding path, some manual configuration of
Layer 4 is still needed.
 Manual configuration focuses on the Layer 4 control path rather than on the data path. That is,
configuration information specifies what a system is permitted or is prohibited from doing.
 As an example of Layer 4 configuration, consider the access rules configured into a firewall.
 A typical rule specifies a combination of items such as IP source and destination addresses, a
transport protocol type (e.g., TCP), and source and destination proto- col port numbers that are to
be allowed or denied (i.e., for which packets are permitted to pass or are dropped).
 ANAT system often allows a manager to preconfigure mappings for specific combinations of
addresses and protocol port numbers.
 Although the port numbers that Layer 4 protocols use for communication are either selected by
server applications or assigned to clients automatically, some network systems allow managers to
configure access specifications that involve Layer 4 parameters.
4. Applications And Layer 5 (or Layer 7):
 Application programs operate at either Layer 5 or 7, depending on whether one uses the 5-layer
model that was designed to describe TCP/IP protocols or the less accurate OSI model.
 In any case, the point is the same: a manager can configure specific applications to operate on specific
computers.
Consider the naming service provided by the Domain Name Sys- tem (DNS). There are two
aspects related to configuration of DNS:
I. Configuration of client and server software that uses DNS to enable communication
II. Configuration of DNS server(s) with specific content
Under the first item, a manager must choose a computer(s) that will run a DNS server, configure the
server software to begin running automatically when the computer boots, and configure each server to
know the addresses of servers for the parent zone and child zones. In addition, a manager must arrange
for other computers in the net- work to know which computer provides a DNS server (i.e., which
computer to contact when name resolution is needed). In cases where DHCP is used to supply the
address of a DNS server at boot time, instead of configuring individual computers, the manager merely
needs to configure the DHCP server to distribute the correct host addresses.
Under the second item, a manager must supply data for a DNS server to distribute. In particular, a
manager must load each DNS server with a set of resource records that specify name bindings, where
each name binding consists of a pair ( name, address ).
In addition to configuring communication among DNS servers and DNS clients, a manager must
configure a set of name-to-address bindings.
DEPENDENCIES AMONG CONFIGURATION PARAMETERS
It may seem that the examples in the previous sections each refer to conceptually independent items
at one layer of the protocol stack.
Although the management interfaces in network elements allow a manager to configure parameters
independently, many parameters are semantically related.
Consider the relationship between configuration of IP subnets at Layer 3 and configuration of
topology at Layer 2. We said that a manager must assign a unique IP prefix to each network. For a multi-
access broadcast network (e.g., Ether- net), the Internet Protocol relies on ARP to resolve the IP
addresses of a next hop to the corresponding MAC address. Because ARP uses broadcast, the definition
of network is the same as a broadcast domain. We also saw that for a network using a Layer 2 switch,
the broadcast domain for a given computer corresponds to the set of computers that attach to the same
VLAN. Furthermore, a manager can configure an arbitrary port on a switch to be on an arbitrary VLAN.
As a result, a semantic dependency exists between topology configuration and subnet configuration: a
topology must be configured at Layer 2 before IP prefixes can be assigned at Layer 3.
 Although network elements permit configuration parameters to be changed in arbitrary ways,
dependencies mean that changing one parameter without changing others can cause errors. For
example, if a manager moves a switch port from one VLAN to another without also changing the IP
address assigned to the computer, the IP prefix will be incorrect. Similarly, if a manager reconfigures
the IP address of a computer without changing the corresponding entry in the DNS database, the DNS
server will re- turn an incorrect mapping.
Although network elements permit a manager to change arbitrary configuration parameters,
semantic dependencies among parameters mean that changing a single item without changing
dependent items, possibly at other layers of the protocol stack, can result in a configuration that is
globally invalid.
CONFIGURATION AND TEMPORAL CONSEQUENCES
If the notion of binding values to parameters does not adequately capture the concept of network
configuration, what does? To understand the problem, consider how a network operates. In general, a
manager connects equipment, configures each network element, and then enables network operation.
Some configuration parameters merely specify initial conditions that can change once the network
becomes operational, and other configuration parameters control how the network operates once
packets begin to flow. For example, the initial set of routes configured into routers specify the paths
packets will take when a network begins operating. However, the choice of whether to configure a
routing update protocol (e.g., RIP or OSPF) determines whether a network will be able to detect and
route around link failures.
Because it requires a network manager to imagine how a network will operate in the future, the
notion of changes over time complicates configuration. In fact, a manager may need to work backward
by envisioning a running network and then imagining a series of steps by which the network reaches
the running condition. To envision such steps, a manager must understand how each configuration
choice affects the network over time, and must choose values that generate initial conditions that will
eventually produce the desired operation. That is, a manager must think about the temporal
consequences of each configuration choice.
CONFIGURATION AND GLOBAL CONSISTENCY
In addition to thinking about temporal changes, a network manager must under- stand how
configuration choices interact. That is, a manager must envision the global state of the network rather
than each individual configuration parameter. In other words, a manager must understand how the
values stored in each network element collectively ensure the network achieves desired properties. For
example, consider for- warding. To provide Internet connectivity to all hosts, a manager cannot
configure one router in isolation, but instead must consider the forwarding state that spans the entire
set of routers. Although a manager configures each network element independently, the routes must
be globally consistent to guarantee the property that all hosts can reach the Internet.
The fundamental goal that a network manager must consider when choosing a configuration is the
desired global state of the network; configuration is merely a mechanism that allows one to specify
details of an initial state and control changes to the state as time proceeds.
An important observation regarding state is that multiple valid states can exist. In the example
above, for instance, it may be possible to have multiple route configurations which each guarantee that
any host can reach the Internet. Thus, a manager can- not know whether a given network element has
correct forwarding information without considering the global network state.
Because multiple network states can be valid, the validity of the configuration on a single network
element can only be assessed relative to the configuration of other network elements.
GLOBAL STATE AND PRACTICAL SYSTEMS
As we will see later, the importance of consistency across an entire network influences the design of
automated management systems. For now, it is sufficient to under- stand a key idea: although global
state is an essential concept, building software to capture and manipulate global state is impractical.
That is, except for trivially small, idle networks, we cannot expect to record the complete state of a
network.
Recording global state is impractical for three reasons. First, because a network contains multiple
network elements and because each network element is complex, an extraordinary amount of data is
needed to represent the entire state of a network. Second, because network state changes over time,
capturing global state requires simultaneously capturing state information from all network elements.
Third, in addition to relatively static values, global state includes packet queues, which change
continuously.
With respect to the large size, one might conclude that forwarding tables constitute the bulk of the
state information. However, in addition to forwarding information, net- work elements contain
protocol software, an operating system, device drivers, control and management software, firmware,
and other data in memory. Thus, even if we ignore the underlying hardware, a single network element
includes an immense amount of state.
 The need for simultaneous state capture should be obvious: without a temporal snapshot, the state
can be inconsistent. For example, imagine capturing the forwarding tables in routers as routes are
changing. If the tables in some elements are captured be- fore the change and the tables in others are
captured after the change, the saved data will not represent a valid global state of the network.
Although packets in the network form part of the state, a more significant problem arises from the
management data itself: as we will learn in a later chapter, network management systems use the
managed network to communicate with network elements. That is, management data flows through
the same wires and network elements as user data. Thus, to record the state of multiple network
elements requires the transmission of packets (i.e., one cannot ‘‘freeze’’ a network, record the state, and
restart the network once the state has been captured).
CONFIGURATION AND DEFAULT VALUES
What is the relationship between the configuration a manager specifies for a net- work element and
the initial state of an element? It might seem that except for specifying basic software (e.g., the operating
system to run), a manager must completely specify the initial state of an element. In practice, however,
only a handful of parameters are needed before a typical network element can function, far fewer
parameters than are needed to specify an initial state for the element.
Are configuration parameters merely abbreviations that the management interface expands to cover
many items? No. The brevity arises from network vendors’ desire to make network configuration as
easy as possible. Vendors follow an approach that uses default values.
Instead of requiring a manager to specify values for all parameters, a management interface begins
with a set of default values and allows the manager to override specific values.
Because it eliminates the opportunity for error, an interface that uses defaults is especially helpful
for devices that are managed directly by a human. Ironically, implicit defaults mean that automated
software that manages a network element must have knowledge of how the element works.
PARTIAL STATE, AUTOMATIC UPDATE, AND RECOVERY
We said that although a configuration specifies some of the items in the initial state of a network
element, changes to the state occur as the element operates. For example, ARP adds entries to a cache,
routing update protocols change routes, and a firewall updates filter rules. Interestingly, the notion of
dynamic state change has an important implication
Because the state of a network element or service can change dynamically as the network operates,
configuration information alone does not specify network state.
 The ideas that network element state varies over time and that state can depend on traffic in the
network are especially important when one considers failure recovery. Reloading a configuration and
restarting a network element can only restore partial state information changes that occur between the
time a device is started and the time a failure occurs cannot be recovered.
To further complicate the situation, the hardware in some network elements allows the element to
store some or all state information in nonvolatile memory. As a trivial example, consider a VLAN switch
that stores port status information in nonvolatile memory, but keeps other configuration data in
volatile memory. That is, when a manager configures a port to be enabled or disabled, the hardware
permanently stores the setting so it can be recovered when the hardware reboots. Power cycling such
a de- vice nullifies the assignment of ports to VLANs, but allows individual port status to survive
unchanged.
INTERFACE PARADIGM AND INCREMENTAL CONFIGURATION
Network elements that use a command-line interface typically allow a manager to enter a series of
configuration commands that each make one small change†. That is, each command adds a small
incremental change to the configuration. To achieve a desired effect, a manager who is using an
incremental interface may need to apply multiple commands (e.g., change a value in the forwarding
table to use a specific interface and enable the interface). In such cases, encountering an error can
complicate the interaction if an error prevents further progress, a manager may need to undo previous
commands in the series.
To help managers master the complexity, some management interfaces allow a series of commands
to be viewed as an atomic unit. That is, all commands in the set should be applied or none of them
should be applied. We use the term transaction to describe a set of operations that are to be treated
atomically. In cases where a command-line interface offers incremental commands that each perform
one small step, a transaction can include a series of many commands. In cases where a command-line
interface offers complex commands that each perform many steps, a transaction can consist of a single
command. For example, suppose the management interface on a router offers a single command that
enables all interfaces. If the command runs as a transaction and a hardware problem prevents one of
the interfaces from being enabled, the command reports the error without enabling any of the
interfaces.
In addition to interfaces that automatically decide how to group commands into transactions, it is
possible for an interface to allow a manager to define transactions dynamically.
 It should be obvious that allowing a manager to define the scope of a transaction provides much more
flexibility than an interface in which the contents of transactions are predetermined. The downside of
permitting managers to specify the boundary of atomicity lies in arbitrary scope: the system must be
able to restore the original state if an error occurs while the transaction is being executed.
Interface Paradigm and Incremental Configuration
transaction name
{
command1
command2
...
commandn
} end of transaction

To understand the potential problem, assume a manager has enclosed commands in a transaction
that each modify a large data structure (e.g., an ARP cache or a forwarding table). The system must
store information needed to recreate the original data structures in case a command in the transaction
fails. However, storing a copy of data items re- quires extra memory.
Interestingly, network elements differ in the way they implement configuration changes some
elements apply each change immediately, and others require a reboot before a change takes effect. In
either case, the consequences of an error can be catastrophic: the element can become unreachable,
either immediately or after a reboot. Section 4.13 considers how an automated rollback mechanism can
help recover after a catastrophic configuration error.
COMMIT AND ROLLBACK DURING CONFIGURATION
As an alternative to an interface that defines transactions, some element management systems
provide a manager with manual mechanisms for undoing partial configurations.
There are two main types
1. Snapshot rollback
2. Incremental rollback
The easiest mechanism to understand involves the use of a snapshot rollback. Be- fore making
configuration changes, a manager takes a snapshot of the configuration (i.e., a snapshot that captures
the current state of the network element). The manager then proceeds to enter commands that make
changes to the network element. The changes can be extensive (i.e., they can make arbitrary
modifications to the network element). Because each command takes effect immediately, a manager
can test the system at any time to verify whether the change has produced the desired result. If a
manager encounters a problem or decides to forgo any change, the manager instructs the system to use
the snapshot to rollback the system to its previous state.
The second manual mechanism that element management systems use consists of incremental
rollback. In essence, an incremental rollback provides a manager with the ability to undo the previous
command or transaction. The most significant limit of incremental rollback arises from the number of
previous operations that can be rolled back. A system that allows only one previous operation to be
undone is less useful than a system that allows an arbitrary number of previous operations to be
undone. However, permitting arbitrary rollback requires the system to store information about each
previous operation.
AUTOMATED ROLLBACK AND TIMEOUT
The concept of rollback can be extended to include a timeout mechanism: when a manager initiates
a transaction, the system starts a timer. If the transaction fails or does not complete before the timer
expires, the system automatically informs the manager that the transaction cannot be completed, and
invokes the rollback mechanism to restore the system. Automated rollback is helpful in situations
where a transaction requires such a long time to execute that a manager becomes distracted or in
situations where an error in the configuration prevents further communication between the element
and the manager.
At least one vendor includes automated rollback as part of their management inter- face. In the
vendor’s system, if a transaction does not complete within N seconds (de- fault is 75 seconds), the
transaction is automatically rolled back.
SNAPSHOT, CONFIGURATION, PARTIAL STATE
How much information must be stored for rollback?
The answer depends on whether the system stores a copy of all state or merely enough
information to restorethe state. If a command has an inverse, the inverse command requires much less
space than a complete system snapshot. Thus, if a manager moves a switch port from VLANi to VLAN
j, the system can store a rollback command that moves the port from VLANj to VLAN i. In cases where
a management command has no inverse, it may be necessary to store a snapshot of a data structure
or of the complete system.
 when the operating system in a network element is reloaded, so much of the state changes that
it is usually easier to restore a snapshot.
The existence of inverse commands determines whether the snapshot or incremental
approaches to rollback require more space. Consider a system that permits incremental rollback of N
commands. If each command has an inverse, the space taken to store incremental rollback information
is Nc, where c is the space required to store one command. If none of the commands has an inverse,
however, the system requires space of NS, where S is the size of a complete snapshot. Thus, if commands
do not have an inverse, incremental rollback can take significantly more space than requiring a manager
to save a snapshot manually.
We can generalize the above discussion: the amount of space required to store a snapshot
depends on whether the system stores internal data values or the information needed to recreate the
data values. In fact, it may seem that space can be minimized by storing an entire configuration rather
than data values.
Some network elements do indeed allow a manager to download a complete configuration in
one-step rather than enter one piece of configuration at a time. However, we must remember that
although it handles many items, configuration information only specifies part of the state information.
Thus, it is important to differentiate between rolling back to a previous state and recreating state from
partial information.
SEPARATION OF SETUP AND ACTIVATION
Some interfaces use an alternative paradigm to avoid problems that arise as configuration
changes occur. Instead of applying incremental changes, the interface separates configuration into two
complete steps that are known as setup and activation.
During the setup phase, a manager downloads a set of configuration requests, which an element
checks for consistency and correctness without applying the changes. If the requests fail the correctness
test, a manager must start again by downloading a re- vised set of requests. Thus, a manager iterates
through revisions until the set of re- quests satisfies the target element.
Once an element has approved a set of requests, the element allows a manager to activate the
changes. Because an element can preprocess requests and generate appropriate internal data
structures, activation can occur rapidly. In particular, it can be possible for an element that uses
activation to install a new configuration without a reboot.
CONFIGURING MULTIPLE NETWORK ELEMENTS
So far, we have concentrated on configuration of a single network element. As we will see later,
configuration of services that cross multiple network elements is significantly more complex. For
example, an MPLS tunnel can span many routers. Similarly, coordination may be needed between the
configuration of network elements and the configuration of services such as DHCP. As a consequence,
complex configuration re- quires that transactions and rollback be coordinated across multiple
platforms.
There are two general approaches: recursive, in which each element makes a re- quest of
another until the transaction can be satisfied, and iterative, in which a management system contacts
each of the network elements that are needed for a transaction. The recursive approach allows
dependencies to be hidden, but can lead to circularity and deadlock. The iterative approach eliminates
circularities, but requires the management system to understand all dependencies and interact with
each network element.
SUMMARY
Configuration is one of the most important and difficult aspects of network management.
Although configuration occurs at each layer of the protocol stack, semantic dependencies occur among
configured items.
Because it specifies initial state and controls operation, configuration is related to the global
state of a network. Although many items are configured, the state of a net- work element can change as
the network operates. Furthermore, the validity of a net- work element’s configuration can only be
assessed with respect to the global configuration of the network.
A management interface on a network element can permit incremental changes to a
configuration; transactions are used to group changes into atomic units. An interface can support
snapshot rollback or incremental rollback; the size of saved information for rollback depends on
whether each configuration command has an inverse and the number of previous commands that can
be undone.
Configuration of services across multiple network elements is significantly more difficult than
configuration of a single network element. In a recursive approach, control passes from element to
element; in an iterative approach, a manager configures one element at a time.