Efficient Network Management (236635)
– Final Project
Project Title: SNMP Agent for large data transfer Team: Kfir Karmon (ID 037197696)
Tsachi Sharfman (ID 029710399)
1. 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:
1. Should enable the efficient transfer of any SNMP table supported by the agent.
2. 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.
1.1. 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
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.
2. 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 1. 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.
enterprises
netSnmp 8072
netSnmpExamples 2
BackchannelControl 1000
BCRegisteredClientsTable 1
BCRegisteredClientsEntry 1
bcRegisteredClientIP 1
bcRegisteredClientPort 2
BCRegisteredOIDsTable 2
BCRegisteredOIDsEntry 1
bcRegisteredOIDClientIP 1
bcRegisteredOIDSeqNum 2
bcRegisteredOID 3
BackchannelControl
PHANTOM - bcMirroredClientIP 1
PHANTOM - bcMirroredIndex 2
PHANTOM -BCMirroredOIDsBranch 3
BCM Index Field Name Field number
BCM Field Name Field number
Non BCM Fields Field number
Figure 1. 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
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:
1. Client machine's IP: 192.168.0.179 2. Client listening Port: 18000
3. Server machine's IP: 192.168.0.2
4. Wanted OID via BC: .iso.org.dod.internet.mgmt.mib-2.ip.ipRouteTable.ipRouteEntry
5. Index of the Registered OID : 1 6. Num' of repetitions in bulk: 150
These are the steps that need to be taken in order for the table to be transferred using the BC mechanism:
1. Client registers itself at the server (his listening port number):
snmpset -c private 192.168.0.2
.iso.org.dod.internet.private.enterprises.netSnmp.netSnmpExamples.BackchannelControl.BCRegistered ClientsTable.BCRegister edClientsEntry.bcRegisteredClientPort.192.168.0.179 d 18000
2. Client registers the wanted Table's OID:
snmpset -c private 192.168.0.2
.iso.org.dod.internet.private.enterprises.netSnmp.netSnmpExamples.BackchannelControl.BCRegistered OIDsTable.BCRegisteredOIDsEntry.bcRegisteredOID.192.168.0.179.1 o
.iso.org.dod.internet.mgmt.mib-2.ip.ipRouteTable.ipRouteEntry
3. Client start the BL (set to port 18000) 4. Client Request the Mirrored OID
snmpbulkget -c public -C r150 192.168.0.2
.iso.org.dod.internet.private.enterprises.netSnmp.netSnmpExamples.BackchannelControl.3.192.168.0.17 9.1
5. BL receives the requested Table and "spoofs" it to the client's "snmpbulkget" process.
Client Machine
NET SNMP AGENT + BCM ExtModule
Figure 2. Describes the process of retrieving data using the TCP Backchannel.
2.1. Components and Employed Methods
The solution consists of the following components:1. 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.
2. Backchannel Listener (BL) – A client side process. The LCM waits for SNMP responses over TCP Backchannels. Upon reception of a SNMP
Client User
SnmpBulkGet(ReferenceOID,…) BL
Load NET SNMP Agent with our ‘BackChannel ControlMIB’ extension The client
registers itself and which TableOID it wants to receive via TCP (to RegisteredOID)
1) SnmpSet(RegisteredClientIP, Port) 2) SnmpSet(RegisteredOID, TableOID)
The client requests the ReferenceOID via SNMP
The Agent queries itself with the TableOID that reflects the ReferenceOID request Pass encapsulated
SNMP packets via a TCP connection Decapsulate the
SNMP packets and send them to the client using IP Spoofing
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 50 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 [1] installed on the gateway.
Linux based
router
+
Configurable
Packet loss
driver
W
W
i
i
n
n
d
d
o
o
w
w
s
s
W
W
i
i
n
n
d
d
o
o
w
w
s
s
3.1. 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 0% and 50%. We used bulk sizes of 60, 126, and 400 entries (a bulk of 60 entries produced a single packet response, a bulk of 126 entries produced a response composed of 2 IP fragments, and a bulk of 400 entries produced a response composed of 8 fragments).
Following are the results: Results for a bulk of 60 entries:
SNMP Client
+
BackChannel
Listener
SNMP Agent
+
BCM
ExtModule
Success Rate (60 Entries)
0 0.2 0.4 0.6 0.8 1 1.2
0 10 20 30 40 50 Packet Loss Rate
Success Rat
e
Udp Tcp BC
Time (60 Entries)
0 5 10 15 20 25
0 10 20 30 40 50 Packet Loss Rate
Time (sec)
Udp Tcp BC
Results for a bulk of 126 entries:
Success Rate (126 entries)
0 0.2 0.4 0.6 0.8 1 1.2
0 10 20 30 40 50 Packet Loss Rate
Success Rat
e
Udp Tcp BC
Time (126 entries)
0 5 10 15 20
0 10 20 30 40 50 Packet Loss Rate
Time (sec)
Udp Tcp BC
Results for a bulk of 400 entries:
Success Rate (400)
0 0.2 0.4 0.6 0.8 1 1.2
0 10 20 30 40 50
Packet Loss Rate
Success Rat
e
Udp Tcp
Time (400)
0 5 10 15 20 25
0 10 20 30 40
Packet Loss Rate
Time (sec)
Udp Tcp
3.2. 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 10%. The bulk size used varied from 60 to 2880 entries.
Following are the results:
Success Rate
0 0.2 0.4 0.6 0.8 1
0 1000 2000 3000 4000 Number of Entries Retrieved
Success Rat
e
Udp Tcp BC
Time
0 1 2 3 4 5
0 1000 2000 3000 4000 Number of Entries Retrieved
Time (sec)
Udp Tcp BC
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 10%-20%.
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
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 (10%-20% 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
1. Nistnet network emulator - http://snad.ncsl.nist.gov/itg/nistnet/
7. Issues to go over with Kfir
1. *Adding an example for explaining Reference OIDs
2. *Structure of Mirror Branch – it is not structured as a table!!!
3. *Synchronize terminology in Fig 2. and in the “Components and Employed Method” section
4. *Adding a drawing of the experiment setup
