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 / Manager Server / Device / Agent 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•C
onfiguration 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 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
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
RPC
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
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.
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)
Manager(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!
Top Related