Network Management 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. What is the problem with conventional switches and a loop topology, > and how are OpenFlow/SDN switches able to accommodate this? s1------s2 | | s4------s3 Conventional switches fall back to flooding when the destination is unknown; this causes packets to circulate endlessly (in both directions!) OpenFlow/SDN switches do all their forwarding at the behest of a *controller*. The controller can: (a). Identify the network topology (b). Have switches report packets with unknown destinations (c). Calculate an appropriate path and instruct the switches to forward to that destination along that path. Alternatively, the controller can: (a). Identify a *spanning tree*, such as s1------s2 | s4------s3 (b). Tell switches to flood to unknown destinations using this spanning tree (c). Tell s1 and s4 to use their mutual link to reach destinations directly connected to the other endpoint, disregarding the fact that the s1--s4 link has, for flooding, been turned off. > 3. What is the simplest way, using SNMP, to > (a) retrieve a single row of a table (say row 3, where the columns are T.1 through T.7) > (b) retrieve a single column of a table (say column 5, with pseudo-header T.5, and 6 rows) (a). Do a multi-attribute Get. eg Get(T.1.3, T.2.3, ..., T.7.3) (b). Do a sequence of six GetNexts (or, better, a single GetBulk with repeaters=6) starting with GetNext(T.5) > 4. Explain how you could determine whether a device is a workstation > or a router using SNMP. non-routers should have 1.3.6.1.2.1.4.6.0 = ipForwDatagrams == 0. Routers will have an ipRouteTable entry that represents a universal default route. Also, routers will have at least two non-loopback entries in the ipAddrTable, while non-routers will usually have only a single entry there. However, a laptop with an Ethernet and a wireless interface will have two non-loopback IP addresses, and a computer hosting a virtual machine *may* have multiple IP addresses. Bottom line, it's hard to be *certain*. > 5. In the IP group, mib2.4, part of RFC1213-MIB, there are several tables: > ipAddrTable > ipRouteTable > ipNetToMediaTable > The following apply to the last table. > (a). List the columns under ipNetToMediaEntry. > (b). Draw a table representing these entries. Create at least two rows. > Make up plausible values. (a): columns are: ipNetToMediaIfIndex ipNetToMediaPhysAddress ipNetToMediaNetAddress ipNetToMediaType (b). Here's a table, where we assume everything is on interface 1, and the ipNetToMediaType field is 3 ("dynamic"): 1 00:11:43:75:C5:D4 10.0.0.3 3 1 00:17:18:34:15:A9 10.0.0.5 3 1 00:11:43:8B:39:E2 10.0.0.18 3 > 6. You own the ABC company that sells hats and jackets. > You have obtained an Object Identifier of 6525 under enterprises (1.3.6.1.4.1); > that is, your company's entries begin 1.3.6.1.4.1.6525. > You have two locations, branch1 and branch2. Each branch has the > following inventory and attributes: > hats: scalar hatQuantity > jackets: table jacketTable, > with entries jacketsSize (INDEX) and jacketQuantity. > (a). Create a MIB module for your company that indicates > how the respective inventories can be accessed with SNMP. > Define OIDs for branch1 and branch2, and create separate > MIB entries for each branch. That is, > define OIDs for branch1, branch2, branch_1_hats, b1jacketTable, etc. > Use the OBJECT IDENTIFIER and OBJECT-TYPE macros; follow the syntax > of any MIB file. Note that hats get a scalar under each branch, > but jackets need a sub-table. > (b). What would be an advantage for having a table of branches, > branch1 ... branchN, versus entries for specific branches? > (The tricky part here is that you can't have a table of tables; > that is, you can't have jacketTable be a column of branchTable.) (a): Here is the no-nested-tables version: 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 } -- b1jacketTable is the table for jacket size info b1jacketTable OBJECT-TYPE -- SYNTAX INTEGER /* WRONG; fixed 3/20/2011 */ SYNTAX SEQUENCE OF B1jacketEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "jacket quantity at branch 1" ::= { branch1 2 } b1jacketEntry OBJECT-TYPE SYNTAX B1jacketEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry for branch1's jacket info" INDEX { b1jacketSize } ::= { b1jacketTable 1 } B1jacketEntry ::= SEQUENCE { b1jacketSize INTEGER, b1jacketQuantity INTEGER } b1jacketSize OBJECT-TYPE SYNTAX INTEGER ACCESS accessible STATUS mandatory DESCRIPTION "a size s(1), m(2), l(3), xl(4)" ::= { b1jacketEntry 1 } b1jacketQuantity OBJECT-TYPE SYNTAX INTEGER ACCESS accessible STATUS mandatory DESCRIPTION "a quantity in stock of that size" ::= { b1jacketEntry 2 } -- now do the same thing for: -- b2hats -- similar to b1hats -- b2jacketTable -- similar to b1jacketTable (b). Most real implementations would probably want to construct a table of branches to allow easy inclusion of additional branches. The practical problem is that you can't define a "table of tables", and the jacket information is already tabular. However, we can simulate a table of tables by creating a table indexed by branchID *and* by jacketSize. That is, we would first create a branchID value to use to specify a branch. Then we would have a table hatsTable, with branchID as INDEX, and with a HatsEntry of { branchID, hatCount }. Finally, we would then create a SECOND table jacketsTable, with INDEX { branchID, jacketSize }. The third column would be jacketQuantity. This dual-INDEX table would allow us to specify a jacketQuantity given any branchID and any jacketSize. > 7.Suppose you're on a subnet. One workstation on the subnet is also > a router to the outside world. How could you determine which workstation > is the router using SNMP? Any workstation's Default routes will point to this workstation as router, so all you have to do is look at any workstation's routing table. Default routes can be found in the ipRouteTable of the ip group. Alternatively, you can examine the routing tables of the routing workstation. Identifying a bridge is trickier. Here are some clues: A. system sysServices is a bitstring representing OSI levels at which the node acts. Only a bridge would set the bit for Level 2. Alas, many nodes don't report sysServices. B. One can use the interfaces table to identify nodes which have two "real" interfaces (ie not virtual, loopback, tunnel, etc), and then use the ip.ipForwarding value to rule out routers. However, there *are* examples where a node has a second ethernet interface just to talk to a private network (eg with a hidden printer). C. Using the ifXTable attributes, you can see if the interface is in "promiscuous mode", which it must be for a bridge. D. You can see if the workstation has the attributes (in something like CISCO-BRIDGE-MIB) for the spanning-tree algorithm, which is used only by bridges. However, a workstation wouldn't be a Cisco bridge, and it may not in fact support *any* bridge-related SNMP queries. E. If the network is relatively idle, you can send a bunch of packets to the outside world and see which device has its ifInUcastPkts *and* ifOutUcastPkts tick up by the same amount. Actually, you don't need the network to be idle so much as the particular device must not be generating traffic on its own. Other suggestions? > 8. Account for the differences between TCP and UDP in the RFC1213-MIB > (mib2). That is, explain the differences and explain why they are there. There is no such thing as a UDP connection, so there is no table of connections. (Open UDP sockets are listed in the udpTable.) The other, scalar entries in the tcp group that do not have analogues in the udp group are also either connection-specific (such as tcpMaxConn, tcpActiveOpens, tcpPassiveOpens, tcpCurrEstab, ...), or refer to attributes of tcp that don't have UDP analogues (tcpRtoMin, etc) > 9. Consider a simplified version of the Interfaces table of RFC1213-MIB > with entries for ifIndex, ifDescr, and ifSpeed. > (a). Give the OIDs for the columns themselves. The OID for ifEntry is 1.3.6.1.2.1.2.2.1, and the three columns are 1, 2, and 5 (or 1, 2, and 3 if you interpreted the question as creating a new table and including only the three columns mentioned). So, the full OIDs for the three columns would be: 1.3.6.1.2.1.2.2.1.1 1.3.6.1.2.1.2.2.1.2 1.3.6.1.2.1.2.2.1.5 > (b). Suppose the table has the following data: > 1 eth0 10,000,000 > 2 eth1 100,000,000 > Give the OIDs for each of these six values. The OID is the name, not the value itself. Using ifEntry as 1.3.6.1.2.1.2.2.1, we have ifEntry.1.1 ifEntry.2.1 ifEntry.5.1 ifEntry.1.2 ifEntry.2.2 ifEntry.5.2 > 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 used to happen all the time, usually because token ring traffic had been bridged into the Ethernet, and token ring used to have a maximum packet size of 4KB. 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* wedge 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. > 11. In what order will values be retrieved from the following table? Retrieval by GET-NEXT traversal is depth-first: starting at the tree root, values are retrieved in the following order: T.E.1.1 T.E.1.2 T.E.1.4 T.E.2.1 T.E.2.2 T.E.2.4 T.E.3.1 T.E.3.2 T.E.3.4 The next GET-NEXT would either return something off to the right of the tree, with OID no longer an extension of the tree root T (or E), or else there would be an End_of_MIB error. Either way, we know we're done with the tree.