CCNA #012: Learn SNMP with GNS3, Wireshark and Solarwinds NPM - CCNA 200-125 exam

[Music] in this lab I've got three Cisco routers running within gns3 connected to a switch which in turn has NPM connected to it here's my NPM server and as an example I can paying 10:1 101 which is a router one on writer one is an example I can type debug IP ICMP and back on M p.m. when I ping that IP address I'm getting echo replies sent on the router so the router is receiving the I TMP messages from the NPM server so I'll log in under nodes Cisco I can see that I have three routers currently up so as an example right or one with IP address 10 one 101 is shown as up and I can see some information about that device now ingenious three I'm going to start capturing on the link from NPM to the switch I'll capture traffic on the switch interface what I'd like to point out is to notice ICMP messages from NPM the server has an IP address of 10 1 100 100 that's what we're seeing as the source in the wireshark capture so echo ping request and in here's a response from the router so as an example I could filter for ICMP messages and what we could see here as an example is ICMP message from NPM to router 2 and rather to replying we can also do a search for SNMP so in this example we've got an SNMP message from NPM to router 3 opening that up we can see it's a data request message it's trying to get this o ID information here's a response back from the router more response information sent back notice Oh ID information so in the background NPM is requesting information from the routers in this example is querying routed to and routed to is responding here it's querying router 3 and so forth and so on that information is then displayed in a nicer graphical format on the NPM server as an example if I click on router 1 I can see information about this device I can see that it's up see its IP address see other information including the subject ID lost boot I could even click on the telnet link and launch a telnet application to telnet directly to the device that would require a telnet client enabled on my PC scrolling down I can see as an example that the polling method used for this devices SNMP and the polling interval is 120 seconds I can see as an example the interfaces and the state of those interfaces we can see other information about the device including that it was rebooted let's have a look at router to see his route at 2 we can see information about the node once again that it's up we can see that it's being polled with SNMP we can see the interfaces once again so let's have a look at serial 0/0 in this case we can see the utilization isn't very high on this interface because no traffic is being sent and we can see that the interface is up see is routed to interface serial 0/0 that's the interface that we're looking at in NPM or shut listen to face down interface has gone down I'll click pull and now and as you can see the interface is being shut down that interface has gone down in Wireshark we can see that a message was sent from NPM to the router and the router then responded with information about the oids on the device so let's do that again what I'll do is restart the capture we're going to search for SNMP and I'm going to specify an IP address 10.1.1.10 so we can see requests from the management station and then responses back from the router what I'll do now is no shut the interface so bring it up so I'm bringing up serial 0/0 back in the management interface I'll click pull now and notice there are null values for different o IDs and now responses are coming back from the router polar game interfaces up so it was done previously so the NPM device is able to retrieve status information of network interfaces by using SNMP we can see for instance the speed of the interface utilization and other options on the interface of the router all running within gns3 now something to point out in the ICMP message NPM is inserting data so the NPM server 10 1 100 100 is sending an echo request but is including data in the message NPM does this by default and one of the reasons for doing this is that some devices between your NMS and the device that you're pinging may block ICMP packets with certain criteria in the data fields some firewalls as an example may block packets with a zero size data field and some firewalls will block packets with large payloads some devices even block ICMP packets that are even or odd in size in this capture we can see that the response packet was sent from router 2 to the NMS so it's an ICMP echo reply message and the NMS will calculate the difference between the time that the request was sent and the reply received and it uses that to calculate the round response time or latency of the network now here's an SNMP message once again from the network management station in other words NPM - router - 10 1 100 - you can see this as an SNMP message and SNMP uses UDP or user Datagram protocol which is a connectionless protocol unlike TCP UDP doesn't provide reliability in the same way that TCP does you'll also notice that the port is port 161 so the network management station is communicating with the router on destination port 161 and the rudder is replying back from port 161 to the ephemeral or random port number that was chosen by the NMS for this connection it's important to remember that UDP port 161 is the destination port that the NMS initiates sessions - in other words the NMS or NPM in this case is going to be initiating sessions - routers on port 161 you need to ensure that your firewalls or access lists or ACL permit or allow UDP port 161 from the NMS to the devices that are being monitored and the reverse traffic also needs to be permitted you may even want to configure devices to use a non default port for SNMP so rather than using the default port of once you fifty-one you may choose to use a another port number like 10,000 161 you would configure that on the device and you would also need to configure that on NPM so knows which port number to use to connect to that device for monitoring in both the SNMP get or SNMP request as well as the response you'll see the OID values and live information that NPM is getting from the device so in the request we can see that the values are null and in the reply is can see the actual values for those oh I D okay that's include +4 blog entry please let me know if there any other topics that you'd like to discuss as part of the efficient a blog if you enjoyed this video please like it it means a lot to me if you liked the video and especially if you subscribe to my channel I wish you all the very best [Music] you