Block Traffic

Parameter	Description	Default
Duration	How long should traffic been blocked?	30s
Include Hostnames	(optional) Restrict to/from which hosts the traffic is affected.
Include IPs/CIDRs	(optional) Restrict to/from which IP addresses or blocks the traffic is affected.
Exclude Hostnames	(optional) Exclude traffic to/from these hosts from being affected. Excludes always take precedence over the include restrictions.
Exclude IPs/CIDRs	(optional) Exclude traffic to/from these IP addresses or CIDR blocks from being affected. Excludes always take precedence over the include restrictions.
Include Ports	(optional) Restrict to which ports the traffic is dropped
Block Localhost Traffic	(optional) Also block matching traffic on the loopback interface (127.0.0.0/8, ::1), e.g. between two processes on the same host. Combine with the include restrictions above, otherwise all localhost traffic is blocked.	false

Details

Restrictions

This attack is not supported on hosts using Cilium.

Localhost traffic

By default, traffic between processes on the same host (127.0.0.0/8, ::1) is not blocked: the kernel delivers it before any blocking rule is evaluated. Enable Block Localhost Traffic to block it as well, e.g. to cut the connection between an application and a database running on the same host.

Only localhost traffic matching the include restrictions is blocked. Without restrictions, all localhost traffic on the host is blocked, so combine the option with Include IPs/CIDRs and/or Include Ports.
Only the address families of the include restrictions are affected: with IPv4 includes only, ::1 keeps working.
Traffic the host sends to its own non-loopback IPs is never blocked, with or without this option.
While the attack runs, the default routing rule for local traffic (0: from all lookup local) is replaced by two narrower ones around the blocking rules, and restored when the attack ends. If that default rule is missing, e.g. because of custom policy routing, the attack doesn't start.
A Block Traffic attack with this option can't run at the same time as another Block Traffic attack on the same host; the second attack fails to start.
Excludes take precedence. The extension's own ports stay reachable on localhost.

Useful Templates

See all

Network outage for Kubernetes nodes in an availability zone

Achieve high availability of your Kubernetes cluster via redundancy across different Availability Zones. Check what happens to your Kubernetes cluster when one of the zones is down.

Motivation

Cloud providers host your deployments and services across multiple locations worldwide. From a reliability standpoint, regions and availability zones are most interesting. While the former refers to separate geographic areas spread worldwide, the latter refers to an isolated location within a region. For most use cases, applying deployments across availability zones is sufficient. Given that failures may happen at this level quite frequently, you should verify that your applications are still working in case of an outage.

Structure

We leverage the block traffic attack to simulate a full network loss in an availability zone. While the zone outage happens, we observe changes in the Kubernetes cluster with Steadybit's built-in visibility. Once the zone outage is over, we expect that all deployments will recover again within a specified time.

Solution Sketch

AWS Regions and Zones
Azure Regions and Zones
GCP Regions and Zones
Kubernetes liveness, readiness, and startup probes

Linux host losing network connection is detected by Datadog

When a host suddenly loses connection to the network and your system, Datadog should alert about this. Eventually, everything should recover once the network is back again.

Motivation

When you're working in a less volatile system environment, a loss of network can be crucial as there is likely no backup host that will enable faster recovery. Thus, you should check your observability tools to catch this.

Structure

Before blocking a host from the network, we verify that the Datadog monitor is in an ok state Afterward, we block all traffic to and from a host and expect Datadog to alert about the isolated host. Eventually, when the host is online again, we expect Datadog to turn into an OK state again. While experimenting, we create a downtime for the Monitor so that it will not escalate due to the ongoing alert.

More Linux Host Actions

See all