snmp tcp backchannel
Download
Skip this Video
Download Presentation
SNMP TCP Backchannel

Loading in 2 Seconds...

play fullscreen
1 / 23

SNMP TCP Backchannel - PowerPoint PPT Presentation


  • 86 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