![Protocol Stack
The NETCONF protocol can be broken down into 4 layers. They are,
● Content – NETCONF data models and protocol operations use the YANG modeling
language (RFC 6020). A data model outlines the structure, semantics and syntax of the
data.[5]
● Operations – A set of base protocol operations initiated via by RPC methods using
XML-encoding, in order to perform operations upon the device. Such as <get-config>,
<edit-config> and <get>.
● Messages – A set of RPC messages and notifications are defined for use including
<rpc>, <rpc-reply> and <rpc-error>.[6]
● Transport – The transport layer used to provide a communication path between the
client/server (manager/agent). The protocol used is agnostic to NETCONF, but SSH is
typically used.](https://image.slidesharecdn.com/iotsystemmanagement-241129083810-a8666c64/85/IoT-System-Management-ppt-SNMP-simple-network-25-320.jpg)
IoT System Management ppt SNMP simple network
- 1. IoT System Management Prepared by Narikamalli Yaswanth Assistant Professor Kristu Jayanti college Bangalore Course Code: 24IoT2T412
- 2. What is SNMP? SNMP: Simple Network Management Protocol SNMP (Simple Network Management Protocol) is a widely used protocol for managing network devices. It allows network administrators to monitor and control network devices, such as routers, switches, servers, and printers, from a central location.
- 3. Key Features of SNMP: ● Remote Management: SNMP enables administrators to manage network devices remotely, reducing the need for physical access. ● Monitoring: SNMP can monitor various aspects of network devices, including: ○ CPU usage ○ Memory utilization ○ Interface traffic ○ Temperature ○ Power consumption ● Configuration: SNMP can be used to configure network devices, such as setting up routing tables, assigning IP addresses, and enabling or disabling features. ● Notifications: SNMP can send notifications to administrators when certain events occur, such as
- 4. SNMP Versions: ● SNMPv1: The original version of SNMP, which is still widely used. ● SNMPv2: Introduced enhancements such as community strings for authentication and security. ● SNMPv3: The most secure version of SNMP, offering authentication, privacy, and authorization features.
- 5. SNMP Components: ● Managed Devices: Network devices that are configured to support SNMP. ● Network Management Station (NMS): A central computer that runs SNMP management software and communicates with managed devices. ● Management Information Base (MIB): A database that defines the structure and content of information that can be exchanged between managed devices and NMS.
- 6. Use Cases for SNMP: ● Network Monitoring: Tracking network performance, identifying bottlenecks, and troubleshooting issues. ● Inventory Management: Keeping track of network devices and their configurations. ● Security Management: Monitoring for security threats and responding to incidents. ● Performance Optimization: Fine-tuning network settings to improve performance.
- 11. Limitations of SNMP Security: ○ Community Strings: SNMPv1 and SNMPv2 use community strings for authentication, which can be relatively easy to guess or intercept. ○ Lack of Encryption: SNMPv1 and SNMPv2 do not provide encryption for data transmission, making it vulnerable. ○ Authorization: While SNMPv3 introduces authentication, privacy, and authorization features, it can be complex to implement and may not be supported by all managed devices.
- 12. Scalability: ● Performance Overhead: SNMP can generate a significant amount of traffic, especially when monitoring large networks or generating detailed reports. ● MIB Complexity: As the number of managed devices and their features increase, managing and understanding MIBs can become complex. Vendor-Specific Implementations: ○ Incompatibility: Different vendors may implement SNMP differently, leading to compatibility issues and challenges in managing heterogeneous networks. ○ Customization: While vendor-specific extensions can provide additional features, they can also make it more difficult to manage devices from different vendors.
- 13. Limited Real-Time Capabilities: ○ Polling: SNMP relies on polling, where the NMS actively queries managed devices for information. This can introduce latency and may not be suitable for real-time monitoring applications. ○ Trap Limitations: While SNMP traps can be used to notify the NMS of events, they may not always provide enough information or be received in a timely manner. Complexity: ○ Configuration: Configuring SNMP on managed devices and setting up the NMS can be complex, especially for large networks or when using advanced features. ○ MIB Understanding: Understanding MIB structures and object definitions is essential for effective SNMP management, but it can be challenging for those without a networking background.
- 14. NETCONF/YANG Prepared by Narikamalli Yaswanth Assistant Professor Kristu Jayanti college Bangalore Course Code: 24IoT2T412
- 15. NETCONF/YANG NETCONF/YANG provides a standardized way to programmatically update and modify the configuration of a network device. To break this down further. YANG is the modelling language that describes the configuration changes. Whereas NETCONF is the protocol that applies the changes to the relevant datastore (i.e running, saved etc) upon the device.
- 16. Introduction Let us start with the problem. Historically, the main method of configuring a networking device had been via the CLI or in some cases SNMP. However these methods presented a number of issues. Such as: CLI disadvantages, ● The CLI INPUT (commands) differs from vendor to vendor. ● The CLI OUTPUT from each vendor differs. Requiring separate parsing logic for each vendor. ● The CLI structure and syntax are prone to changes. Making our CLI scripts fragile.
- 17. SNMP disadvantages, ● Unreliable as it inherently uses UDP as its transport protocol. ● Traditionally insecure. Though SNMPv3 looks to address this, it still comes with its own security challenges. Mainly being the discovery messages used to negotiate the authentication and encryption keys are neither authenticated nor encrypted. ● No clear delimiter between configuration data and monitoring data. Resulting in additional logic having to be performed on the client side in order to sort. ● Lacks standard MIBs for configuring networks. That is why, vendors have developed various proprietary MIBs which become a barrier to managing cross vendor platforms. ● Provides no real transactional operation model, to allow for simple rollbacks etc.
- 18. With the adoption of network automation increasing (such as SDN, think NBI) there was a need to standardize and improve the way that networking devices were programmed. A way that provided, ● A programmatic interface for device configuration. ● Separation of configuration and state data. ● The ability to configure services not just devices. ● Integrated error checking and recovery. The solution to this issue came in the form of NETCONF and YANG. In its simplest form YANG provides a language to describe your desired configuration. NETCONF, on the other hand provides the protocol to deliver and perform the required operations in order to achieve the desired state, described within the YANG model.
- 20. YANG YANG (Yet Another Next Generation) is a data modelling language, providing a standardized way to model the operational and configuration data of a network device. YANG, being a language is being protocol independent, can then be converted into any encoding format, e.g. XML or JSON
- 21. Open/Native Models Open Models – Designed to be independent of the underlying platform and normalize the per-vendor configuration of network devices. Open YANG Models are developed by Vendors and Standards bodies, such as IETF, ITU, OpenConfig etc. Native Models – Native Models are developed by the vendors. They relate and are designed to integrate to features or configuration only relevant to that platform.
- 22. Components Container – A collection of information logically grouped. Such a container for configuration, and one for state. List – Within a container you can have a list or even multiple lists. Such as a list of interfaces. Key – Each item within the list is references via a key. Leaf – Inside our list we have leaf’s. Containing our information. Data Type – Each leaf is associated against a data type.
- 24. NETCONF NETCONF (NETwork CONFiguration) is a protocol defined by the IETF to “install, manipulate, and delete the configuration of network devices”. NETCONF operations are performed via a RPC layer using XML based encoding. Some of the key features to NETCONF are, ability to rollback configurations, ability to support any data model and the separation of config from operational state.
- 25. Protocol Stack The NETCONF protocol can be broken down into 4 layers. They are, ● Content – NETCONF data models and protocol operations use the YANG modeling language (RFC 6020). A data model outlines the structure, semantics and syntax of the data.[5] ● Operations – A set of base protocol operations initiated via by RPC methods using XML-encoding, in order to perform operations upon the device. Such as <get-config>, <edit-config> and <get>. ● Messages – A set of RPC messages and notifications are defined for use including <rpc>, <rpc-reply> and <rpc-error>.[6] ● Transport – The transport layer used to provide a communication path between the client/server (manager/agent). The protocol used is agnostic to NETCONF, but SSH is typically used.
- 28. Communication NETCONF is based upon a client/server model, as known (as per NETCONF’s terminology) – Manager and Agent. Within the communication flow of a NETCONF session there are 3 main parts. These are: 1. Session Establishment – Each side sends a <hello>, along with its <capabilities>. Announcing what operations (capabilities) it supports. 2. Operation Request – The client then sends its request (operation) to the server via the<rpc> message. The response is then sent back to the client within <rpc-reply>. 3. Session Close – The session is then closed by the client via <close- session>.
- 29. Configuration Datastores There are 4 NETCONF configuration datastores – Running, Startup, Candidate and URL. Actions are then performed against these datastores via the various NETCONF operations (as previously seen): ● Running – The configuration datastore containing the configuration that is applied and running upon the network device. ● Startup – The configuration datastore holding the configuration loaded by the device when it boots. ● Candidate – A configuration datastore that can be manipulated without impacting the device’s current configuration and that can be committed to the running configuration datastore. ● URL – A configuration datastore thats configuration resides within a separate location, accessed via a URL.