1 / 28

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 Example Partial Lock RPC

cale
Télécharger la présentation

Network Configuration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Network Configuration Prepared by: MennaHamza MohamadHesham Mona Abdel Mageed Yasmine Shaker

  2. 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

  3. operations and management area • Area Workgroups Examples: • Adslmib : ADSL MIB • Capwap : Control And Provisioning of Wireless Access Points. • Bmwg : Benchmarking Methodology • Dime : Diameter Maintenance and Extensions • Netconf : Network Configuration

  4. 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.

  5. 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.

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

  7. 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)

  8. Definitions • Application / client • Server / Device • Data Store / Configuration file • Capabilities

  9. Protocol Layers

  10. <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?

  11. 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? • Client closes the session or Server terminates session due to timeout

  12. 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

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

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

  15. Filters • What’s a filter • Using a filter • <filter> • Demo

  16. <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>

  17. <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>

  18. Extended Capabilities Case Studties • Partial lock • With default Capabilities

  19. 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

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

  21. <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

  22. <partial-lock> (ctd.) • RPC Call • Parameters • Filter (Lock) • ID (Unlock) • Deadlock Avoidance • RPC Reply • Positive (Lock ID in case of lock) • Negative

  23. With default capability • It’s just 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.

  24. 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.

  25. 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?

  26. NETCONF over TLS • Connection Initiation ClientHello message Handshake Start Exchange XML • Connection Closure Manger (NETCONF) Client (TLS ) Agent (NETCONF) Server (TLS)

  27. 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

  28. Questions

More Related