860 likes | 899 Views
Network Monitoring and Management. ICMP and SNMP. ICMP. Internet Control Message Protocol RFC 792 Transfer of (control) messages from routers and hosts to hosts Feedback about problems e.g. time to live expired Encapsulated in plain IP datagram Not reliable. Application. Application.
E N D
Network Monitoring and Management ICMP and SNMP
ICMP • Internet Control Message Protocol • RFC 792 • Transfer of (control) messages from routers and hosts to hosts • Feedback about problems • e.g. time to live expired • Encapsulated in plain IP datagram • Not reliable
Application Application Application Application ARP RARP Application Transport TCP UDP ICMP IGMP Network IP Link Ethernet Driver incoming frame
FTP server telnet server 7 21 23 SMTP 25 TCP src port TCP dest port data header UDP 17 TCP TCP ICMP 6 1 hdr cksum dest addr source addr data protocol type IP header ARP x0806 IP IP x0800 dest addr source addr data Ethernet frame type CRC (Ethernet frame types in hex, others in decimal)
ICMP • Uses IP but is a separate protocol in the network layer • ICMP messages contain • Type • Code • 1st 8 bytes of “bad” datagram IP HEADER PROTOCOL = 1 TYPE CODE CHECKSUM REMAINDER OF ICMP MESSAGE (FORMAT IS TYPE SPECIFIC) IP HEADER IP DATA
Destination Unreachable TYPE CODE CHECKSUM UNUSED IP HEADER + 64 bits data from original DG TYPE = 3 CODE 0 = Net unreachable 1 = Host unreachable 2= Protocol unreachable 3 = Port unreachable 4 = Fragmentation needed but DF set 5 = Source route failed 6 = Dest network unknown 7 = Dest host unknown
Source Quench TYPE CODE CHECKSUM UNUSED IP HEADER + 64 bits data from original DG • TYPE = 4; CODE = 0 • Flow control: • Indicates that a router has dropped the original DG or may indicate that a router is approaching its capacity limit. • Correct behavior for source host is not defined.
Time Exceeded TYPE CODE CHECKSUM UNUSED IP HEADER + 64 bits data from original DG TYPE = 11 CODE 0 = Time to live exceeded in transit 1 = Fragment reassembly time exceeded
Redirect TYPE CODE CHECKSUM NEW ROUTER ADDRESS IP HEADER + 64 bits data from original DG TYPE = 5 CODE = 0 = Network redirect 1 = Host redirect 2 = Network redirect for specific TOS 3 = Host redirect for specific TOS
Redirection Concept Internet
QUERY Message: Echo and Echo Reply TYPE CODE CHECKSUM IDENTIFIER SEQUENCE # DATA …. TYPE = 8 = ECHO; 0 = ECHO REPLY CODE = 0 IDENTIFIER An identifier to aid in matching echoes and replies SEQUENCE # Same use as for IDENTIFIER UNIX “ping” uses echo/echo reply
Using Ping [wirth:~] [4:15pm] -> ping www.uakron.edu PING arwen.uakron.edu (130.101.81.50) 56(84) bytes of data. 64 bytes from arwen.uakron.edu (130.101.81.50): icmp_seq=0 ttl=62 time=0.512 ms 64 bytes from arwen.uakron.edu (130.101.81.50): icmp_seq=1 ttl=62 time=0.449 ms 64 bytes from arwen.uakron.edu (130.101.81.50): icmp_seq=2 ttl=62 time=1.38 ms 64 bytes from arwen.uakron.edu (130.101.81.50): icmp_seq=3 ttl=62 time=0.439 ms 64 bytes from arwen.uakron.edu (130.101.81.50): icmp_seq=4 ttl=62 time=0.448 ms 64 bytes from arwen.uakron.edu (130.101.81.50): icmp_seq=5 ttl=62 time=0.496 ms 64 bytes from arwen.uakron.edu (130.101.81.50): icmp_seq=6 ttl=62 time=0.449 ms --- arwen.uakron.edu ping statistics --- 7 packets transmitted, 7 received, 0% packet loss, time 6001ms rtt min/avg/max/mdev = 0.439/0.596/1.383/0.323 ms, pipe 2 [wirth:~] [4:16pm] ->
Extended Ping Used for path MTU discovery • IP header options can be used along with ICMP: • route recording, • timestamping, • source routing
Traceroute • UNIX utility - displays router used to get to a specified Internet Host (Van Jacobson, 1988) • Operation • router sends ICMP Time Exceeded message to source if TTL is decremented to 0 • if TTL starts at 5, source host will receive Time Exceeded message from router that is 5 hops away • Traceroute sends a series of UDP probes(to port ~33500) with different TTL values… and records the source address of the ICMP Time Exceeded message for each • Probes are formatted so that the destination host will send an ICMP Port Unreachable message
TTL=1 TTL=2 Router 1 known TTL=3 Router 2 known Destination known Traceroute and ICMP (2) • Trace the route of an IP packet Source Destination Router 1 Router 2 Timeline:
Traceroute and ICMP (3) • Trace the route of an IP packet • Upon reaching destination, • No “Time exceeded” message generated • How do you know when final destination is reached? • Traceroute sends to unused UDP port (>30000), generating an ICMP “destination unreachable” message • With code “port unreachable”
Taceroute mymachine:~% traceroute www.cis.ksu.edu traceroute to polaris.cis.ksu.edu (129.130.10.93), 30 hops max, 40 byte packets 1 wraith.facnet.mcs.kent.edu (131.123.46.1) 0.878 ms 0.620 ms 0.553 ms 2 ghost.uis-mcs.mcs.kent.edu (131.123.40.1) 6.000 ms 3.366 ms 2.632 ms 3 lib2-255x248-e37-lib.gate.kent.edu (131.123.255.254) 7.170 ms 3.552 ms 4.477 ms 4 twcneo-cw.neo.rr.com (204.210.223.3) 9.515 ms 15.167 ms 18.687 ms 5 bordercore4-hssi1-0.NorthRoyalton.cw.net (166.48.233.253) 17.864 ms 10.971 ms 14.652 ms 6 core4.WillowSprings.cw.net (204.70.4.73) 23.438 ms 22.099 ms 17.397 ms 7 wsp-sprint2-nap.WillowSprings.cw.net (206.157.77.94) 18.367 ms 22.854 ms 20.267 ms 8 sl-bb11-chi-2-1.sprintlink.net (144.232.10.157) 23.518 ms 24.528 ms 18.757 ms 9 sl-bb12-chi-5-1.sprintlink.net (144.232.10.6) 21.197 ms 31.452 ms 15.050 ms 10 sl-bb10-kc-7-1.sprintlink.net (144.232.9.117) 46.752 ms * 40.125 ms 11 sl-gw5-kc-0-0-0.sprintlink.net (144.232.2.62) 38.360 ms 48.002 ms 44.795 ms 12 sl-uok-1-0-0.sprintlink.net (144.232.132.14) 93.256 ms 67.070 ms 61.727 ms 13 ks-1-ks-ksu.r.greatplains.net (164.113.232.193) 77.743 ms 64.566 ms 67.117 ms 14 164.113.212.250 (164.113.212.250) 59.988 ms 46.188 ms 55.616 ms 15 129.130.252.9 (129.130.252.9) 68.211 ms 67.881 ms 75.441 ms 16 polaris.cis.ksu.edu (129.130.10.93) 76.462 ms 54.838 ms *
PMTU-D TCP: path-MTU discovery
SNMP • Where did it come from ? • Internet Engineering Task Force • Network Management Area • SNMP v1 • MIBv1, MIBv2 • SNMP v2 (?) • SNMP v3 (?)
SNMPv1 History • RFC 1157, 1990: • “A Simple Network Management Protocol (SNMP)” • RFC 1155, 1158,1213, 1990: • Specification of the MIBv2 • Written in ASN.1
SNMPv1 Protocol Five Simple Messages: • get-request • get-next-request • get-response • set-request • trap
SNMP - SNMP Message Handling - GetRequest (What is the value of MIB?) SNMP Agent SNMP Manager GetResponse (The value is XXXX!) GetNextRequest (What is the next value of MIB Tree ?) GetResponse (The value is XXXX!) SetRequest (Modify the value of OID) GetResponse (The value is XXXX!) Trap (Problem happened!)
SNMPv1:UDP ports get_request get_response port 161 get_next_request port 161 get_response Manager Agent set_request port 161 get_response trap port 162 port 161
SNMPv1 Packet Format UDP Header PDU Type Request ID Error Status Error Index Version Community name value name ... • SNMP version (0 is for version 1) • Community (read-only, read-write): • Shared “password” between agent and manager • PDU: Specifies request type • Request ID • Error Status • Error Index
Community Names • Community names are used to define where an SNMP message is destined for. • Set up your agents to belong to certain communities. • Set up your management applications to monitor and receive traps from certain community names.
RFC 1065 (MIB Structure) • “Structure and Identification of Management Information for TCP/IP-based Internets (SMI)” • Uses Abstract Syntax Notation 1 (ASN.1) • Types of information • Network Address • IP Address • Counter (32 bit monotonically increasing) • Gauge (32 bit variable) • Timeticks (time in hundredths of a second) • Opaque (arbitrary syntax for text data) • Adopted as a full standard in RFC 1155 (basically unchanged)
MIB definitions • RFC 1066 - MIB definitions using RFC 1065 (RFC 1155) (Rose & McCloghrie) • First version of the MIB now called MIB-I • Adopted as a full standard in RFC 1156 (essentially unchanged from 1066) • RFC 1158 - extends MIB-I and defines MIB-II • Adopted as a full standard in RFC 1213
Vendor extensions to MIB • RFC 1156 (MIB-I) allowed for vendor specific extensions to be included in the MIB • Allows for additional management information about devices not provided for in the standard MIB • For example: CPU utilisation • Normal for devices to support all of MIB-II PLUS have their own vendor-specific extensions
SNMP - MIB Tree - • Objects are managed by the tree • Expressed in a row of values divided by the period root iso(1) ccitt(0) Joint-iso-ccitt(2) org(3) dod(6) Internet(1) directory(1) mgmt(2) exprimental(3) private(4) mib-2(1) enterprise(1) Standard MIBs Vendor-specific MIBs
SNMP Naming question: how to name every possible standard object (protocol, data, more..) in every possible network standard?? answer: ISO Object Identifier (OID) tree: • hierarchical naming of all objects • each branchpoint has name, number 1.3.6.1.2.1.7.1 udpInDatagrams UDP MIB2 management ISO ISO-ident. Org. US DoD Internet
SNMP - OID - • OID Expression • iso(1). org(3). dod(6). internet(1). mgmt(2). mib2(1) -> .1.3.6.1.2.1 e.g. sysDscr = .1.3.6.1.2.1.1.1 = mib-2.1.1 = system.1
SNMP - MIB & OID - • SNMP Manager can acquire the management information defined by MIB(Management Information Base) from Agent • Current version : MIBv2 RFC 1213 • MIB is the aggregate of object (information) on the equipment which SNMP Agent holds • Identifier is defined for each object = OID • MIB performed by Agent is roughly divided into: • MIBv2 : standard, public, specified by IETF • Enterprise MIB : private, specified by vendor company
MODULE SNMP MIB MIB module specified via SMI (Structure of Management Information) MODULE-IDENTITY (100 standardized MIBs, more vendor-specific) OBJECT TYPE: OBJECT TYPE: OBJECT TYPE: objects specified via SMI OBJECT-TYPE construct
OBJECT-TYPE:ipInDelivers MODULE-IDENTITY:ipMIB SMI: Object, module examples ipMIB MODULE-IDENTITY LAST-UPDATED “941101000Z” ORGANZATION “IETF SNPv2 Working Group” CONTACT-INFO “ Keith McCloghrie ……” DESCRIPTION “The MIB module for managing IP and ICMP implementations, but excluding their management of IP routes.” REVISION “019331000Z” ……… ::= {mib-2 48} ipInDelivers OBJECT TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION “The total number of input datagrams successfully delivered to IP user- protocols (including ICMP)” ::= { ip 9}
MIB example: UDP module Object ID Name Type Comments 1.3.6.1.2.1.7.1 UDPInDatagrams Counter32 total # datagrams delivered at this node 1.3.6.1.2.1.7.2 UDPNoPorts Counter32 # underliverable datagrams no app at portl 1.3.6.1.2.1.7.3 UDInErrors Counter32 # undeliverable datagrams all other reasons 1.3.6.1.2.1.7.4 UDPOutDatagrams Counter32 # datagrams sent 1.3.6.1.2.1.7.5 udpTable SEQUENCE one entry for each port in use by app, gives port # and IP address
ASN.1: Abstract Syntax Notation 1 • ISO standard X.680 • defined data types, object constructors • like SMI • BER: Basic Encoding Rules • specify how ASN.1-defined data objects are to be transmitted • each transmitted object has Type, Length, Value (TLV) encoding