Hello everyone and welcome back to the modern campus network management techniques video series. The first video involve network management challenges in evolution. Now you move on to explore classic NMS tools like SNMP, Syslog, and more. SNMP based management solution may have several 100 or thousands of managed nodes, switches, routers, gateways, servers, and more. Now, each managed node maintains a management information base, or MIB, which defines information that can be used to monitor and configure that node. This information can be accessed because of an SNMP agent which implements the SNMP protocol. The other major component is some network management system or NMS server, that includes SNMP Manager capabilities. The manager uses the SNMP protocol to request or modify information in a managed node, MIB to configure the system or monitor system health and statistics. SNMPv1 and 2c use community strings like a password to control access to the MIB, and you must configure the SNMP Manager with proper passwords for each device or group of devices or when the server must retrieve status information, it sends a GET request with the appropriate read-only or R0 community string. If this is correct, the agent grabs this information from the MIB and sends it to the manager. There's also a GETNEXT request to more efficiently retrieve larger information sets from the MIB. To set a value, the manager sends a SET request with an appropriate read-write or RW string. If the string is correct, the new value takes effect. As you can see, SNMP uses a pull mechanism, the agent only provides information if the manager request it, often periodically based on how you configure the Manager. However, some important messages cannot wait for a periodic request, and so a push mechanism is used and unsolicited notification sent in the form of a TRAP message. These are not acknowledged by the NMS, so there's a danger that these vital messages go unnoticed. But there is a newer so-called inform message for this purpose that is acknowledged. A meanwhile, SNMPv3 takes care of some weaknesses in v2c. Username, password based authentication improves control over who can access the MIBs. Message encryption prevents bad actors from viewing sensitive configuration in status data. Even so, it still uses the same periodic poll-based approach to gathering network statistics. Now, this another limitation can affect scalability and usability. We have some similar concerns with logging. Network and other device types often log status messages locally in a Syslog format. You can control the severity of messages logged, emergency alert, critical, and so on. You can also configure devices to send Syslog information to a common set of Syslog servers. Thus, you have more centralized information repository to use for status checks, audits, and forensics. It's great having all this information, but imagine trying to use it, waiting through thousands of hours of logs for hundreds of devices. You will soon learn about security information and event management or SIM tools to help with this. For many years, we've been managing individual network devices like switches, routers, and controllers with SNMP, and by using a command-line interface or CLI to create flat configuration text files. You have dozens, hundreds, even thousands of individual configuration files to manage. The time it takes to initially configure these devices is bad enough. Then over time the network grows, needs change configurations are modified during troubleshooting or some emergency mandate for management. You need to periodically audit your configuration files. Do you meet current or near-future corporate objectives for connectivity and quality of service or QoS? You need to be aware of remaining switch ports in Power over Ethernet budgets as compared to expected business growth and new initiatives like deploying more APs, cameras, or IoT devices. Use switch configurations conform to current security best practices and corporate compliance requirements. Security breaches and nonconformance can be costly and damage to the corporate brand. Most classic NMS tools have a way to store configuration backups, making it easier for you to deal with equipment replacements, but may lack the intelligence to compare your configurations against a set of ever-changing gold standards. The other issue is those old flat text configuration files. Now, that CLI is great for a human to machine interaction, but not so great for machine-to-machine interaction. Those familiar mechanisms can still work nicely, but they're aging, becoming less appropriate for the scalability and ease of management requirements of modern campus designs. Wouldn't it be nice to have a Unified Infrastructure with a single operational model across the entire infrastructure. I like that the Aruba CX switches are built on a microservices-based operating system with an open REST API available for configuration and management functions. You get easy secure Cloud Connectivity with modern HTTP-based telemetry that uses a more optimized publisher-subscriber model as opposed to the cumbersome polling method of SNMP. This facilitates zero downtime upgrades and moving to a more centralized control and management plane in Cloud or on-premises. It also facilitates more automation for typical network admin tasks. In scalability, a single customer can manage up to 100,000 network devices and one million client devices. That concludes the second video in the modern campus network management techniques series, SNMP overview versions, and challenges along with Syslog capabilities and the challenges of managing these devices with these aging tools and flat texts configuration files. You saw how a microservices-based network OS that leverages open REST API technology can ease administration while increasing uptime. Please come on back for the third video in the series, modern NMS tools.
