Network Management

Summer 2016, Corboy 710, TTh 5:30-8:45 pm

Class 2: July 7


Demos using iReasoning tool and snmpwalk

We will use host ulam3 (10.38.2.42) for these demos. It's reachable via Loyola's Ethernet, but not via Loyola's Wi-Fi.

(/etc/default/snmpd by default binds snmpd only to localhost!)

    snmpwalk -v 2c -c public ulam3 .1.3.6.1.2.1

    vs

    snmpwalk -v 2c -c futhark ulam3 .1.3.6.1.2.1


    snmpwalk -v 2c -c public ulam3 1.3.6.1.4.1
    End of MIB

    snmpwalk -v 2c -c tengwar ulam3 1.3.6.1.4.1
    gads of data

    snmpwalk -v 1 -c tengwar ulam3 1.3.6.1.4.1.42
    gads of data

As of 1 July 2016, the ulam3 SNMP community strings are "public", "futhark" and "tengwar".
They are related as public ⊆ futhark ⊆ tengwar.

You can put .1.3.6.1.4.1.42 into the upper-right box of the iReason tool [at least for ulam3]
    
Other ways of polling devices:

    ssh: limitations: lack of "universal" account
              lack of "limited" account
              doesn't work for most hubs/switches/non-hosts
             
Also try host win7.


SNMP Basics

The manager sends queries to the agent. Agents are sometimes called managed devices.

To enable the Windows SNMP Agent feature:
First, Control Panel -> Programs and Features -> Turn Windows Features On or Off -> Simple Network Management Protocol (SNMP)
Next, in Control Panel -> Administrative Tools -> Computer Management -> Services and Applications -> Services,
click on SNMP Service (not SNMP Trap) and configure it. At a minimum, you will have to add a community name under the Security tab. (By default, Windows accepts SNMP connections only from localhost.)

SNMP uses UDP. Why?

CMIP has a TCP option, CMoT. Sometimes that's important.

SNMP does support the SET command, to write to devices. That's a little risky, unless you're using the security provided by SNMPv3.


History of SNMP

SGMP: Simple Gateway Monitoring Protocol:
started 1987; conflict with OSI approach

CMIP: Basic OSI strategy; too complex and large at the time it was defined for practical implementation.

1988: IAB decided to pursue both SGMP and CMOT: CMIP Over TCP/IP
This failed within a year: CMOT was dropped and SGMP had evolved into SNMPv1.

(Note that the IAB typically standardizes things a year or so after the thing has been rolled out. In fact, in order to become a standard, two independent implementations must exist.)

1990: SNMP v1 and SMI v1 had both been standardized. See RFC 1155.

1991: the SNMP mib-2 group was published in RFC 1213, consisting of system, interfaces, etc.

1993: RFC 1442, SNMP v2 SMI (first version, obsoleted by RFC 1902 in 1996); first SNMPv2 proposal. There is extensive controversy on how best to improve the security of SNMPv1.

1996: SNMPv2, Experimental (RFC 1901, Jan 1996); SNMPv2 standardization for the so-called "community-based version", now known as SNMPv2c, is complete. This version ignores all attempts at improving security, postponing that until a future consensus.

1999: SMI version 2. Note that version 2 and mib 2 have nothing in common.

2002: RFCs 3411-3418 are published, defining SNMPv3. It becomes a standard a couple years later. Security support is now thoroughly built in.
 
To enable community-based security for SNMPv1 (or SNMPv2c), you have to "manually" (that is, outside of SNMP) configure the agent with the community string, and then configure the manager to contain that <agent,community> pair. SNMPv3 likewise requires some initial "manual" configuration of the agent with a suitable key, and then provide the manager with suitable credentials so that it can prove to the agent that it has (or knows) the key. So, in that sense, SNMPv3 is similar to its predecessors. In the details, however, SNMPv3 configuration is decidedly more complex.
 
 

SNMP naming and OIDs

MIB-2 is 1.3.6.1.2.1.

See oid-info.com/get/

Top level
itu-t(0)
iso(1)
standard(0)
registration-authority(1)
member-body(2)
identified-organization(3)
nist(5)
dod(6)
internet(1) (apparently the only one)
directory(1)
mgmt(2)
mib-2(1)
experimental(3)
private(4)
security(5)
snmpV2(6)
mail(7)
features(8)
icd-ecma(12)
oiw(14)
edifactboard(15)
ewos(16)
osf(22)
nordunet(23)
nato(26)
icao(27)
...
amazon(187)
joint-iso-itu-t(2)


MIBs


First look at SNMP tables


All leaf nodes of the SNMP tree are atomic data values. However, tables (lists of records) can be constructed by using the OID sequences to index the data. The indexing is slightly nonstandard, though.

Recall the system group, {mib-2 1}. It is a "group" in the sense that system is a prefix to the OIDs of the group:
    sysDescr ::= {system 1}
    sysObjectID ::= {system 2}
    sysUpTime ::= {system 3}
etc. The group is thus simply a collection of values. In this case, the are all scalars (except for system.9!); as such, their full OID must have .0 appended. That is, to get sysDescr, you have to fetch {system 1 0}, or 1.3.6.1.2.1.1.1.0. Doing a GET of 1.3.6.1.2.1.1.1 returns "no such name error".

System.9, the sysORTable, was added in RFC 1450; OR = Object Resource

A table can be a member of a group in the same way as a scalar. A table is a collection of rows; each row consists of columns, or fields, and one (or more) of the fields serves as the table index, or key. We'll consider the interfaces table ifTable, part of the interfaces group. We have:
    interfaces ::= {mib-2 2}
    ifNumber ::= {interfaces 1}      ;; a scalar value, retrieved with 1.3.6.1.2.1.2.1.0
    ifTable ::= {interfaces 2}

By convention, SNMP then defines a table entry by adding another 1:
    ifEntry ::= {ifTable 1}

An ifEntry is a list of fields (the columns), numbered starting at 1. Here are a few of the fields:
    ifIndex ::= {ifEntry 1}
    ifDescr ::= {ifEntry 2}
    ifType ::=  {ifEntry 3}
    ifPhysAddr ::= {ifEntry 6}
    ifInOctets ::= {ifEntry 10}
    ifOutOctets::= {ifEntry 16}

Actual data is then indexed with OID {ifEntry col row}. (Note that the numbering order {... row col} would be more conventional.) That is, the address of the 4th interface is ifPhysAddr.4, or ifEntry.6.4. These OIDs serve as the keys for retrieving any particular row and column of the table. The key for a given row is, of course, the row number.

Here's a representation of all the OIDs involved in a table. Note that only leaf OIDs are actually stored; these are interior nodes.
1.3.6.1.2.1.2   interfaces
1.3.6.1.2.1.2.1   ifNumber
1.3.6.1.2.1.2.2   ifTable
1.3.6.1.2.1.2.2.1   ifEntry
1.3.6.1.2.1.2.2.1.1   ifIndex, our first column name
1.3.6.1.2.1.2.2.1.2   ifDesc, our second column name
1.3.6.1.2.1.2.2.1.3   ifType, our third column name

The actual leaf data is stored under OID columnName.ifNumber. That is, the ifDesc for interface 4 would be at ifDesc.4, or 1.3.6.1.2.1.2.2.1.2.4.

There are no trailing .0's (as is required for scalar values).

Note that this indexing strategy means that, as we traverse the tree, we get all of column 1, then all of column 2, then all of column 3, etc. The second-to-last field of the OID is in effect the column number and the last field is the row number, so values are named prefix.col.row. This is sometimes called column-major indexing.

On host ulam3 (10.38.2.42) there are several interfaces, and two significant ones (eth0 and eth1).

Columns in principle can be numbered nonconsecutively, though such examples are relatively rare. Rows, however, are fairly often "numbered" nonconsecutively. In fact, the actual rule is to take the column that represents the table index (or key in the database sense of the word "key"), and replace "row" with the OID of the index column's value. For the interface table, the index is required to be an integer between 1 and ifNumber, inclusive. But if the index were an IP address, we might retrieve a value for column 7 of the row indexed by ip address 147.126.65.47 with OID tableEntry.7.147.126.65.47. Similarly, if a table had two columns that served as index (key), we would access column 7 with tableEntry.7.row1val.row2val, where row1val and row2val were the index values for the row in question.

Note that we can also use the snmpwalk method (details later) to traverse the subtree and thus retrieve the entire table, without using key/index values as such.

Note that adding an extra slot in the OID for the tableEntry is slightly wasteful; it does, however, help to make the grammar a bit clearer. However, it would be feasible to define ifEntry to be ifTable,  and not {ifTable 1}, at the expense of making it slightly harder to connect retrieved OIDs with named MIB entries.


ASN.1


See also http://luca.ntop.org/Teaching/Appunti/asn1.html.

SNMP uses Abstract Syntax Notation 1 (ASN.1) to define syntax; encoding into UDP packets is then done using the Basic Encoding Rules (BER). Right now it sufficies to note the following:
  1. BER data is tagged with its type.
  2. ASN.1 and BER supports compound data types. However, SNMP does not use these; all data is atomic. (However, SNMP does support tables, which corresponds roughly to record formats and which can be pressed into service to represent, say, arrays.)
  3. SNMP uses the ASN.1 type constructors SEQUENCE (to define lists) and SEQUENCE OF (to define records). A table is a SEQUENCE of records; each record is a SEQUENCE OF a specific list of fields. (ASN.1 also has SET and SET OF constructors, but SNMP does not use these directly.)
  4. ASN.1 also supports CHOICE types, but these are used in SNMP only for very high-level definitions, eg
                      SimpleSyntax ::=
                          CHOICE {
                              number
                                  INTEGER,
                              string
                                  OCTET STRING,
                              object
                                  OBJECT IDENTIFIER,
                              empty
                                  NULL
                          }

  5. SNMP does not use all the available basic ASN.1/BER data types. In fact, only INTEGER, OCTET STRING, OBJECT IDENTIFIER, and NULL are allowed. However, some subtypes of INTEGER are created; these are called defined types. See intronetworks.cs.luc.edu/current/html/netmgmt.html#snmpv1-data-types.
  6. The BER encoding is such that the actual size in bytes of the data can be difficult to predict.
Some defined types from RFC 1155:

ASN.1 has more built-in data types. Every type is either Universal, Application-specific, Private, or Context-specific. Some of the universal types are BITSTRING, UTCTime, and PrintableString.


Some ASN.1:

Some definitions of high-level OID prefixes:

      internet    OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }


      directory     OBJECT IDENTIFIER ::= { internet 1 }
      mgmt          OBJECT IDENTIFIER ::= { internet 2 }
      experimental  OBJECT IDENTIFIER ::= { internet 3 }
      private       OBJECT IDENTIFIER ::= { internet 4 }

For defining records (eg ifEntry, or other table rows):
      SEQUENCE { <type1>, ..., <typeN> }
Tables are lists of records, defined with
      SEQUENCE OF <entry>
The OBJECT-TYPE macro is ubiquitous in MIB files. It provides a uniform way to specify the value's type (the SYNTAX) field, and also the ACESS and STATUS fields. The notation closes with "::= <OIDvalue>".


      OBJECT-TYPE MACRO ::=
      BEGIN
          TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
                            "ACCESS" Access
                            "STATUS" Status
          VALUE NOTATION ::= value (VALUE ObjectName)

          Access ::= "read-only"
                          | "read-write"
                          | "write-only"
                          | "not-accessible"
          Status ::= "mandatory"
                          | "optional"
                          | "obsolete"
      END


Here are five examples of OBJECT-TYPE in use to define the (now-deprecated) at table (for ARP data). The OID for the at group is 1.3.6.1.2.1.3. It defines atTable as at.1 (that is, 1.3.6.1.2.1.3.1), and atEntry as atTable.1, and the three columns as atEntry.1, atEntry.2, and atEntry.3.

1.                atIndex OBJECT-TYPE
                         SYNTAX  INTEGER
                          ACCESS  read-write
                          STATUS  mandatory
                          ::= { atEntry 1 }

2.                atPhysAddress OBJECT-TYPE
                          SYNTAX  OCTET STRING
                          ACCESS  read-write
                          STATUS  mandatory
                          ::= { atEntry 2 }

3.                atNetAddress OBJECT-TYPE
                          SYNTAX  NetworkAddress
                          ACCESS  read-write
                          STATUS  mandatory
                          ::= { atEntry 3 }

4.                atEntry OBJECT-TYPE
                          SYNTAX  AtEntry
                          ACCESS  read-write
                          STATUS  mandatory
                          ::= { atTable 1 }

5.                atTable OBJECT-TYPE
                          SYNTAX  SEQUENCE OF AtEntry
                          ACCESS  read-write
                          STATUS  mandatory
                          ::= { at 1 }

The first three entries define columns ("fields") of atEntry. The fourth defines atEntry as having OID atTable.1, and with syntax the CAPITALIZED AtEntry. The fifth defines atTable as having OID at.1, and with syntax SEQUENCE OF AtEntry.

Finally there is
                  AtEntry ::= SEQUENCE {
                      atIndex
                          INTEGER,
                      atPhysAddress
                          OCTET STRING,
                      atNetAddress
                          NetworkAddress
                  }
Every table has a row specification like this, with name capitalized by convention. Note that the OBJECT-TYPE is not used here. We could splice AtEntry into the fourth and fifth OBJECT-TYPE entries above, but it's simpler not to.


Interface Table

Go through details of ifTable, ifEntry, IfEntry, and all the columns (fields). This amounts to table syntax.
Then discuss the semantics, or meaning, of all the fields.
Special attention: ifInOctets and ifOutOctets.

Note that not all fields are updated immediately in real time, and some fields are notorious for being permanently wrong. ifSpeed, for example, is often set to 0 when the speed is variable (which is now considered to be the best alternative), and is sometimes set to some incorrect constant value in order to convince higher-level routing software to assign a specific "preference" to the link connected to that interface.



Review of 19.7: SNMP tables

19.8: GetNext()

19.10: MIB-2



Network Implementation Design Analysis – Burke, 2004, p 45

Geographical Distribution

  1. Office
    1. Subnets
    2. LAN
  2. Department (many offices)
    1. Subnets
    2. LAN
  3. Division (many departments)
    1. LAN
    2. WAN
  4. Organization (many divisions)
    1. Local LAN/WAN
    2. National WAN
    3. Global WAN
Subnets
  1. How many
    1. bridges/switches
    2. routers
  2. Ethernet
    1. cabling
    2. speed
    3. IP addresses needed
    4. DHCP
  3. Wireless
    1. number of wireless hubs
    2. authentication

LAN

  1. How many of them
  2. Domain names
  3. DNS configuration
  4. IP address space
  5. Subnets / how many, subnet masks
  6. switched Ethernet v routers
  7. Other LAN technologies

WAN

  1. How sites connect
  2. PSTN, X.25, SONET, ATM, Frame Relay, Carrier Ethernet, etc

Bandwidth requirements

  1. Video needs
  2. Audio needs
  3. Data needs

Service Level Agreements

  1. bandwidth constantly available
  2. peak bandwidth
  3. bandwidth available on demand
  4. burst capacity

Security

  1. firewall configuration
  2. proxy servers
  3. authentication issues
  4. network intrusion detection
  5. virus/malware monitoring


Apply it to:

 
Table 3.2 from Burke, Network Management, 2004: this describes some of the data we want:

Reliability:
Faults
Availability:    MTBF

Performance (response time)
Throughput
Data packet throughput
Voice ordered packet throughput
Video bandwidth, ...
Utilization
Resource use
Policies

Redundancy

User support

Note that this table does NOT have any per-service entries!
Some software services:


Fundamental SNMP-v1 messges:    
atomic data values only! Note use of GET-NEXT to retrieve these.

Issues:
    data presentation (eg byte order, but much more)
    NAMING for all those possible attributes!
    
ASN.1/BER data representation: defer

data can be subdivided into fields, though it is not for SNMP.