Network Configuration Management with NETCONF and YANG J¨ urgen Sch¨ onw¨ alder 84th IETF Meeting, Vancouver, 2012-07-29 1 / 90
Network Management Protocol Soup SID/TAM CMIN/WBEM GDMO/CMIP [TMFORUM] [DMTF] IE/IPFIX [OSI] [IETF] YANG/NETCONF TR069/SOAP [IETF] [BROADBANDFORUM] DME/DCE SMI/SNMP [OSF] [IETF] DEN/LDAP SPPI/COPS−PR [DMTF] [IETF] TL1 [TELCORDIA] POLICY/COPS TINA/ODL/CORBA [IETF] [TINA−C] CLI [VENDORS] EC2 [AMAZON] SYSLOG [BSD/IETF] ⊲ See RFC 6632 for further details about the IETF’s contribution to the network management protocol soup. 2 / 90
Today’s Menu . . . NETCONF The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. [RFC 6241] YANG YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [RFC 6020] 3 / 90
Configuration Management [15 min] Configuration Management [15 min] 1 NETCONF Protocol [20 min] 2 YANG Data Modeling Language [20 min] 3 Core Configuration Data Models [15 min] 4 Implementations, Tools, and Usage [10 min] 5 Future Directions [10 min] 6 Discussion [20 min] 7 4 / 90
“The Network is the Record” Policy Management Service Management Systems Systems Network Topology Network Status and Information Performance Information Configuration Configuration Configuration Configuration Configuration Device Device Device Device Device Configuration Backup Repository ⊲ Network operators typing / scripting proprietary CLIs ⊲ Often coupled with a backup repository to track changes ⊲ Labor intensive, expensive, error prone, widely deployed 5 / 90
“Generate Everything” (RFC 3139) Policy Management Service Management Systems Systems Network−Wide Network Topology Network Status and Configuration Information Performance Information Database Configuration Data Translator Configuration Configuration Configuration Configuration Configuration Device Device Device Device Device ⊲ Changes go to a network-wide configuration database ⊲ Device configurations are automatically pushed to devices ⊲ Devices are (ideally) never touched manually 6 / 90
Configuration Management Requirements R1 A configuration management protocol must be able to distinguish between configuration state and operational state. (configuration state vs. operational state) ⊲ Configuration state: • Everything explicitely configured (e.g., IP addresses assigned manually to network interfaces) ⊲ Operational state: • Usage and error counters obtained by the device • State learned from interaction with other devices (e.g., an IP address obtained from a DHCP server) 7 / 90
Configuration Management Requirements R2 A configuration management protocol must provide primitives to prevent errors due to concurrent configuration changes. (concurrency support) ⊲ Goal: Prevent two operators from making configuration changes simultaneously that lead to undesired results ⊲ Requires either strict locking or a conflict resolution mechanism ⊲ Computer programs generally deal better with strict locking, conflict resolution requires intelligence ⊲ Scope of locks determines how much concurrency is possible 8 / 90
Configuration Management Requirements R3 A configuration management protocol must provide primitives to apply configuration changes to a set of network elements in a robust and transaction-oriented way. (configuration transactions) ⊲ Example: renumbering a whole network • All devices need to pick up new addresses • During the renumbering process (activation of a new configuration), connectivity might be temporarily lost • Devices need to be able to decide whether they keep the new configuration (addressing scheme) or rollback to the previous configuration 9 / 90
Configuration Management Requirements R4 A configuration management protocol must be able to distinguish between several configurations and devices should be able to hold multiple configurations. (multiple configurations) ⊲ Configurations can become large and complex ⊲ Often useful to keep a few configurations on the device to easily switch between them (backup configs) ⊲ Distinction between the running configuration and the configuration used at next re-initialization 10 / 90
Configuration Management Requirements R5 It is important to distinguish between the distribution of configurations and the activation of a certain configuration. (distribution vs. activation) ⊲ Example: peak hours vs. off-peak hours • An operator wants to turn off links during off-peak hours • This might happen once per day or even more frequently • Instead of shipping a complete new configuration each time, it is much more efficient to activate a different already locally stored configuration ⊲ Implementations may internally keep data derived from known locally stored configurations in order to make the activation as smooth as possible 11 / 90
Configuration Management Requirements R6 A configuration management protocol must be clear about the persistence of configuration changes. (persistence of configuration state) ⊲ Sometimes changes are temporary and should be forgotten after the next restart of a device ⊲ Sometimes changes should be applied immediately and be remembered after reboots ⊲ Sometimes changes should only be applied at the next restart of a device 12 / 90
Configuration Management Requirements R7 A configuration management protocol must be able to report configuration change events. (configuration change events) ⊲ Example: firewall rules break applications • Customers report that certain applications suddenly fail to function correctly • Reason: A new firewall rule causes certain messages these applications rely on to be blocked ⊲ A log of configuration change events often helps during fault isolation / resolution 13 / 90
Configuration Management Requirements R8 A full configuration dump and a full configuration restore are primitive operations frequently used by operators and must be supported appropriately. (configuration dump and restore) ⊲ This seems to be rather obvious to operators ⊲ Some network management protocols fail badly here 14 / 90
Configuration Management Requirements R9 A configuration management protocol must represent configuration state and operational state in a form enabling the use of existing tools for comparison, conversion, and versioning. (support for standard tools) ⊲ Many operators use home-grown software systems ⊲ Such systems often rely on standard tools for processing network management data ⊲ Data formats enabling the use of off the shelf tools • eases integration • saves time • cuts costs 15 / 90
Configuration Management in the IETF No Description SNMP NETCONF R1 config vs. oper state - + R2 concurrency support o + R3 config transactions - [+] R4 multiple configs - [+] R5 distribution vs. activation - [+] R6 persistence of config state o + R7 config change notifications - + R8 config dump and restore - + R9 support of standard tools - + ⊲ These requirements originate from an IAB workshop that paved the way for NETCONF and YANG [RFC3535] 16 / 90
NETCONF and YANG Timeline Date Milestone Jun 2002 IAB network management workshop May 2003 NETCONF working group established — work work work — Dec 2006 NETCONF 1.0 RFCs published Apr 2008 NETMOD working group established — work work work — Oct 2010 YANG 1.0 RFCs published Jun 2011 NETCONF 1.1 RFCs published — tutorial IETF 84 — Q4 2012 Core configuration data models published 17 / 90
NETCONF Protocol [20 min] Configuration Management [15 min] 1 NETCONF Protocol [20 min] 2 YANG Data Modeling Language [20 min] 3 Core Configuration Data Models [15 min] 4 Implementations, Tools, and Usage [10 min] 5 Future Directions [10 min] 6 Discussion [20 min] 7 18 / 90
NETCONF RFCs (as of today) RFC Status Content RFC 6241 PS NETCONF Protocol Version 1.1 RFC 6242 PS NETCONF over SSH Version 1.1 RFC 6243 PS NETCONF With-defaults Capability RFC 6470 PS NETCONF Base Notifications RFC 6536 PS NETCONF Access Control Model RFC 5717 PS NETCONF Partial Locking RFC 5277 PS NETCONF Event Notifications RFC 6022 PS NETCONF Monitoring RFC 6244 I NETCONF / YANG Architecture ⊲ Further RFCs define additional transports ⊲ Some of the transports may be declared historic soon 19 / 90
Deployment Model Server Remote NETCONF CLI NETCONF Applications Manager CLI Client Client CLI Client Server Server Agent Server Instrumentation Instrumentation Instrumentation NETCONF Device NETCONF Device NETCONF Device ⊲ NETCONF enabled devices include a NETCONF server ⊲ Management applications include a NETCONF client ⊲ Device CLIs can be a wrapped around a NETCONF client 20 / 90
Layering Model (RFC6241) Layer Example Content Configuration Data Notification Data Operations <get−config>, <edit−config> <rpc>, <rpc−reply> <notification> Messages Secure Transport SSH, TLS, (BEEP/TLS), (SOAP/HTTP/TLS), ... ⊲ Security is provided by the transport layer ⊲ Operations focus on primitives to manage configurations ⊲ The set of operations is designed to be extensible 21 / 90
Recommend
More recommend
