NETWORK CONFIGURATION

Prepared by:Menna HamzaMohamad HeshamMona Abdel MageedYasmine Shaker

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

AGENDA

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.

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

AGENDA

XML DETOUR XML Why XML? XSD and Schemas Xpath XML Node XML Sub Tree Example

XML EXAMPLE <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>

Value of Xpath (top/users/user/name)

DEFINITIONS Application / client Server / Device Data Store / Configuration file Capabilities

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

AGENDA

PROTOCOL LAYERS

•Configuration Data•Status Data?

Content

•<get-config>•<edit-config>•…..

Operation

•<rpc-call>•<rpc-reply>

RPC

•SSL, SSH, BEEP, console Transport Protocol

<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 the needed advertised capabilities

requests to the Server. The Server processes the requests on a FIFO

basis (Pipe Line) 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

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

AGENDA

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

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

AGENDA

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

<PARTIAL-LOCK> (CTD.) RPC Call Parameters

Filter (Lock) ID (Unlock)

Deadlock Avoidance RPC Reply

Positive (Lock ID in case of lock) Negative

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

AGENDA

WITH DEFAULT CAPABILITY A new XML child element added to the

method-name element. 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.

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.

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

AGENDA

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

Agent(NETCON

F)

Server(TLS)

Manger(NETCON

F)

Client(TLS )

NETCONF OVER TLS Endpoint Authentication and Identification

Server Identity o The server hostnameo Matching is case-insensitive.o A "*" wildcard character.o multiple names is acceptable.

Client Identity

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

AGENDA

QUESTIONS!