In my previous articles we reviewed the overall topic of management interfaces to Taps and NPBs and took a deeper dive into Fault Management. In this chapter we will focus on the areas of configuration and provisioning management topics. Subsequent chapters will cover other management topics including software management, accounting, performance monitoring, security and remote access.
Configuration vs. Provisioning
I have found, in my experience, that it is a good practice to separate the device setup and operational provisioning into separate categories. The requirements are somewhat different when it comes to access control and security, persistence, ease of use, user interface, APIs, etc. In practice I typically use the term ‘Configuration’ to include any setup that is performed during the Day 1 setup of a device or anything that is done infrequently throughout its lifecycle, whereas, ‘Provisioning’ is a term I generally reserve for the types of activities that are performed frequently, typically by non-administrative users. I’ll start by defining both of these in more detail.
Configuration
The configuration function starts just after the device is initially booted and includes all of the aspects of device setup to enable the device to be integrated into the network and operations of the customer environment. This can include:
- Assigning network addressing (DHCP, static IP, DNS, etc.)
- Configuring the software options, including activating/deactivating any optional modules (we’ll discuss software management itself in a later chapter)
- Setting up of any licensing
- Configuration of management interfaces, and if applicable, separate management network connectivity and addressing
- Configuration of network management APIs such as SNMP, Syslog, NETConf, RESTConf, and security interfaces such as Radius, TACACS, security certificates, etc. (we’ll discuss security interfaces and security encryption in detail in a later chapter as well)
- Setup of user profiles and user accounts
- Setup of physical interfaces for the NPB and/or Tap connections
- Setup of any routing required to enable the NPB/Tap to function without disrupting normal network traffic, including failover modes
Once the initial configuration is complete, the device should be up and running, integrated into the network and the operations environment and be ready to be provisioned for the NPB and TAP specific services.
Configuration steps can occur again for the same device in the future anytime that it may be required, such as:
- Changes to the physical network
- Changes to the management operations network or interfaces being used for management
- Upgrades which may affect the base configuration of the device
- Changes to the role or scope of the device that require a change to the physical network
- Enabling of new features/interfaces which may require additional configuration steps
Provisioning
Provisioning is performed after the installer/administrator has finished the initial configuration of the device. The provisioning activities include anything that is used to enable the functional services of the device and to modify and update these over time. In NPBs and Taps this includes:
- Setup of monitoring ports and destinations
- Setup of routes, filters and flows within the unit
- Setup of traffic monitoring services such as IPFix
- Adjusting the filters or routing services to meet changing needs of the network
- Adding filters to manage security, traffic separation/aggregation or traffic grooming either for the network in general or for the feeds to other network traffic capture and analysis products
- Adding, deleting or modifying temporary routes and filters used to monitor for threats to the network or to manage network traffic during upgrades or outages
Provisioning can be performed by the same user that performs the configuration or can be delegated to a user with lower privilege levels which may only enable access to a subset of ports, filters and route services. This partitioning between Configuration and Provisioning roles is useful in preventing network disruption due to inadvertent changes to basic network connectivity and flows when the user only wants to modify monitoring or filters on tapped flows. I’ll discuss more on best practices in the data security section below.
Configuration Interfaces
Initial configuration occurs during box commissioning/setup, and likely occurs before the management network interfaces are in place, and before other user accounts are set up. In most cases the initial configuration is performed over a simple command line interface (CLI) and is access over a text based interface protocol:
- Secure Shell (SSH)
- Serial Port (RS-232, RS-422 and others)
- Serial Port over USB (virtual COM port)
Historically there were other CLI interfaces, however, those are rarely, if ever seen in modern devices. These are typically not secure in that they transfer the user identity/credentials and the configuration and command data in clear text. This is generally not an issue for serial port communication shown above since they are point to point local connections and not visible on a network. Some of the obsolete command line network protocols include:
Most, but not all, modern devices also have a Graphical User Interface (GUI). The graphical interface can be available on the initial startup or may require some configuration via CLI before it can be accessed. Generally a graphical user interface is easier to use, better structured, and provides more information to the operator at a glance. Graphical interfaces are highly preferred when users do not have the need to learn a new command line interface or when a device is rarely accessed such that a user would not know/remember command line syntax. A GUI is also helpful to configure complex/related parameters (such as port type/speed and routes within a device). A good example of devices that rely almost entirely on GUIs are home cable modem or wifi routers – they almost never have a CLI interface.
By far the most common graphical user interface protocol provided by a web server to a web browser running in the user’s desktop, table or mobile phone. There are several techniques used to render the graphical interface via web servers including:
- Hypertext Markup Language (HTML)
- The most recent version, HTML5, provide excellent capabilities in rendering the type of graphical interface needed for NPBs and Taps
- Java (utilizing Java Web start over HTTP/HTTPS) which invokes a Java application on the user’s client workstation, within the web browser environment, that can communicate back to the box being managed over other protocols including SSH, SSL, Netconf, JSON, RESTConf, etc.
- A Java GUI client has much more capability and is less limited than an HTML client interface, but is more complex to implement and support. Generally the JWS form of GUI client has fallen out of use as HTML has improved over the last decade.
Just as with CLI, there is a long history of other graphical user interfaces. Most of these have become obsolete due to security, complexity or support issues. The ubiquity of web browsers enabled a shift away from these client specific options:
- X11 – A form of remote GUI access that generally assumes a desktop environment is being supplied by the host unit.
- Dedicated Application – an application specific to each desktop environment such as Windows, Android, Mac, etc.
- Remote Desktop – involves running a desktop environment locally on the box and then allowing the user to remotely view/interact with it. There are also a number of commercial products which perform the same function such as VNC.
Application Programing Interfaces (APIs) are used when either a remote application or management system needs to communicate with the unit or when a downloaded client (such as JWS, a dedicated application, etc.) provided by the box vendor needs to communicate back to the box being managed. In TAPs and NPBs, APIs see common use in the areas of fault management and security, which we discuss in those chapters, but there is some use in the configuration area including:
- SNMP – While SNMP can be used for complete configuration and provisioning of a box, most commonly it is used for fault/status notification and for some very basic configuration such as IP addressing. SNMP has mostly be replaced with other provisioning APIs which we will describe below.
- Bootp/TFTP – While DHCP is commonly used to provide IP addressing/configuration information to a box, if more configuration data is required, then the bootp protocol can be used to identify a configuration file that can then be downloaded via TFTP. This allows for nearly completely unattended configuration of boxes into a network. It is more common in large scale deployments such as cable modems, edge routers, etc. but could be applied to Taps and NPBs if there are a large number to be setup.
Provisioning Interfaces
Provisioning user interfaces are generally the same as those used for configuration but once the activity switches from one time configuration to frequent provisioning we see a shift to greater emphasis on use of the GUIs and APIs.
Most provisioning will be performed via GUI interfaces using the HTML browser based technology.
In larger networks or larger devices where more sophisticated or more frequent provisioning is required or where some provisioning automation may be used (such as triggered failover or dynamically configured IPFIX), there is still a need for an API. In provisioning there are a few APIs that are used in addition to those shown in the configuration section above.
- NETCONF – NETCONF is my preferred provisioning interface since it is designed for the types of data and interaction required for provisioning sophisticated NPB systems. NETCONF can use many transport protocols and can be used to retrieve, set and transfer configuration between boxes. It also has enough data session and locking capabilities to make it robust enough for a multi-user environment.
- REST – The Representational State Transfer (REST) is also commonly used but we have found it is more applicable to state and event notification and that NETCONF is better suited for provisioning operations due to the locking, two-phase commit capabilities.
- Both NETCONF and RESTCONF use the YANG language for specifying the data structures used within the system. This allows for management systems to ‘discover’ the configuration model of a device or to identify if any changes to that model have been made over time.
As with the other interfaces, there are a number of obsolete provisioning interfaces that are worth mentioning for historical purposes:
- Corba – Common Object Request Broker Architecture
- CMIP – Common Management Interface Protocol
- RPC – Remote procedure calls, using protocols such as JSON or SOAP. These are usually used where there is tighter coupling between the client and the host box that is typically needed in TAPs and NPBs.
Configuration and Provisioning Data Management
Key requirements for NPBs and TAPs in the data management area include:
Data Storage
- Ensure data storage is reliable (persistence over reboot, reload, patching/upgrades, power failures, etc.)
- Include integrity checking to ensure corrupt data is not used
- Include a data rollback capability to revert to a previous configuration if the current configuration is found to be corrupt (aka internal backup/restore)
- Include a reset to factory default capability
- Ensure multi-user, multi-client (GUI, API, CLI, etc.) data writes do not create data integrity issues (i.e. record locking, two-phase commit, etc.
Data Auditing
- Keep a record of all changes, who made them and when
- Keep those records secure and protected from modification
- Provide an export mechanism for security/administrative personnel
Data Security
- Ensure all data access is protected by a trusted security mechanism (including read and write access)
- Encrypt all data in transit
- Authenticate and Authorize all readers and writers of data (i.e. know who they are and what they are allowed to access). This includes access via APIs.
- Partition sensitive data from unauthorized users
Backup and Restore
- Provide a simple and reliable means for configuration and provisioning data backup
- Backups that can be stored off-board and off-site to allow for disaster recovery
- Backup data is still considered sensitive so it should be protected (encrypted) to prevent unauthorized viewing
- Off-board backup should be automated
- Restore should be simple and reliable to allow for rapid return to service in the event recovery is needed
- Backup and restore should either include the software original image/patch source or should create an image of the software on the unit to allow for rapid recovery of the matching software version to the data version
- Restore should validate that the incoming data is a valid backup from this device, is valid for the current version of software running on the device and should confirm with the user to overwrite the existing data (i.e. confirm the backup file is not corrupt, is not from a different device, not from an older/newer software version, and has not been tampered with)
Export and Import
- Export/Import is distinct from Backup/Restore – Backup/Restore is to protect and recover the data for a given unit. Export/Import is to allow some or all data from one unit to be transferred to another unit or to another system or to import configuration data from another system
- Export should allow selection of which data from the device to export (i.e. it could include just the filter configuration, port configuration, user profiles, etc.)
- As with backup files, export files need to be considered sensitive data and must be protected from authorized access (encrypted or otherwise secured) unless explicitly selected by the user to utilize an unprotected format
- Export should allow multiple formats but each should include sufficient context along with the data to allow for the data to be imported at a future date. XML is a preferred format.
- Import, as with restore, should validate the incoming data is compatible with the device and should validate the data has not been tampered with
