An Eclectic Introduction to Iota

An Eclectic Introduction to Iota 1 Created: 2020-08-15

Stuart Kendrick Updated: 2020-09-05

An Eclectic Introduction to Iota Contents Overview 2

Capture Control 2

Status 2

Pcap Archive 7

Twinks 11

Filtering 14

Dashboards 15

Home 16

Explore 18

Flow Explorer 19

Filtering Out 20

Grabbing a PCAP 23

TCP Troubleshoot 27

DNS 33

Others 34



Overview Here is a rough introduction to the Iota’s basic features. I am not trying to be exhaustive here, merely flying high and fast, to develop

an early feel for how the product works.

What The Iota is a hand-held box which combines packet capture, a database, and a graphical reporting engine.

- 1G or 10G in-line or SPAN-based packet capture

- In-memory packets saved into a pcap every 60s

- Meta-data extracted from each pcap and stashed into a database

- Graphical (Kibana) reporting engine

Capture Control In this example, I have the Iota plugged into a SPAN port on a 10G pathway connecting a building to the rest of the campus.

Status Here we can see that the Iota has captured ~31GB of traffic, saved now across 354 pcaps, and during the process has dropped ~1MB

of packets. Why dropped frames? The 10G Iota model sports SFP+ ports which support 10G Ethernet transceivers. But the box is

not architected to support 10Gb/s line-rate capture, so past ~3Gb/s, it drops frames. The traffic across this link sees plenty of surges

past 3Gb/s.



Here, we can see the disk gradually accumulating traffic



Once the disk is full, the Iota stops capturing.



You can run automated clean-ups on a periodic basis:

There is currently no way to implement a rolling buffer.

Pcap Archive Here we can see the long list of pcaps:



One can download each one individually, or a collection, by clicking the check boxes.

Here we can the see the state of the Capture Engine: it is capturing and has consumed a few percent of the available ~900GB of

storage space



Twinks Iota can capture in In-line or SPAN mode

You can twink with Capture Control by retaining or discarding bad frames and by slicing.



Like other Profitap products, the Iota offers in-depth reporting on the SFP/SFP+ which you have inserted:



Filtering And the Iota provides some limited hardware filtering capabilities:



Dashboards Iota ships with predefined Dashboards – the graphical reporting engine built atop Kibana. Here is a view of the default Home

Dashboard: a typical ‘Top Talker’ type display.



Home

Notice how I can quickly filter down to view, say, just UDP traffic:



And if I want to see the packets behind, say, 10.71.12.33’s UDP traffic, I can click on it and download a pcap extracted from the entire

archive of pcaps currently stored on the device.

Explore This Dashboard gives you an early view into stations and applications:

In this situation, we can see that NFS traffic (TCP Port 2049 Is dominating, with SSL (TCP Port 443) trailing. And that Iota has

identified a handful of application Servers – looks like a check_mk instance (using check_ssh), an OpenNMS instance, plus some

Ubuntu box and an Apache instance.



Flow Explorer The Iota thinks in terms of Flows, which are defined by tuples of IP source & destination address, protocol, and port number:

Here we can see a couple stations which emit a lot of pings (management stations?)



Filtering Out Management stations can rack up a lot of flows (every single ICMP Echo / Echo Reply looks like a new Flow), as does each SNMP

query / response. I don’t want to look at these – not relevant to the end-user experience. So let’s filter them out, by clicking on the ‘+’

sign to the right of Filters.



Scrolling down



And here I have a view in which flows from one particular station are no longer included in the display.

Grabbing a PCAP Now, some of those addresses are racking up a lot of DNS queries – why? If they were our DNS servers, then perhaps this would be

understandable, but I happen to know that they are not.

So let’s Filter on the top DNS talker



Drill into a tiny time slice by selecting a small square



And then clicking Download PCAP



And then I can open the pcap, where I can see that the host is emitting DNS queries for a single name in the following rapid-fire

pattern: foo

foo.company.com

foo

foo.company.com

foo

foo.company.com

[…]

The queries for ‘foo’ fail of course, while the queries for ‘foo.company.com’ succeed. This suggests a misconfiguration on that host,

namely that it is emitting DNS queries for unqualified names. And raises the question of why an application feels the need to perform

DNS look-ups at a frenetic rate (typically .8ms between each query, per a glance at the pcap using Wireshark).

TCP Troubleshoot This Dashboard offers a quick overview of TCP health.



Here for example we can see which conversations are being affected by Zero Window events.



Which are experiencing long round-trip times



Which are the popular TCP Ports



Which do Retransmissinos look like – some of those clients are doing a lot of retransmissing

Here, we get a feel for Lost Packets



And Out-of-Order counts:



Of course, this sort of high-level survey isn’t particularly useful here – more useful would be Filtering on a particular Client or Server

of interest and focusing on the TCP Health of that particular conversation.

DNS



Others Iota ships with a collection of pre-built Dashboards, plus, you can build your own

An Eclectic Introduction to Iota

Documents

Transcript of An Eclectic Introduction to Iota