NCS provides a single network-wide interface to all network devices and all network applications and services, as well as a common modeling language and datastore for both services and devices. A transaction engine handles transactions from the operations at the service layer to the actual deployment of configuration changes in the network.
Designed to be a generic SDN solution, NCS supports the implementation of network applications and service on a wide variety of networking devices, both traditional hardware-based devices and virtual software appliances. NCS can also support Openflow-based applications through a built-in Openflow controller, Tailflow; alternatively, applications built on top of other Openflow controllers can be easily integrated into NCS.
NCS Overview Presentation (18 minutes)
Model-driven: Network services and devices are modeled into YANG and their configuration states are centrally stored in NCS. Model changes are easy to adapt. NCS automatically renders the device interface from the vendor’s device models. NCS also renders the complete service management functionality from the service models that are specified by the Service Provider.
Service-Aware: NCS provides a declarative way to specify how a network service shall be applied to the network infrastructure. This greatly facilitates the mapping of service configuration changes to device configuration commands. The entire service life-cycle is supported including creating, modifying and deleting service instances.
Transactions: NCS applies all service changes towards the network as an atomic change-set. This ensures that the network is always in a consistent state and can automatically recover from failed configuration changes.
Consistent State: NCS represents the true current state of the network services, the device configurations and the mapping between services and devices through a central data-store in real-time.
Tail-f Network Control System Datasheet
An overview of Multi-vendor Software-Defined Networking (SDN).
NCS — An Introduction for Network Engineers
Created specifically for Network Engineers, this 20+ page document explains the functions of NCS and how NCS works with devices and services.
Service Chaining: What and Why?
This datasheet discusses software-defined service chaining and how Tail-f’s NCS product provides a unified system for controlling all aspects of dynamic service chains, including traffic steering and third-party L4-L7 network functions.
NCS OpenStack Networking Plugin
Learn more about Tail-f’s NCS OpenStack plugin that permits automatic provisioning for multi-vendor networks in response to configuration changes. This allows OpenStack Networking to utilize the variety of layer 2 networking technologies found in complex real-world data centers.
Tailflow Module Datasheet
An overview of the OpenFlow Controller Module of Network Control System (NCS)
Network Control System (NCS) whitepaper
An overview of how NCS can be used as a Powertool for Network Engineers.
Automating Network and Service Conﬁguration Using NETCONF and YANG
A presentation on NETCONF and YANG for Service Automation presented at LISA Usenix 2011.
NCS Demo video
Jacob Ideskog, Technical Marketing Manager, gives a demonstration of the Tail-f NCS product.
- Problems Solved
- General NCS Configuration Management Principles
- Which types of network devices can NCS manage?
- How does NCS handle interfaces to devices?
- Can customers change the Network Element Driver (NED)?
- How does NCS deal with different software versions of a device?
- Can NCS validate configurations?
- What happens if NCS is temporarily down or unreachable?
- Can NCS do service configuration?
- Device Management
- How does NCS configure Juniper devices?
- How does NCS configure Cisco devices?
- How does NCS configure SNMP Devices?
- How does NCS manage OpenFlow devices?
- Transactions and roll-backs?
- What is unique about the way that NCS manages transactions?
- How can NCS do network transactions over non-transactional devices like SNMP, Cisco CLI?
- How can a network engineer work with NCS?
- How does NCS support different user categories?
- Can NCS do dry-run and what-if scenarios?
- What are the training requirements for NCS?
- How complex is it to install NCS?
- The Tail-f Difference
- How does NCS compare to other Configuration Management tools?
- How does NCS compare with Service Activation tools?
- Integration, Support and Hardware requirements
- What type of database does NCS require?
- Which northbound interfaces does NCS support?
- Does NCS support XML import and export?
- Does NCS support monitoring and fault management?
- Does NCS support syslog?
- Which logs does NCS generate?
- Does NCS support AAA?
- How does NCS ensure scalability?
- What is the typical hardware requirement?
Unlike other configuration managers on the market, NCS focuses not only on reading but WRITING deep fine-grained configurations to the network. NCS provides configuration management for both devices and network services. Any detailed parameter can be changed and NCS will generate the minimum configuration changes to the devices (not the entire config files).
NCS applies distributed transactions to all network changes. That is, if there is an error on any device when committing a change to the network, none of the other devices in that transaction will be changed. This includes non-transactional devices like CLI and SNMP. When NCS writes the configuration changes it is capable of generating any reverse operations to keep the network and NCS in a consistent state (these reverse operations are stored in rollback files).
NCS maintains a detailed real-time embedded configuration database of all devices and services and the mapping between service and device configurations. The database always provides a true view of the network.
NETCONF is the IETF protocol for configuration management (see RFC 6241). All Juniper JunOS devices support NETCONF. There is excellent support for NETCONF in NCS (in fact, one of Tail-f’s engineers, Martin Bjorklund, co-edited the NETCONF RFC).
In networks where there are frequent and complex changes and failure is expensive, our customers tell us that productivity and quality improvements outweigh the cost in environments with more than 20 devices.
Any device that can be remotely configured can be managed by NCS. This includes, routers, switches, load-balancers, firewalls, web servers and a whole host of other devices (both virtual and physical). Since it is not limited to one type of device or particular vendor, NCS allows for management of the entire network from a single pane of glass.
The device interfaces are managed by NCS Network Element Drivers (NEDs) and the accompanying toolkit. Tail-f provides NEDs to Juniper, Cisco, A10, F5, Brocade, HP, Huawei, and others. Additional NEDs can be ordered from Tail-f or developed by end-customers and integrators.
As part of the support contract Tail-f will support any device upgrades with the same NED functionality.
A key benefit of NCS is that every device interface (that is, every NED) is defined by its data model. Customers can add support in the data model for new commands or change commands to cover for bug fixes in the device.
When NCS connects to a device it discovers the device version and the appropriate data model version. The NCS Web interface, CLI, database and APIs are version-aware, so the correct model will be used. When committing changes to the network, a user can choose different strategies (require all devices to support all changes, or skip changes to devices not supporting them). The network engineer using NCS does not have to keep device versions in mind, NCS resolves all of this.
Yes, NCS supports deep fine-grain configuration validations. Validations can be applied to both devices and services. Validation constraints can be added at run-time to specify uniqueness, dependencies between configuration items and devices, and more.
Some examples of validations include:
- All URL’s must be unique
- All devices should have a management interface m0 with status up
- The MTU for ATM interfaces must be between 64 and 17966
NCS can reconcile any configuration change that happened out-of-band and allows a network engineer to determine which configuration is correct.
Absolutely! NCS is typically used for provisioning network services like VPNs, ACLs, BGP Peers, etc. It is of great value to have one product and one embedded database that provisions services and device configurations as one atomic transaction.
NCS supports fine-grained service updates: the user can change any aspect of a service and NCS will calculate the resulting minimum device configuration changes. NCS automatically cleans up the network when services are deleted.
NCS can also perform network audits to detect if any device configuration has changed with respect to the desired service configuration. The diff can be displayed and analyzed and the service can be re-deployed if needed.
Introducing new service types (VPN, Firewall Policies, etc.) into NCS Service models usually takes a matter of days. As with devices, services are defined by data models. Once a new service model is created, it can automatically be loaded and used for new service instances.
The Juniper NED, with a complete JunOS Schema, is part of the standard NCS offering. Upgrades are managed by reading the JunOS schema from the upgraded device and the NCS toolkit will re-render all the NCS functions from the newly read JunOS schema, including the user interfaces and the database schema.
The Cisco CLI NED is part of the standard NCS offering. It ships with data models for IOS, NX-OS, and IOS-XR. From these data models NCS renders Cisco CLI sequences and parse CLI outputs without any code. This means that adding support for new commands is a matter of adding the command to the model. Furthermore the model covers dependencies so NCS can generate commands and roll-backs in the correct order.
NCS can load SNMP MIBs and generate configuration commands directly from the MIBs. Before loading the MIBs an integrator can annotate the MIB with ordering dependencies so that a user does not need to know that a certain variable needs to have a certain value before changing another variable, which is common in SNMP. NCS also handles table relationships automatically.
NCS allows for transaction-based management of SNMP devices. The NCS diff-engine can generate the reverse operations to reach the previous state, thus supporting roll-backs also of SNMP devices.
NCS supports Openflow-based applications through a built-in Openflow controller, Tailflow; alternatively, applications built on top of other Openflow controllers can be easily integrated into NCS.
NCS does not just fire-off commands to the network, but rather confirms that all changes in the transaction are deployed correctly at the device level. If at any point of the series a device cannot be changed, the entire transaction is automatically roll-backed. This ensures that there is always a consistent network state. Complex rollback-scenarios like correct ordering of CLI commands is handled. The NCS database, the services and the devices configurations are all part of the same transaction.
Users can load network-wide rollback files to undo network changes.
NCS performs any configuration change as a diff operation against the current configuration. If a device does not support rollbacks, NCS can use the diff engine to calculate the diff between current state and the previous state before the configuration change is applied. NCS knows the capabilities for different network devices and will issue a config change or just a rollback command depending on the network device capabilities. The data models for the devices specify dependencies explicitly as directed references – this ensures that NCS knows in which order to create and delete items.
That is up to the user of NCS – it is configurable.
Truth is most network engineers are hard-core CLI users. NCS is the only product on the market that is designed with the network engineer in mind. NCS provides a network-wide CLI to a multi-vendor network. As a real-time abstraction of the network, it doesn’t matter which access methods are used, the network is always in a consistent state. Some of our customers use NCS for network automation by hooking it into their workflow systems, while at the same time having the CLI access for network engineers to quickly review and approve changes to device configurations.
NCS supports different interfaces for different users with different needs and skills:
- CLI for power-users
- Web interface for ad-hoc users
Before a transaction is committed a user can inspect the actual effect to the network in two ways:
- “Compare running brief” – this will show the difference between the desired configuration and the current configuration
- “Dry-run” – this will also involve any service provisioning logic and show the resulting device configurations
Limited training is required to get started. NCS is designed to be user friendly to network engineers by providing common tools that they are already familiar using, such as a CLI and a Web interface.
NCS installs in seconds. There are no third party requirements.
The NCS embedded configuration database and transaction engine is at the heart of the product. Whenever a NCS user changes a device or service configuration this change is applied as one single transaction including the NCS database as well as the devices. This means that the database will always represent the true state of the network. In case of out-of-band configurations, boot-strap scenarios, etc., NCS supports synchronization and comparison tools.
The database is an integral part of NCS, so schemas and database administration are managed automatically without requiring a database administrator.
The database can be imported, exported and queried using XML, XPath, and the CLI and Web interfaces. Programmatic interfaces to the database are also provided.
If you look at the marketing material, there seems to be a lot of configuration management tools on the market. However, when you dig into the actual functionality available for writing configurations to the devices, it is disappointing. The practice for these kinds of tools is to push and pull configuration files, store them, diff them and restore them. This works fine for static environments. The above tools do not actually understand the configurations, they treat them as opaque text files.
NCS on the other hand understands the configurations and represent them as fine-grained data structures in the embedded configuration database. Thereby NCS can provide configuration-aware tools like the CLI, configuration validation, an auto-rendered web interface, etc. And most importantly NCS can do real-time fine-grained changes rather than diffing and pulling configuration files.
Some vendors have fantastic tools for managing their specific devices. This works great if you have a single-vendor network. However, single-vendor networks are rare.
There are several stove-pipe activation tools (single-vendor, single service-type) that work very well for that specific vendor or service type. Service activation with these tools breaks down when a service requires different vendors or multiple service types. NCS is capable of handling multiple service types for multi-vendor networks.
NCS is unique in the way it communicates to the devices. Many activation tools require device “adaptors” that are custom-coded and expensive to maintain. The NCS Network Element Driver (NED) technology makes device integration simple.
Another difference is that NCS applies transactions to the activation chain. Many other activation tools are workflow-centric, which makes it very hard to recover from faults and in many cases they escape to manual work orders.
NCS also provides detailed knowledge of the device configurations: it can make sure that the service instance is consistent with the actual device configuration. NCS provides a network and service CLI as a powertool for network engineers. The visibility of the activation chain, using the CLI, service dry-run, etc, helps the network engineers trust the tool (this is harder to do with tools that just provides a magic OK button).
NCS ships with an embedded special-purpose database, so no external database server is needed.
The following interfaces are auto-rendered for all services and devices:
- CLI: for network engineers that prefer a Juniper or Cisco style command-line interface
- Web interface: for network engineers that prefer a graphical interface (the Web interface is highly customizable)
- REST: for programmatic access (exactly the same feature set as the CLI and Web interface)
- Java: for building custom applications and service provisioning logic
- NETCONF: for importing and exporting XML configurations
- SNMP: for reading status and receiving NCS alarms
NETCONF is an XML-based protocol. So by using the northbound NETCONF interface configuration data as well as operational data can be imported and exported. The NCS database has XML import and export tools.
NCC can poll counters and other operational data from the network and forward it to a monitoring system. Similarily, NCS can receive SNMP traps and, if appropriate, convert them to alarms that are sent northbound to a monitoring system.
NCS supports generating BSD and RFC 5424 syslog messages.
Developer logs, audit trail logs, web interface logs, device communication logs, XPath logs.
NCS contains a rich AAA engine that spans all interfaces. NCS supports role-based access control lists providing different access privileges to different users. These privileges may apply to a group of devices, or to individual devices, or to a any subset of any device configuration. External authentication can be used via Pluggable Application Module (PAM).
NCS is designed from the ground up to provide carrier-grade scalability and reliability. As part of release testing, Tail-f performs automated scalability testing of NCS managing 10,000 network devices. Tail-f’s core engineering team has their roots at a Tier 1 telecom device vendor. The experience which they gained working on managing scalable carrier grade network devices has gone into the design and implementation of NCS. NCS is designed so that processor power and available memory are the only limitations on how large NCS can scale. Internally, NCS is massively multi-threaded and designed to allow for concurrent processing and operator sessions. Execution threads are dynamic and come and go as processing needs dictate. NCS also provides support for multi-core processors. The user can configure NCS for how many cores of a multi-core processor it may execute on at once.
NCS requires a standard Unix box
- Medium (< 1000 devices): 4 Core CPU and 32 GB RAM
- Large (> 1000 devices): 8 Core CPU and 64 BG RAM
- Linux/x86 – Linux/x86 64
- MacOS 10.6/x86 64
- Solaris 10/SPARC
- Solaris 10/x86