Snmp tcp backchannel
Download
1 / 23

SNMP TCP Backchannel - PowerPoint PPT Presentation


  • 85 Views
  • Uploaded on

SNMP TCP Backchannel. An SNMP agent extension for transferring large files. Submitted by:. Tsachi Sharfman 029710399 Kfir Karmon 037197696. Problem Description. SNMP runs over UDP UDP is unreliable and therefore is inefficient for transferring large amounts of data.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' SNMP TCP Backchannel' - lew


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Snmp tcp backchannel

SNMP TCP Backchannel

An SNMP agent extension for transferring large files

Submitted by:

Tsachi Sharfman 029710399

Kfir Karmon 037197696

Efficient Network Management (236635)


Problem description
Problem Description

  • SNMP runs over UDP

  • UDP is unreliable and therefore is inefficient for transferring large amounts of data

Efficient Network Management (236635)


Solution s requirements
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)


Possible solutions 1 3
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)


Possible solutions 2 3
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)


Possible solutions 3 3
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)


Implementing solution 3
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)


Implementing solution 31
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)


Implementing solution 32
Implementing Solution #3

Backchannel Control MIB (BCM) 2/3

  • BCRegisteredClients

  • BCRegisteredOIDs

Legend:

Efficient Network Management (236635)


Implementing solution 33
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)


Implementing solution 34
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)


Implementing solution 35
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)


Implementing solution 36
Implementing Solution #3

The Whole Picture

Efficient Network Management (236635)


How we tested 1 2
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)


How we tested 2 2
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)


Results 1 4
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)


Results 2 4
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)


Results 3 4
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)


Results 4 4
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)


Observations 1 2
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)


Observations 2 2
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)


Conclusion
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)


The end
The End

Efficient Network Management (236635)


ad