Goline Logo


  • Route RPKI validation April 1st, 2022
    RPKI is a security framework by which network owners can validate and secure the critical route updates or Border Gateway Protocol (BGP) announcements between public Internet networks. BGP is essentially the central nervous system of the Internet and one of its fundamental building blocks. The main function of BGP is to facilitate efficient routing between Autonomous Systems (AS), by building and maintaining the Internet routing table. The Internet routing table is effectively the navigation system of the Internet and without it, traffic would be unable to flow between its constituent networks. Unfortunately, routing equipment alone cannot distinguish between legitimate and malicious routing announcements,...
  • RIPE – Atlas Anchor February 17th, 2022
    We have become an even more integral part of the RIPE Atlas project by hosting an anchor, a device that allows for latency analysis of traffic between autonomous systems.https://atlas.ripe.net/probes/7073/RIPE Atlas anchors play an integral role in the RIPE Atlas network by acting both as enhanced RIPE Atlas probes with more measurement capacity, as well as regional measurement targets within the greater RIPE Atlas network. Anchors are able to perform many more measurements than a regular RIPE Atlas probe, and the large amount of data they collect is made available to everyone. In addition, anchors act as powerful targets that can...
  • MANRS June 20th, 2020
    GOLINE firmly believes in initiatives to protect networks, improve security and resilience of the global routing system. Therefore we decided to support the MANRS project and join as participants.Mutually Agreed Norms for Routing Security (MANRS) is a global initiative, supported by the Internet Society, that provides crucial fixes to reduce the most common routing threats. MANRS offers specific actions via four programs for Network Operators, Internet Exchange Points, CDN and Cloud Providers, and Equipment Vendors. Requirements for Participation Please read the full MANRS Actions document before applying. You can become a participant if you meet these requirements: You (or your company) support...

iftop – display bandwidth usage on an interface by host

Miro Manglaviti Linux 22 June 2022


iftop – display bandwidth usage on an interface by host


iftop -h | [-nNpblBP] [-i interface] [-f filter code] [-F net/mask] [-G net6/mask6]



iftop listens to network traffic on a named interface, or on the first interface it can find which looks like an external interface if none is specified, and displays a table of current bandwidth usage by pairs of hosts. iftop must be run with sufficient permissions to monitor all network traffic on the interface; see pcap(3) for more information, but on most systems this means that it must be run as root.

By default, iftop will look up the hostnames associated with addresses it finds in packets. This can cause substantial traffic of itself, and may result in a confusing display. You may wish to suppress display of DNS traffic by using filter code such as not port domain, or switch it off entirely, by using the -n option or by pressing r when the program is running.

By default, iftop counts all IP packets that pass through the filter, and the direction of the packet is determined according to the direction the packet is moving across the interface. Using the -F option it is possible to get iftop to show packets entering and leaving a given network. For example, iftop -F will analyse packets flowing in and out of the 10.* network.

Some other filter ideas:

not ether host ff:ff:ff:ff:ff:ff
Ignore ethernet broadcast packets.
port http and not host webcache.example.com
Count web traffic only, unless it is being directed through a local web cache.

How much bandwidth are users wasting trying to figure out why the network is slow?



Print a summary of usage.


Don't do hostname lookups.


Do not resolve port number to service names


Run in promiscuous mode, so that traffic which does not pass directly through the specified interface is also counted.


Turn on port display.


Display and count datagrams addressed to or from link-local IPv6 addresses. The default is not to display that address category.


Don't display bar graphs of traffic.


Display bandwidth rates in bytes/sec rather than bits/sec.

-i interface
Listen to packets on interface.
-f filter code
Use filter code to select the packets to count. Only IP packets are ever counted, so the specified code is evaluated as (filter code) and ip.
-F net/mask
Specifies an IPv4 network for traffic analysis. If specified, iftop will only include packets flowing in to or out of the given network, and packet direction is determined relative to the network boundary, rather than to the interface. You may specify mask as a dotted quad, such as /, or as a single number specifying the number of bits set in the netmask, such as /24.
-G net6/mask6
Specifies an IPv6 network for traffic analysis. The value of mask6 can be given as a prefix length or as a numerical address string for more compound bitmasking.
-c config file
Specifies an alternate config file. If not specified, iftop will use ~/.iftoprc if it exists. See below for a description of config files


When running, iftop uses the whole screen to display network usage. At the top of the display is a logarithmic scale for the bar graph which gives a visual indication of traffic.

The main part of the display lists, for each pair of hosts, the rate at which data has been sent and received over the preceding 2, 10 and 40 second intervals. The direction of data flow is indicated by arrows, <= and =>. For instance,

foo.example.com  =>  bar.example.com      1Kb  500b   100b

                 <=                       2Mb    2Mb    2Mb

shows, on the first line, traffic from foo.example.com to bar.example.com; in the preceding 2 seconds, this averaged 1Kbit/s, around half that amount over the preceding 10s, and a fifth of that over the whole of the last 40s. During each of those intervals, the data sent in the other direction was about 2Mbit/s. On the actual display, part of each line is inverted to give a visual indication of the 10s average of traffic. You might expect to see something like this where host foo is making repeated HTTP requests to bar, which is sending data back which saturates a 2Mbit/s link.

By default, the pairs of hosts responsible for the most traffic (10 second average) are displayed at the top of the list.

At the bottom of the display, various totals are shown, including peak traffic over the last 40s, total traffic transferred (after filtering), and total transfer rates averaged over 2s, 10s and 40s.


By pressing s or d while iftop is running, all traffic for each source or destination will be aggregated together. This is most useful when iftop is run in promiscuous mode, or is run on a gateway machine.

Port Display

S or D toggle the display of source and destination ports respectively. p will toggle port display on/off.

Display Type

t cycles through the four line display modes; the default 2-line display, with sent and received traffic on separate lines, and 3 1-line displays, with sent, received, or total traffic shown.

Display Order

By default, the display is ordered according to the 10s average (2nd column). By pressing 1, 2 or 3 it is possible to sort by the 1st, 2nd or 3rd column. By pressing < or > the display will be sorted by source or destination hostname respectively.

Display Filtering

l allows you to enter a POSIX extended regular expression that will be used to filter hostnames shown in the display. This is a good way to quickly limit what is shown on the display. Note that this happens at a much later stage than filter code, and does not affect what is actually captured. Display filters DO NOT affect the totals at the bottom of the screen.


P will pause the current display.

o will freeze the current screen order. This has the side effect that traffic between hosts not shown on the screen at the time will not be shown at all, although it will be included in the totals at the bottom of the screen.

0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments
Would love your thoughts, please comment.x