Differences
This shows you the differences between two versions of the page.
|
ep:labs:04 [2020/08/11 17:07] cristian.marin0805 [03. Individual Connections with tcptrace] |
ep:labs:04 [2021/10/22 17:25] (current) radu.mantu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Lab 04 - Networking Monitoring (Linux) ====== | + | ====== Lab 04 - Network Monitoring (Linux) ====== |
| + | ===== Objectives ===== | ||
| - | Why **Networking** is **Important**? | + | * Dive into the inner workings of previously studied traffic monitoring / filtering tools |
| + | * Discuss methods of path discovery | ||
| + | * Provide an introduction to protocol options | ||
| - | Having a well-established network has become an important part of our lives. The easiest way to expand your network is to build on the relationships with people you know; family, friends, classmates and colleagues. We are all expanding our networks daily. | ||
| - | ===== Objectives ===== | ||
| - | |||
| - | * Offer an introduction to Network monitoring. | ||
| - | * Get you acquainted with a few Linux standard monitoring tools and their outputs, for monitoring the impact of the Network on the system. | ||
| - | * Provides a set of insights related to understanding networks and connection behavior. | ||
| ===== Contents ===== | ===== Contents ===== | ||
| {{page>:ep:labs:04:meta:nav&nofooter&noeditbutton}} | {{page>:ep:labs:04:meta:nav&nofooter&noeditbutton}} | ||
| - | ===== Introduction ===== | ||
| - | |||
| - | ==== 01. Ethernet Configuration Settings ==== | ||
| - | |||
| - | <note> | ||
| - | Unless explicitly changed, all Ethernet networks are __auto negotiated for speed__. The benefit of this is largely historical when there were multiple devices on a network at **different speeds and duplexes**. | ||
| - | |||
| - | Most enterprise Ethernet networks run at either 100 or 1000BaseTX. Use **ethtool** to ensure that a specific system is synced at this speed. | ||
| - | |||
| - | In the following example, a system with a 100BaseTX card is running auto negotiated in //10BaseT//. | ||
| - | |||
| - | {{ :ep:laboratoare:ep2_poz4.png?450 |}} | ||
| - | |||
| - | The following command can be used to force the card into 100BaseTX: | ||
| - | |||
| - | //# ethtool -s eth0 speed 100 duplex full autoneg off// | ||
| - | </note> | ||
| - | ==== 02. Monitoring Network Throughput ==== | ||
| - | |||
| - | <note important>It is impossible to control or tune the switches, wires, and routers that sit in between two host systems. The best way to test **network throughput** is to send **traffic** between two systems and __measure statistics__ like **latency** and **speed**.</note> | ||
| - | |||
| - | === Using iptraf for Local Throughput === | ||
| - | |||
| - | <note>The **iptraf** utility (http://iptraf.seul.org) provides a **dashboard** of **throughput** per Ethernet interface. (Use: //# iptraf –d eth0//)</note> | ||
| - | |||
| - | === Using netperf for Endpoint Throughput === | ||
| - | |||
| - | <note>Unlike **iptraf** which is a **passive interface** that monitors traffic, the **netperf** utility __enables a system administrator__ to perform **controlled tests** of **network throughput**. This is extremely helpful in determining the throughput from a client workstation to a heavily utilised server such as a file or web server. The **netperf** utility runs in a **client/server** mode. | ||
| - | |||
| - | To perform a basic controlled throughput test, the **netperf** server must be running on the server system (//server# netserver//). | ||
| - | |||
| - | There are multiple tests that the **netperf** utility may perform. The most basic test is a standard throughput test. The following test initiated from the client performs a 30 second test of TCP based throughput on a LAN. | ||
| - | The output shows that the throughput on the network is around 89 mbps. The server (192.168.1.215) is on the same LAN. This is exceptional performance for a 100 mbps network.</note> | ||
| - | |||
| - | {{ :ep:laboratoare:ep2_poz5.png?430 |}} | ||
| - | |||
| - | <note>Another useful test using **netperf** is to monitor the amount of **TCP request and response** transactions taking place per second. The test accomplishes this by creating a single TCP connection and then sending multiple request/response sequences over that connection (ack packets back and forth with a byte size of 1). This behavior is similar to applications such as RDBMS executing multiple transactions or mail servers __piping__ multiple messages over one connection. | ||
| - | |||
| - | The following example simulates TCP request/response over the duration of 30 seconds.</note> | ||
| - | |||
| - | {{ :ep:laboratoare:ep2_poz6.png?450 |}} | ||
| - | |||
| - | <note>In the previous output, the network supported a transaction rate of 4453 psh/ack per second using 1 byte payloads. This is somewhat unrealistic due to the fact that most requests, especially responses, are greater than 1 byte. | ||
| - | |||
| - | In a more realistic example, a **netperf** uses a **default size** of **2K** for requests and **32K** for responses.</note> | ||
| - | |||
| - | {{ :ep:laboratoare:ep2_poz7.png?470 |}} | ||
| - | |||
| - | |||
| - | <note tip>The transaction rate reduces significantly to 222 transactions per second. | ||
| - | </note> | ||
| - | === Using iperf to Measure Network Efficiency === | ||
| - | |||
| - | <note>The **iperf** tool is similar to the **netperf** tool in that it checks connections between two endpoints. The difference with **iperf** is that it has more __in-depth checks__ around TCP/UDP efficiency such as __window sizes__ and __QoS settings__. The tool is designed for administrators who specifically want to **tune TCP/IP stacks** and then test the effectiveness of those stacks. The **iperf** tool is a single binary that can run in __either server or client mode__. The tool runs on port **5001** by default. In addition to TCP tests, **iperf** also has UDP tests to measure __packet loss and jitter__.</note> | ||
| - | |||
| - | ==== 03. Individual Connections with tcptrace ==== | ||
| - | |||
| - | The **tcptrace** utility provides detailed TCP based information about specific connections. The utility uses **libpcap** based files to perform an analysis of specific TCP sessions. The utility provides information that is at times difficult to catch in a TCP stream. This information includes: | ||
| - | * **TCP Retransmissions** – the amount of packets that needed to be sent again and the total data size | ||
| - | * **TCP Window Sizes** – identify slow connections with small window sizes | ||
| - | * **Total throughput** of the connection | ||
| - | * **Connection duration** | ||
| - | For more information refer to pages 34-37 from Darren Hoch’s “Linux System and Performance Monitoring” - http://ufsdump.org/papers/oscon2009-linux-monitoring.pdf. | + | ===== Proof of Work ===== |
| + | Before you start, create a [[http://docs.google.com/|Google Doc]]. Here, you will add screenshots / code snippets / comments for each exercise. Whatever you decide to include, it must prove that you managed to solve the given task (so don't show just the output, but how you obtained it and what conclusion can be drawn from it). If you decide to complete the feedback for bonus points, include a screenshot with the form submission confirmation, but not with its contents. | ||
| - | ==== Good to know: ==== | + | When done, export the document as a //pdf// and upload in the appropriate assignment on [[https://curs.upb.ro/2021/course/view.php?id=5665#section-5|moodle]]. Remember, the cut-off time is 15m after the lab ends. |
| - | <note important> | ||
| - | Takeaways for network performance monitoring: | ||
| - | * Check to make sure all **Ethernet interfaces** are running at proper rates. | ||
| - | * Check **total throughput** per **network interface** and be sure it is inline with network speeds. | ||
| - | * Monitor **network traffic** types to ensure that the **appropriate traffic** has precedence on the system. | ||
| - | </note> | ||
| ===== Tasks ===== | ===== Tasks ===== | ||
