Efficient Network Management (236635) Final Project

Transcription

1 Efficient Network Management (36635) Final Project Project Title: SNMP Agent for large data transfer Team: Kfir Karmon (ID ) Tsachi Sharfman (ID 97399). Problem Description One of the weaknesses of SNMP is its lack of an efficient mechanism for transferring large amounts of data, specifically large tables (for example a large routing table on a router). SNMP runs over UDP. While UDP (enhanced with an application layer retransmit mechanism) is sufficient for retrieving and setting single attributes, it is inefficient when used for transferring large tables. Efficiently transferring large tables requires employing a sliding window mechanism such as the one implemented by TCP. The goal of this project is to define and implement an efficient mechanism for transferring large SNMP tables. This shall be done by additional software components both on the agent side and on the client side. The requirements of the mechanism are:. Should enable the efficient transfer of any SNMP table supported by the agent.. The mechanism should be generic, i.e. any standard SNMP client (with the additional client side components) should be able to leverage the efficient transfer mechanism... Possible Solutions We considered several methods for efficiently transferring SNMP tables. The first method we considered was sending a SNMP SET command to a special OID, notifying the agent to locally save a specified table, and retrieving the table using FTP. The advantages of this method are that it relays on existing and widespread technology (SNMP commands and FTP), and that the bulk of data is transferred over a reliable protocol (the SNMP SET command is still sent over UDP, but application level retransmits should sufficiently handle the SNMP SET transaction). The disadvantage of this method is that it is not transparent to existing management tools using SNMP (such as OpenView or Tivoli). An alternative solution is establishing a TCP based tunnel between the SNMP client and SNMP agent, and routing SNMP commands and responses between the client and agent through the TCP tunnel. The advantage of this method is that it is completely transparent to existing management tools using SNMP. The disadvantage of this method is that while TCP based tunnels do exist (ssh tunnels, VTun), they are limited in functionality (ssh tunnels do not support UDP), and are not supported on all platforms. The third solution we considered was tunneling only the SNMP responses through a TCP backchannel (SNMP responses are sent over TCP to the client. On the client, a dedicated process receives the responses, and sends them locally over UDP with the agents IP address as the source IP address of the UDP packet). Since the amount of

2 data sent from the SNMP agent to the SNMP client is considerably higher than the amount of data sent from the client to the agent, this solution considerably improves the efficiency of data transfer without the complexities of establishing a bi-directional TCP based tunnel. In addition the solution is transparent to existing management tools using SNMP. The disadvantage of this method is that opening the TCP backchannel may be difficult through firewalls and NAT gateways.. Implemented Solution We decided to implement a TCP backchannel for sending SNMP responses, since it provides a solution that is transparent to existing management tools, and does not require platform specific support. The TCP Backchannel is only used for transferring specific subtrees called Target Subtrees, which are specified by clients in a new MIB called the Backchannel Control MIB (BCM). The TCP backchannel will be handled on the client side by a process called the Backchannel Listener (BL). The BL acts as a tunnel endpoint, i.e. upon reception of a response from an SNMP agent it locally sends the response over UDP using the agent s IP address as the source address of the packet. The structure of the BCM is described in Fig. It contains two tables, the first table, called the Client Registration Table, is used for registering the IP address and BL port number of clients supporting the TCP Backchannel. The second table, called the Target Table, is used for specifying the OIDs of the Traget Subtrees for each registered client. Each Target Subtree registered for each client in the Target Table is assigned a unique integer (per client) called the Mirror Index. The Mirror Index is used by the client in order to retrieve the values from Target Subtrees using the TCP Backchannel.

3 Field number BCM Index Field Name Field number BCM Field Name Field number Non BCM Fields netsnmpexamples 87 netsnmp enterprises BackchannelControl BCRegisteredClientsTable BCRegisteredOIDsTable BCRegisteredClientsEntry BCRegisteredOIDsEntry bcregisteredclientip bcregisteredclientport bcregisteredoidclientip bcregisteredoidseqnum 3 bcregisteredoid BackchannelControl PHANTOM -BCMirroredOIDsBranch 3 PHANTOM - bcmirroredclientip PHANTOM - bcmirroredindex Figure. The BCM's structure. In addition to the registration tables described above, the BCM includes an additional branch, called the Mirror Branch, used for activating the TCP Backchannel. Target Subtrees are replicated under the Mirror Branch, i.e. each OID in a Target Subtree is associated with an OID (called the Reference OID) under the Mirror Branch. When an SNMP GET, GETNEXT or GETBULK command specifies a Reference OID, the SNMP agent returns the response through the TCP Backchannel. An OID to an entry in a Target Subtree is composed of two partes, OID of the root of the subtree (called the prefix), and the remaining part of the OID (called the suffix). A Reference OID (associated with an entry in Target Subtree) is created by replacing

4 the prefix of the OID to the original entry with a prefix under the Mirror Branch. The new prefix shall be composed of the OID of the Mirror Branch, concatenated with the client IP address, followed by the Mirror Index assigned to the Traget Subtree. Consider the following Example:. Client machine's IP: Client listening Port: 8 3. Server machine's IP: Wanted OID via BC:.iso.org.dod.internet.mgmt.mib-.ip.ipRouteTable.ipRouteEntry 5. Index of the Registered OID : 6. Num' of repetitions in bulk: 5 These are the steps that need to be taken in order for the table to be transferred using the BC mechanism:. Client registers itself at the server (his listening port number): snmpset -c private iso.org.dod.internet.private.enterprises.netSnmp.netSnmpExamples.BackchannelControl.BCRegistered ClientsTable.BCRegister edclientsentry.bcregisteredclientport d 8. Client registers the wanted Table's OID: snmpset -c private iso.org.dod.internet.private.enterprises.netSnmp.netSnmpExamples.BackchannelControl.BCRegistered OIDsTable.BCRegisteredOIDsEntry.bcRegisteredOID o.iso.org.dod.internet.mgmt.mib-.ip.iproutetable.iprouteentry 3. Client start the BL (set to port 8) 4. Client Request the Mirrored OID snmpbulkget -c public -C r iso.org.dod.internet.private.enterprises.netSnmp.netSnmpExamples.BackchannelControl BL receives the requested Table and "spoofs" it to the client's "snmpbulkget" process.

5 BL Client Machine Client User NET SNMP AGENT + BCM ExtModule The client registers itself and which TableOID it wants to receive via TCP (to RegisteredOID) ) SnmpSet(RegisteredClientIP, Port) ) SnmpSet(RegisteredOID, TableOID) Load NET SNMP Agent with our BackChannel ControlMIB extension The client requests the ReferenceOID via SNMP SnmpBulkGet(ReferenceOID, ) Pass encapsulated SNMP packets via a TCP connection The Agent queries itself with the TableOID that reflects the ReferenceOID request Decapsulate the SNMP packets and send them to the client using IP Spoofing Figure. Describes the process of retrieving data using the TCP Backchannel... Components and Employed Methods The solution consists of the following components:. Agent extension module An extension module for the CMU SNMP agent. The extension module handles the Backchannel Control MIB. It keeps a record of all the clients that register with the agent, and the Target Subtrees each client would like to retrieve. When a registered client tries to retrieve data specifying a Reference OID the extension module is invoked with the SNMP command sent by the client. The command from the client is copied, and Reference OIDs in the command are converted to the original OID in the Traget Subtee. The new command is sent locally to the snmp agent. When a response to the local command is received a response to the clients original command is built using the values received in the response to the internal command. A new thread is spawned, which sends the response to the original command over a TCP connection.. Backchannel Listener (BL) A client side process. The LCM waits for SNMP responses over TCP Backchannels. Upon reception of a SNMP

6 response through a TCP Backchannel, the BL repackages the response as a UDP packet, and sends it locally with the IP address of the agent as the packets source IP address (using a raw socket). 3. Experimental Results In order to test the performance of our solution we compared retrieving entries from a table (we used the routing table in our experiments) with SNMP GETBULK requests over an unreliable network, using both regular UDP responses and the TCP Backchannel. The parameters for each experiment were the packet loss rate of the network, and the number of entries retrieved using the GETBULK command. Each experiment was repeated 5 times. The parameters measured were the success rate for each method (the number of successful GETBULK commands), and the average time it took for a successful GETBULK command to complete. No application level retransmits were performed during the experiment. The SNMP client and agent were run on two machines running Windows XP. The client and agent were assigned IP addresses on different subnets, with a Linux box serving as the gateway between the subnets. Packet loss was generated by the nistnet network emulator [] installed on the gateway. Windows SNMP Client + BackChannel Listener Linux based router + Configurable Packet loss driver Windows SNMP Agent + BCM ExtModule 3.. Packet Loss Influence The first parameter we were interested in testing was the effect of the packet loss rate on the performance of the two methods of retrieving SNMP data. We performed a series of experiments with a packet loss rate varying between % and 5%. We used bulk sizes of 6, 6, and 4 entries (a bulk of 6 entries produced a single packet response, a bulk of 6 entries produced a response composed of IP fragments, and a bulk of 4 entries produced a response composed of 8 fragments). Following are the results: Results for a bulk of 6 entries:

7 Success Rate (6 Entries) Success Rate Time (6 Entries) Time (sec) Results for a bulk of 6 entries: Success Rate (6 entries). Success Rate

8 Time (6 entries) Time (sec) Results for a bulk of 4 entries: Success Rate (4). Success Rate Tcp Time (4) Time (sec) Tcp

9 3.. Bulk Size Influence The second parameter we were interested in testing was the effect of bulk size on the performance of the two methods in reasonable network conditions. We chose to perform the experiments at a packet loss rate of %. The bulk size used varied from 6 to 88 entries. Following are the results: Success Rate Success Rate Number of Entries Retrieved Time Time (sec) Number of Entries Retrieved 3.3. Results Analysis The experimental results indicate that the success rate of both methods drops as the packet loss rate increases. Although the success rate of the TCP Backchannel is consistently higher then the success rate of UDP responses, the TCP Backchannel does not perform well above a packet loss rate of %-%. An advantage of using UDP responses is that the average success time remains constant regardless of bulk size or packet loss rate, while the average success time of the TCP Backchannel increases as packet loss rate and bulk size increase. Testing the methods in relatively moderate packet loss conditions indicates that the TCP Backchannel is significantly more effective for retrieving large amounts of data. Success rate and success time remains constant regardless of the bulk size, while

10 when using UDP response success rate decrease and success time increases when the bulk size increases. 4. Possible Enhancements The TCP Backchannel scheme may be enhanced in several ways. Technical issues that may be improved include enhancing the Client Registration and Target Registration to include a RowStatus column, and performing stricter security checks on requests for values from the Mirror Branch. Adding a RowStatus column will enable several clients to work more effectively with an SNMP agent, and enable clients to delete rows from the registration tables. Stricter security checks on requests for values from the Mirror Branch will prevent a hostile client from flooding a registered client with SNMP responses, thus creating a Denial of Service attack. Other issues that may be improved are eliminating the need to replicate Target Subtrees under the Mirror Branch, and problems the TCP Backchannel scheme currently has with firewalls and NAT gateways. Although the TCP Backchannel scheme is transparent to existing SNMP management tools, it does require using a Reference OID for activating the TCP Backchannel. This limitation may be eliminated by running a local proxy on the machine running the agent. Since at present the SNMP agent automatically establishes the TCP Backchannel with a client when a response for the client is ready, is will not function properly if a firewall or a NAT gateway exist between the client and the agent. This may be overcome if the TCP Backchannel is manually established by the client before SNMP requests are sent. 5. Conclusion Using a TCP Backchannel proved to be very effective in relatively moderate packet loss rates (%-% packet loss rate). It enables retrieving large amounts of data in a quick and reliable manner, and is transparent to existing SNMP based management tools. It proved to be ineffective in extreme packet loss conditions. Most of the limitations existing in the current implementation, such as security and NAT issues, may be overcome. An inherent limitation of the solution is the vulnerability for SNMP requests sent by the client, which are still transmitted over an unreliable connection. The only way of handling this limitation is by application level retransmissions. 6. References. Nistnet network emulator Issues to go over with Kfir. *Adding an example for explaining Reference OIDs. *Structure of Mirror Branch it is not structured as a table!!! 3. *Synchronize terminology in Fig. and in the Components and Employed Method section 4. *Adding a drawing of the experiment setup 5. *How many fragments a response with a bulk of 4 entries produces?