MIMIC SNMP SImulator and Prometheus FOSS

We installed the Prometheus free open-source software NMS, and enabled
SNMP monitoring following this post.

Once we pointed Prometheus at a out-of-the-box 25-node simulated network with

MIMIC SNMP Simulator

we can monitor network interfaces. The graphing can be
compared to a commercial offering as shown below:

IoT Control System at the edge: MIMIC MQTT Simulator and AWS IoT Greengrass

Overview

AWS IoT Greengrass is Amazon's IoT edge processing platform. We used their
documentation and other sources [1] with MIMIC MQTT Simulator to setup a
simple control system at the edge to test bi-directional MQTT message flow
(from sensors to control logic, and from control logic to actuator).

For those who'd rather skip to the video, here is the 2-minute Youtube video.

This example illustrates the purpose of IoT at the edge: the processing that does
not need the cloud should happen locally. In this test, everything is occurring at
the edge, we just  added device shadow synchronization to the AWS IoT cloud
for illustration.

Details

You need to setup an account at Amazon AWS IoT. Once logged into the AWS IoT
console, and a Greengrass Group has been created according to their
Getting Started manual. We setup a group called GG_group2 with a core 
GG_group2_Core.

Then we simulated our usual bi-directional simple control system at the edge,
with these devices

including a sensor sensor_1 reporting telemetry to Greengrass core,

running in MIMIC as seen above on the left, with certificates as configured in
AWS on the right.

When the actuator (eg. cooling system) in the control system is off, the sensor
temperature heats, and when it is on, then it cools. We implemented the control
system logic in a Node-RED flow, rather than in a Lambda function.

It turns the actuator on if the temperature exceeds a high threshold, and turns it
off if the temperature is cool enough. The connectivity to the core broker is setup
as a subscriber to the shadow updates as shown below on the right:

and the Node-RED subscriber is configured to connect to the broker at the edge:

with TLS certificates exported by AWS:

The parts of the system need permission to publish as defined in the Greengrass
subscriptions:

Once everything is setup, the control system reaches a normal steady state at the
edge, as visualized by the Node-RED graphing rules, as shown in this 2-minute
Youtube video.

Conclusion

We saw that by using MIMIC MQTT Simulator we can create a real-time
scalable, predictable, customized IoT Edge Control System scenario that
compresses the state transitions into a period short enough for showing in
less than 3 minutes.

Future work can improve on this to make it more scalable, test exceptions
(eg. what if the sensor does not cool down when fan is on?), test different
implementations (eg. Lambda function vs. Node-RED), etc.


References:

[1] The Hitchhikers Guide to AWS IoT

MIMIC MQTT Simulator driving a IoT demo at Cisco Live

If you are planning to attend Cisco Live next week, take a look at a
dynamic IoT platform demo. You will see a cruise ship with dynamic,
real-time cabin temperature and door lock sensors simulated by
MIMIC MQTT Simulator.

Here you see a drill-down to a particular sensor:

Update 6/12/2019: Here is a tweet to a video at the show.

MIMIC MQTT Simulator: dynamic, scalable device shadows on AWS IoT

This 2-minute Youtube video shows multiple, independent device shadows
updating from MIMIC MQTT Simulator to Amazon AWS IoT with dynamic,
real-time,  predictable, scalable values.

MIMIC allows to quickly create on-demand prototypes and proof-of-concepts for
your particular IoT Application based on AWS IoT device shadows.

MIMIC Simulator integrated with Telegraf OSS monitoring application

What better way to quickly develop / test / prototype Telegraf deployments
than with simulated data? MIMIC Simulator delivers the dynamic,
customizable, scalable data for the variety of Telegraf input plugins.

To exercise SNMP interoperability, for this experiment we graph real-time
interface statistics from a simulated Cisco ASR 9000  router.

The graph in Grafana shows ifInOctets SNMP data collected from the MIMIC
simulated Cisco ASR 9000. The data is collected by the Telegraf application
using the SNMP plugin, and output to InfluxDB. Grafana is showing the data
using the InfluxDB as data source.

The Telegraf, InfluxDB and Grafana setup was done using this link:

https://lkhill.com/telegraf-influx-grafana-network-stats/

MIMIC implements MQTT 6

Skipping the latest MQTT 5, MIMIC MQTT Simulator now supports the
yet-to-be-defined MQTT 6 standard.

Happy April Fool's Day!

In all seriousness, MIMIC is the first MQTT 5 simulator to implement the
latest MQTT 5.

Try it out at http://mqttlab.iotsim.io/mqtt5/

MQTT 5 Testing

MQTT 5.0 is the next version of the ISO standard MQTT 3.1.1 Internet
of Things protocol.

We used the latest version of MIMIC MQTT Simulator to test several MQTT
brokers with MQTT 5 support, and in a short time have discovered some
differences in protocol behavior between them.

Test 1 - CONNECT with Maximum Packet Size set to low value

In the case of 0, one broker disconnects immediately, and the other sends a
CONNACK with Reason Code. In this case, the spec clearly says

It is a Protocol Error to include the Maximum Packet Size more than once, or for the value to be set to zero.

Both behaviors are legal, since protocol errors must result in disconnect, but
at the discretion of the server it may send a CONNACK with reason code, as
detailed here.

Curiously, if the value is 10, again one broker disconnects immediately, but
the other does not send anything, presumably because the CONNACK would
have violated the limit. This results in a timeout at the client.

Test 2 - PUBLISH with empty topic name and no topic alias

In this case, one broker disconnects and the other sends PUBACK with
Reason Code. In this case, the spec clearly says

It is a Protocol Error if the Topic Name is zero length and there is no Topic Alias.

Protocol errors must result in disconnect as detailed here.

Test 3 - PUBLISH to wildcard topic

For example, to handle the error of a PUBLISH with QOS = 1 to an illegal
wildcard topic, one broker returns a PUBACK with the Reason Code of 0x90,
whereas another returns a DISCONNECT with that Reason Code. This
behavior is expected with QOS 0, but since it is not defined as a protocol
error, for QOS 1 and 2 the PUBACK and PUBREC response should be used.

This is what our logs show:


INFO  02/06.10:58:25 - MQTT[AGT=1] - sent PUBLISH (110 bytes)
INFO  02/06.10:58:25 - MQTT[AGT=1] - rcvd PUBREC rc=0x90 Reason String The topic is not valid: ...

vs.

INFO  02/06.11:01:25 - MQTT[AGT=1] - sent PUBLISH (110 bytes)
INFO  02/06.11:01:25 - MQTT[AGT=1] - rcvd DISCONNECT reason 0x90 (Reason String PUBLISH with wildcard character (#/+) was sent.)

Test 4 - PUBLISH with Payload Format property

For a PUBLISH with property Payload Format set, the spec says

A Server MUST send the Payload Format Indicator unaltered to all
subscribers receiving the Application Message [MQTT-3.3.2-4]

One of the brokers discards the Payload Format Indicator property if it is 0.
If this property is missing, it can be assumed to be 0. While not breaking
anything, this is technically incorrect.

Conclusion

Since MQTT 5 is so recent, you need to test many features of your selected
MQTT brokers and IoT applications with different scenarios to mitigate
costly surprises before deployment. MIMIC MQTT Simulator can really help
with that.