Midterm Study Guide solutions

> 1. Suppose we want to create a new snmp table, 
> called carTable. The prefix is vehicles::= 1.5.4.3.2.
> The carTable is to consist of sets of entries of form
> 	horsePower
> 	make (gm, chrysler, ford, nissan, toyota)
> 	modelNumber
> 	seating
> The index is to be a field carNum.
> 	
> Give an ASN.1 definition for carTable, carEntry, and 
> the entry fields. 

	vehicles OBJECT IDENTIFIER  ::= { 1 5 4 3 2 }
	
        carTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF CarEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "A list of cars"
              ::= { vehicle 1 }

        carEntry OBJECT-TYPE
              SYNTAX  CarEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry containing car features"
              INDEX   { carNum }
              ::= { carTable 1 }

        CarEntry ::=
              SEQUENCE {
                  carNum
                      INTEGER,
                  horsepower
                      INTEGER,
                  carmake INTEGER,
                  modelNumber
                      INTEGER,
                  seating
                      INTEGER
              }

These five fields should also be defined. Here is one:

       carmake OBJECT-TYPE
              SYNTAX  INTEGER {
                          other(1),          -- none of the following
                          gm(2),
                          ford(3),
                          nissan(4),
                          toyota(5),
                          chrysler(666)  
      -- can you tell I have a love/hate relationship with Chrysler?
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "manufacturer of the car"
              ::= { carEntry 3 }

> 2. Discuss some methods by which an NMS can identify new nodes.
> What happens if a node is a non-IP device, such as a switch?

The two most common discovery methods are 
  (a) use of PING
  (b) manual configuration
Examination of SNMP and other tables (especially from DHCP servers)
is also employed reasonably often.

Non-IP devices like hubs cannot be detected by IP-based strategies.
However, most such *managed* devices require that they be configured
with an IP interface.

> 3. How can the NMS decide what to *do* with a certain SNMP-speaking
> device it has discovered? That is, how can an NMS know to ask 
> router-type questions of a router and switch-type questions
> of a switch?

Manual configuration is one possibility; the other is dispatch
based on an initial prefix of the sysOID string.

> 4. Chapter 4 exercise 9: host v router using SNMP

non-routers should have ipForwDatagrams == 0. Also, routers
will have at least two entries in the ipAddrTable, while non-routers
will *almost* always have only a single entry there.

> 5. Chapter 4 exercise 10: use the ipNetToMediaEntry table.

(a): columns are:
	ipNetToMediaIfIndex
	ipNetToMediaPhysAddress
	ipNetToMediaType
	ipNetToMediaNetAddress

> 6. Chapter 4 exercise 11: write a MIB file.

Here is a way that does not require tables for b1 and b2
(except for jackets). Most real implementations would 
probably construct a table of branches, to allow easy
inclusion of additional branches.

abc OBJECT IDENTIFIER ::= { enterprises 5000 }

branch1 OBJECT IDENTIFIER ::= { abc 1 }
branch2 OBJECT IDENTIFIER ::= { abc 2 }

b1hats  OBJECT-TYPE
      SYNTAX  INTEGER
      ACCESS  accessible
      STATUS  mandatory
      DESCRIPTION
	      "hat quantity at branch 1"
      ::= { branch1 1 }
              
-- similarly for b2hats

b1jacketTable OBJECT-TYPE
	SYNTAX SEQUENCE OF B1jacketEntry
      	ACCESS  not-accessible
      	STATUS  mandatory
      	DESCRIPTION "jacket info table"
      ::= { branch1 2 }
	

b1jacketEntry OBJECT-TYPE
              SYNTAX  B1jacketEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry branch1 jacket info"
              INDEX   { jacketSize }
              ::= { b1jacketTable 1 }

B1jacketEntry ::=
              SEQUENCE {
                  jacketSize INTEGER,
                  jacketQuantity INTEGER
              }

-- similarly for b2jacketTable.

> 7. Chapter 4 # 13: use the standard mib-2 objects to identify
> which workstation on a LAN is really a router to the outside 
> world.

Default routes will point to this router.

> 8. Chapter 4 # 14: differences between TCP and UDP in mib2

Note that no UDP connections are listed; they do not really exist.
(Open UDP sockets *could* be listed, but are not.)

> 9. Chapter 3 exercises: 
> #2: overview of NMS for dual-vendor network
> #6: give an ASN.1 version of a DayofWeek type as a SEQUENCE
> #7: give an ASN.1 version of a DayOfWeek type as an ENUMERATED


> 10. Find the etherlike.mib MIB file for ethernet-like nodes and
> (a) identify how to find the number of collisions

There are three count fields that give this.
            dot3StatsSingleCollisionFrames      Counter,
            dot3StatsMultipleCollisionFrames    Counter,
            dot3StatsExcessiveCollisions        Counter,
Strictly speaking, these only count packets, not total number
of collisions.


> (b) identify how to determine if any host is violating the
>     1500-byte maximum packet size

This happens all the time, usually because token ring traffic
has been bridged into the Ethernet, and token ring used to have
a maximum packet size of 4K. I once had to deal with an 
EXTREMELY FRUSTRATING problem of having oversize packets 
arrive at regular intervals, together with a bunch of Sun 
workstations that had a network driver bug that would 
completely crash the machine whenever these oversize packets arrived.

            dot3StatsFrameTooLongs              Counter


> (c) identify how to determine the rate of collisions per good packet.

You have to use the interface stats to get the number of good packets.
Unfortunately, this MIB does not really provide a good collision
count, just the number of packets that were involved in collisions.