Usage

FlowSpec Injection

Use Ze to inject or relay BGP FlowSpec rules when an automation system must distribute traffic filters to routers. Keep the route source, policy, and withdrawal path explicit because a stale FlowSpec rule can affect live traffic.

Choose the deployment shape

Two common shapes are:

  1. A FlowSpec route reflector receives rules from an authorised controller and reflects them to clients.
  2. A protected router receives FlowSpec and translates accepted rules into local firewall actions.

The existing FlowSpec route-reflector and protected-router guides cover those complete roles. This page focuses on the injection boundary.

Complete injection lab

The destination peer must negotiate the FlowSpec family. Save this minimal sender configuration as flowspec-sender.conf; configure the remote router as AS 64501 at 192.0.2.20.

plugin {
    internal rib { use bgp-rib; }
}

bgp {
    router-id 192.0.2.10;
    session { asn { local 64500; } }

    peer flowspec-client {
        connection {
            local { ip 192.0.2.10; }
            remote { ip 192.0.2.20; }
        }
        session {
            asn { remote 64501; }
            family {
                ipv4/flow { prefix { maximum 1000; } }
            }
        }
    }
}

Validate and start the sender, then confirm family negotiation:

ze config validate flowspec-sender.conf
ze start flowspec-sender.conf
ze cli -c "show bgp peer flowspec-client capabilities"

In a lab, inject a discard rule for TCP destination port 443:

ze cli -c "peer flowspec-client update text extended-community [rate-limit:0] nhop self nlri ipv4/flow add destination 203.0.113.0/24 protocol tcp destination-port =443"

The command uses the same registered dispatcher through CLI, REST, gRPC, and MCP. Confirm the remote router installed the rule, then withdraw the exact NLRI:

ze cli -c "peer flowspec-client update text nlri ipv4/flow del destination 203.0.113.0/24 protocol tcp destination-port =443"

Use an atomic window

When several rules form one mitigation, stage and inspect them before release:

ze cli -c "request commit start mitigation-42"
ze cli -c "peer flowspec-client update text extended-community [rate-limit:0] nhop self nlri ipv4/flow add destination 203.0.113.0/24 protocol tcp destination-port =443"
ze cli -c "peer flowspec-client update text extended-community [rate-limit:9600] nhop self nlri ipv4/flow add destination 203.0.113.0/24 protocol udp destination-port =53"
ze cli -c "request commit show mitigation-42"
ze cli -c "request commit end mitigation-42"

Use request commit rollback mitigation-42 instead of end if validation or review fails. This prevents clients from observing a partial mitigation policy.

Authorisation and policy

Treat route injection as a privileged operation:

A controller must be able to withdraw every rule it installs. Do not rely on process exit as cleanup.

Verification

After injection:

ze cli -c "show bgp peer flowspec-client capabilities"
ze cli -c "show bgp rib status"
ze cli -c "show warnings"
ze cli -c "show errors"

Then verify the destination appropriate to the deployment:

Test rule replacement as well as add and withdraw. A mitigation controller often changes rate or match criteria while an incident is active.

Failure cases

Monitor both BGP state and the enforcement backend. One without the other is incomplete evidence.