SNMP TCP Backchannel

1. SNMP TCP Backchannel An SNMP agent extension for transferring large files Submitted by: Tsachi Sharfman 029710399 Kfir Karmon 037197696 Efficient Network Management (236635)

2. Problem Description • SNMP runs over UDP • UDP is unreliable and therefore is inefficient for transferring large amounts of data Efficient Network Management (236635)

3. Solution’s Requirements • Should enable the efficient transfer of any SNMP table supported by the agent. • Should be transparent to existing SNMP clients. Efficient Network Management (236635)

4. Possible Solutions (1/3) • Download a mirrored table using FTP • Send an SNMP SET command to a special OID • The agent will locally save a specified table • The client will retrieve the table using FTP Pros and Cons: • Based on widespread known technology (SNMP & FTP) • Relies on an reliable protocol (FTP/TCP) • Not transparent to existing SNMP clients(Fails to withstand the requirements) Efficient Network Management (236635)

5. Possible Solutions (2/3) • Use SNMP through a TCP tunnel • Open a TCP tunnel between the client and server • SNMP packets are routed through the TCP tunnel Pros and Cons: • Full transparency for existing SNMP clients • Relies on an reliable transfer protocol (TCP) • Non standard, relies on proprietary technology • Overhead for short SNMP requests (UDP is cheaper) Efficient Network Management (236635)

6. Possible Solutions (3/3) • Use a TCP backchannel for SNMP responses • Client requests the table using SNMP • Client has a service, listening on a designated TCP port • Agent sends the SNMP responses encapsulated in the TCP backchannel to the client’s listening port • The service locally emulates the agent’s SNMP response Pros and Cons: • Full transparency for existing SNMP clients • Relies on an efficient transfer protocol (TCP) • Might be non-friendly to firewalls and NAT gateways Efficient Network Management (236635)

7. Implementing Solution #3 Architecture Overview - TCP backchannel (1/1) • In order to trigger the Backchannel (BC) mechanism the client should : • Register its IP and listening port • Register the wanted table (OID) • Issue an SNMP request to the Mirrored OID • At this point the SNMP agent will query itself with SNMP for the requested OID (the real one) • After the receiving the table a bakchannel to the client is opened and the table is transferred • The client side will send itself an SNMP response with the received table Efficient Network Management (236635)

8. Implementing Solution #3 Backchannel Control MIB (BCM) 1/3 • New MIB defined in the “NET-SNMP-EXAMPLES-MIB.txt” file • It introduced two table: • BCRegisteredClientsTable Every client that wants to use the BC mechanism needs to register itself here • BCRegisteredOIDsTable Each OID that needs to be transferred via the BC should be registered here • An additional “phantom” table was introduced, it includes OIDs that issuing SNMP requests to them triggers the BC mechanism Efficient Network Management (236635)

9. Implementing Solution #3 Backchannel Control MIB (BCM) 2/3 • BCRegisteredClients • BCRegisteredOIDs Legend: Efficient Network Management (236635)

10. Implementing Solution #3 Backchannel Control MIB (BCM) 3/3 • BCMirroredOIDsTable • These names are not defined in the MIB, though the structure is supported by the agent add-on (via the numeric annotation) Legend: Efficient Network Management (236635)

11. Implementing Solution #3 Backchannel Server (BCServer) 1/1 • The NET SNMP agent was extended using the, existing, add-on mechanism • The extension would handle any SNMP requests that are targeted to the “…BackchannelControl.*” OIDs • When an SNMP Get* request, to the MirroredOIDs, is received the agent will query itself for the appropriate OID • The agent will send, via the TCP BC, the SNMP packets constructing the received response (in the TCP packets payloads) Efficient Network Management (236635)

12. Implementing Solution #3 Backchannel Client (BCClient) 1/1 • A.K.A BackChannel Listener (BL) • The client registers itself and the wanted OIDs to the designated tables as described above. • The client issues a standard SNMP Request to the MirroredOID • The BCClient listens to the designated port for a connection to be made by the BCServer • After receiving the encapsulated SNMP response packets from the BCServer, the BCClient issues a standard SNMP response “spoofed” with the server’s IP. • Thus causing the initial, standard, SNMP request to receive the response without knowing that it was sent via a TCP BC. Efficient Network Management (236635)

13. Implementing Solution #3 The Whole Picture Efficient Network Management (236635)

14. How We Tested (1/2) • I order to test the efficiency of the new BC mechanism we built the following network topology Linux based router + ConfigurablePacket loss driver Windows SNMP Client + BCClient Windows SNMP Agent + BCServer Efficient Network Management (236635)

15. How We Tested (2/2) • We created scripts to automate our testing: • _AddRoutingRules.vbsThis script added routing rules to the agent’s routing table, a rule was added for each IP in the range: 10.0.[0-4].[0-255] • _Test.vbsThis was the main script, its usage:_Test.vbs [TCP | UDP] [Server's IP] [Client's IP] [NumOfRepititions] [NumOfTimes] [CSV_File] • This script performs snmpBulkGet requests to the server using a defined number of repetitions in the bulk response. • The requests were executed a defined number of times. • The output was exported to a CSV formatted file for later data processing in MS-Excel. • TCP requests were issued to the mirrored OID and UDP requests were issued to the regular ipRoutingTable OID (both via standard SNMP) Efficient Network Management (236635)

16. Results (1/4) Increase Packet Loss Rate & no IP Fragments • At first we compared the BC mechanism’s efficiency against the standard SNMP with the following parameters: • 60 repetitions in the bulk response (= a single IP packet) • Packet Loss rate ranging from 0%-50% stepping in 10% • Each scenario was tested 50 times Efficient Network Management (236635)

17. Results (2/4) Increase Packet Loss Rate & 2 IP Fragments • Then we used the following parameters: • 126 repetitions in the bulk response (= 2 IP packet, caused by IP-fragmentation) • Packet Loss rate ranging from 0%-50% stepping in 10% • Each scenario was tested 50 times Efficient Network Management (236635)

18. Results (3/4) Increase Packet Loss Rate & 8 IP Fragments • Then after we used the following parameters: • 400 repetitions in the bulk response (= ~8 IP packet, caused by IP-fragmentation) • Packet Loss rate ranging from 0%-50% stepping in 10% • Each scenario was tested 50 times Efficient Network Management (236635)

19. Results (4/4) Increasing IP Fragments & fixed Packet Loss • The last test had the following parameters: • Repetitions ranging from 6 to 2880, in the bulk response, stepping in ~400 • Packet Loss rate of 10% • Each scenario was tested 50 times Efficient Network Management (236635)

20. Observations (1/2) Increase Packet Loss Rate • Both methods success rate drop when packet loss rate inclines • Though, BC success rate is consistently higher than standard SNMP • UDP’s average success time is constant, BC’s average time increases. (UDP fails at const timeout, BC retries) • BC’s performance declines when packet loss increases over 20% (Combination of average time and success rate) Efficient Network Management (236635)

21. Observations (2/2) Fixed Low Packet Loss • When packet loss rate set to 10% and increasing the size of the bulk ... • BC delivers great performance: Nearly fixed time & high success rate • Standard SNMP suffers from increasing average time and steep drop in success rate Efficient Network Management (236635)

22. Conclusion • Using a TCP Backchannel proved to be very effective in relatively moderate packet loss rates (~10%) • The solution is transparent to existing SNMP based management tools • Provides efficient method for retrieving large amounts of data in a quick and reliable manner Efficient Network Management (236635)

23. The End Efficient Network Management (236635)