Forwarding

Your devices already send syslog, traps, and flow to Yagra. Forwarding hands that data onward — to a SIEM, a compliance archive, another collector — without configuring a second export target on every device, and without Yagra giving anything up.

What forwarding is

Forwarding is a filtered tee of received passive data. A destination says “everything matching this filter also goes there”; Yagra keeps ingesting, matching, alerting, and storing regardless. It is a copy onward, not a diversion — Yagra stays the system of record.

Destinations are configured under Settings ▸ Forwarding, and the sending has a deliberate shape: core does all the sending; pollers only carry the received bytes to core over the bus. That gives you a single egress point — you allow one address through the firewall rather than one per poller, and a remote-site poller needs no new outbound rules for a destination you add at HQ. In a high-availability pair the active (leader) core is the one that sends, so the egress point stays single even with two cores running.

Sources

Three source kinds select what a destination receives:

Source	What it carries
`syslog`	Received syslog messages — and webhook-ingested events, which ride under this kind
`trap`	Received SNMP traps and informs
`flow`	Received flow exports (NetFlow v5/v9, IPFIX, sFlow), relayed as whole datagrams

Pollers carry the original bytes to core whether or not any destination exists today. That carriage is deliberate: a capture toggle would make forwarding fidelity depend on configuration rather than being a property of the system — the moment you add a destination, byte-exact output is simply available. (It does cost bus bandwidth at remote sites; see Egress requirements.)

Destinations

Six destination kinds, each with a defined wire behavior:

Kind	Wire format	Accepts
Syslog over UDP	RFC 5424	syslog, trap
Syslog over TCP	RFC 6587 octet-counted framing (message boundaries survive embedded newlines)	syslog, trap
Syslog over TLS	RFC 5425	syslog, trap
SNMP trap re-emission	SNMPv2c trap PDUs over UDP	trap only
Flow relay	The original datagram, verbatim, over UDP	flow only
BigQuery	Normalized, typed rows via streaming insert	everything

Relay fidelity. Relay destinations have two modes: verbatim sends the original datagram byte-exact — the collector sees exactly what the device sent — and rendered rebuilds the message from the parsed fields (RFC 5424 for syslog destinations, an SNMPv2c trap PDU for the trap destination). Where a pairing has no sensible original — a trap relayed to a syslog destination, say — the rendered form is used, because a trap PDU dropped on a syslog port would be undecodable.

The compatibility column above follows from the same logic. The trap re-emission destination accepts traps only: no SNMP PDU can be built from a syslog line. The syslog destinations accept traps as well as syslog, because a trap renders naturally into a log line — which is exactly how most SIEMs want to receive traps anyway.

Flow relay is byte-exact or nothing. A flow export is template-bound binary; no rendered form could stand in for it, so the API rejects rendered mode on a flow destination rather than silently sending something a collector cannot parse. Template datagrams (the periodic NetFlow v9/IPFIX template refresh) always pass, filter or no filter — without them a filtered collector could never decode the records it does receive.

BigQuery is the odd one out: instead of mirroring a live stream, it streams normalized, typed rows — one per event, one per flow record — into a table for querying months of history. Yagra creates the table for you, day-partitioned and clustered; the dataset must already exist, because a dataset’s region is permanent and Yagra will not silently choose your data residency. Grant the identity the BigQuery Data Editor role on the dataset — paste a service-account JSON key (encrypted at rest, never shown again), or leave the credential empty when core runs on Google Cloud with Workload Identity, which stores no credential at all. Two things to know before enabling it: streaming inserts are billed by Google, and the original bytes are deliberately not stored — a relayed datagram passes once to a collector you chose, but a table persists, and syslog bodies routinely contain credentials. Pair a BigQuery destination with a relay destination if you also need byte-exact archival.

Filters

Each destination carries an optional filter: a match-all or match-any set of up to 32 typed conditions (operands capped at 512 characters). An empty filter forwards everything from the selected source.

Conditions are field + operator + operand. Event-side fields cover the source IP, poller pool, event kind, syslog facility and severity, hostname, application name, message text, trap OID, and trap varbinds; flow-side fields cover source/destination address, protocol (names like tcp are accepted), source/destination port, and source/destination AS. Twelve operators are available — equality, contains, prefix, regex (and their negations), list membership, CIDR membership, and numeric bounds — and each is type-checked against its field: a regex on a port, or a CIDR test on a hostname, is rejected with 400 when you save it, never silently ignored at send time.

Typical shapes: a SIEM destination that takes only what matters (severity at or above warning, and hostname prefixed with the site code), or a NetOps flow archive scoped to the internal range (src_addr in 10.0.0.0/8 or dst_addr in 10.0.0.0/8).

Filter semantics differ by data shape, and the difference matters:

Event filters are exact, per message. A syslog line or trap either matches or it does not.
Flow filters are per-datagram, not per-record. A relayed flow datagram is forwarded whole when any record in it matches — non-matching records included — because records cannot be removed without re-encoding the datagram, and re-encoding would break the byte-exact promise. Expect a superset of the records you asked for, never a subset.
BigQuery flow filtering is exact, per record — rows are independent, so only matching records become rows. If you need precise flow selection, BigQuery is the destination that can do it.

Two guardrails: at most 1,024 records per datagram are inspected for filtering, and a datagram that cannot be decoded at all is dropped and counted on a filtered destination rather than forwarded unfiltered — a filter that fails open is worse than one that fails closed.

TLS

The TLS syslog destination (RFC 5425) is the only relay kind protected in transit — UDP and TCP syslog, trap re-emission, and flow relay are plaintext on the wire, so keep those on networks you trust and prefer TLS whenever the path to the collector crosses anything you do not own. (BigQuery is HTTPS by nature.)

Certificate verification uses the system trust store, plus an optional per-destination CA certificate (PEM) for collectors signed by a private CA. Verification can never be disabled — there is no flag — so a destination behind a TLS-interception proxy will not connect; add the proxy’s CA to the destination instead. The CA certificate is not a secret: it round-trips through the API like any other destination setting, and it is rejected on non-TLS destination kinds where it would mean nothing.

Reliability and visibility

A slow or dead destination must never become Yagra’s problem. Every destination is isolated behind:

A bounded queue (4,096 messages). When it fills, new messages for that destination are dropped and counted — ingestion, matching, and alerting are never blocked by a destination that cannot keep up.
An optional per-destination rate limit, for collectors licensed or sized by events per second.
A circuit breaker: five consecutive send failures open it; after 30 seconds one probe is let through, and the circuit closes again only when a send succeeds. A dead collector costs a counter, not a backlog.
Timeouts and re-resolution: connects and writes time out at 5 seconds, and destination hostnames are re-resolved every 5 minutes, so a long-lived relay follows a collector that moves.

All of it is visible per destination — messages sent, filtered, and dropped (by reason: queue full, rate limit, circuit open, unfilterable, undecodable), current queue depth, and circuit state — on Settings ▸ Forwarding, at GET /api/v1/forwarding/status, and in core’s Prometheus metrics (drops are counted per reason in yagra_forward_dropped_total).

Fidelity is watched the same way: a destination that promised byte-exact output but had to do without an original datagram counts it, and any poller that cannot supply original bytes is named on the page. Forwarding is built so it cannot quietly degrade — when the output is less than promised, the page says so.

Egress requirements

Because core does all the sending, only the core host needs firewall exceptions:

Destination kind	Egress needed
Relay (UDP / TCP / TLS syslog, trap, flow)	The collector’s `host:port`
BigQuery	`bigquery.googleapis.com` and `oauth2.googleapis.com` over HTTPS — plus the GCE metadata server (`169.254.169.254`) when using Workload Identity instead of a stored key

Nothing is sent until you add a destination — a deployment with no destinations configured makes no forwarding egress at all.

One cost is paid on the bus rather than at the egress: so that forwarding can relay exactly what a device sent, pollers always carry the original bytes to core — roughly 1.45–1.64× the raw event volume, plus every received flow datagram verbatim alongside the aggregated stream. That is real WAN traffic for a remote-site poller; the sizing discussion and the full egress table are in Ports & firewall.