Network Configuration

Network Configuration Prepared by: Menna Hamza Mohamad Hesham Mona Abdel Mageed Yasmine Shaker

Agenda • OPS • NetConfig Work Group • NetConfig Protocol • XML Detour • Definitions • Protocol Layers • Protocol Main Scenario • Basic Operations • Filters • Demo • Partial Lock RPC • With Default Capability • TLS

operations and management area • Area Workgroups Examples: • CAPWAP : Control And Provisioning of Wireless Access Points. • BMWG: Benchmarking Methodology • DIME : Diameter Maintenance and Extensions • NETCONF : Network Configuration

netconf working group • The NETCONF Working Group is chartered to produce a protocol suitable for network configuration. • required characteristics includes: • Differentiate between configuration data and non-configuration data. • Extensible. • Integration with user authentication methods. • Integration with configuration database systems. • Wide configuration transactions with features such as locking and rollback capability.

NetConfig Protocol • The protocol provides mechanism to transfer and manipulate configuration data in a network device • It uses an Extensible Markup Language (XML)-based data encoding for the configuration data and the protocol messages. • The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer.

Agenda • OPS • NetConfig Work Group • NetConfig Protocol • XML Detour • Definitions • Protocol Layers • Protocol Main Scenario • Basic Operations • Filters • Example • Partial Lock RPC • With Default Capability • TLS

XML Detour • XML • Why XML? • XSD and Schemas • Xpath • XML Node • XML Sub Tree • Example

XML Example Value of Xpath (top/users/user/name) <top xmlns="http://example.com/schema/1.2/config"> <users> <user> <name>root</name> <type>superuser</type> <full-name>Charlie Root</full-name> <company-info> <dept>1</dept> <id>1</id> </company-info> </user> </users> </top>

Definitions • Application / client / Manager • Server / Device / Agent • Data Store / Configuration file • Capabilities

Protocol Layers

<Hello> • A way for both client and server to announce there existence • It also serves as an announcement of session ID as well as supported features !!! • Extendible protocol means that there is no guarantee that the server and client support the same set features. • Base capability must be supported • How to handle different set of features?

Serve Me • The client uses the needed advertised capabilities to send requests to the Server. • The Server processes the requests on a FIFO basis (Pipeline) • The Server sends Required Data/ request status to the client • How to associate a request with a reply? ID • Client closes the session or Server terminates session due to timeout

RPC For Life • Client Requests are RPC calls • The data store is conceptually a list of XML namespaces • The RPC manipulates these XML namespaces • Changes to the XML name spaces are mapped by the device to actual changes in it’s internal configuration (registers, etc..) • Server reply contains requested XML data, errors, warnings and optionally execution success feedback

Basic Operations • Get • get • get-config • Manipulate • edit-config • copy-config • delete-config • Parallel access control • Lock • unlock • End session • close-session • kill-session

RPC blocks • <rpc-call> • <rpc-reply> • <rpc-error> • </ok> • <data>

Filters • What’s a filter • Using a filter • <filter>

Demo

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-config> <source> <running/> </source> <filter type="subtree"> <top xmlns="http://example.com/schema/1.2/config"> <users> <user> <name>root</name> </user> </users> </top> </filter> </get-config> </rpc>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <top xmlns="http://example.com/schema/1.2/config"> <users> <user> <name>root</name> <type>superuser</type> <full-name>Charlie Root</full-name> <company-info> <dept>1</dept> <id>1</id> </company-info> </user> </users> </top> </data> </rpc-reply>

Extended Capabilities Case Study • Partial lock • With default Capabilities

Agenda • OPS • NetConfig Work Group • NetConfig Protocol • XML Detour • Definitions • Protocol Layers • Protocol Main Scenario • Basic Operations • Filters • Example • Partial Lock RPC • With Default Capability • TLS

Partial Lock RPC • Describes the lock and unlock operations on parts of configuration data stores using XPath filtering mechanisms • Definition of Terms • Scope of the lock • Protected area

Partial Locking Capability • Usage Scenarios • Multiple managers with overlapping sections • Multiple managers, distinct management areas • New Operations • <partial-lock> • <partial-unlock>

<partial-lock> • Locking a node protects the node itself and the complete sub-tree under the node • The XPath expressions are evaluated only once at lock time • NETCONF server that supports partial locking MUST be able to grant multiple simultaneous partial locks to a single NETCONF session • Failure • Global lock • Already locked • User does not have access rights

RPC • Parameters • Filter (Lock) • ID (Unlock) • Deadlock Avoidance • RPC Reply • Positive (Lock ID in case of lock) • Negative

With default capability • part of the configuration data is not set by the NETCONF client, but rather a default value is used. • Some times NETCONF client has a prior knowledge about this default data, so the NETCONF server does not need to send it to the client. • In other situations the NETCONF client will need this data so it must be sent at the NETCONF <rpc-reply> messages. • A new XML child element added to the method-name element.

Reporting modes • report-all: • All default data is always reported. • trim: • Values are not reported if they match the default. • explicit: • Default data is not reported except explicitly set default data.

NETCONF over TLS • Configuration exchange must be secure. • TLS provide support for certificate-based mutual authentication. • TLS is application-protocol-independent. • How NETCONF can be used within a TLS session?

NETCONF over TLS • Connection Initiation Client Hello message Handshake Start Exchange XML • Connection Closure Manager (NETCONF) Client (TLS ) Agent (NETCONF) Server (TLS)

NETCONF over TLS • Endpoint Authentication and Identification • Server Identity • The server hostname • Matching is case-insensitive. • A "*" wildcard character. • multiple names is acceptable. • Client Identity

Questions!

Network Configuration